date:20160512

[Xen-devel] [qemu-upstream-4.4-testing baseline-only test] 44411: tolerable FAIL

2016-05-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 44411 qemu-upstream-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44411/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2 19 guest-start/debian.repeat fail blocked in 44171
 test-amd64-amd64-pv  17 guest-localmigrate/x10   fail blocked in 44171

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 qemuua2fd7eba04d4c69e4ee18a43eb6cf32aaffb3c98
baseline version:
 qemuu16169ab825a03262cd66382dc0b02caa0dbd636a

Last test of basis44171  2016-02-26 11:55:40 Z   76 days
Testing same since44411  2016-05-12 23:20:28 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   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-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  fail
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  fail
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit a2fd7eba04d4c69e4ee18a43eb6cf32aaffb3c98
Author: Gerd Hoffmann 
Date:   Tue Apr 26 14:48:06 2016 +0200

vga: make sure vga register setup for vbe stays

Re: [Xen-devel] [PATCH v4 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending

2016-05-12 Thread Xu, Quan

On May 10, 2016 5:25 PM, Jan Beulich  wrote:
> >>> On 06.05.16 at 10:54,  wrote:
> > --- a/xen/arch/x86/acpi/power.c
> > +++ b/xen/arch/x86/acpi/power.c
> >  static int device_power_down(void)
> >  {
> > -console_suspend();
> > +if ( console_suspend() )
> > +return TYPE_CONSOLE;
> 
> This (together with the resume side) makes me guess that the use of TYPE_ as
> a prefix confused not just me, but also you:

Yes,  this is really not a good prefix, and probably pretty bad to use 'ERROR_'.
What about 'PRIOR_'?  then I also need to adjust  device_power_up() as ...


> Here you want to tell the caller
> that everything _prior_ to console suspend (which happens to be nothing in
> this specific case) needs to be undone. Yet below you use TYPE_CONSOLE as
> an indication that
> console_resume() needs to be called.

... this,

+switch ( prior )
+{
   ...
+time_resume();
+case PRIOR_TIME:
+console_resume();
+case PRIOR_CONSOLE:
...
+}

> 
> > -time_suspend();
> > +if ( time_suspend() )
> > +return TYPE_TIME;
> >
> > -i8259A_suspend();
> > +if ( i8259A_suspend() )
> > +return TYPE_I8259A;
> >
> > +/* ioapic_suspend should never fail */
> >  ioapic_suspend();
> 
> The comment is bogus: "should" means it can in theory. Yet the function
> having void return type means it just cannot fail.
> 

I'll use 'cannot', instead of 'should'.
Another question, I check the code again, and the rest of the functions 
(console_suspend/ time_suspend/ i8259A_suspend / ioapic_suspend / lapic_suspend 
), in device_power_down(), always returned '0'.
Maybe I need to fix these functions  annotation from 'int' to 'void', and then 
I can add a comment on the device_power_down().  

More that, if the   ' iommu_suspend()'  is the only fail, could we re-consider 
the previous v2/v3 solution with 'goto'?

> > @@ -169,6 +204,7 @@ static int enter_state(u32 state)
> >  {
> >  printk(XENLOG_ERR "Some devices failed to power down.");
> >  system_state = SYS_STATE_resume;
> > +device_power_up(error);
> 
> Either error's and device_power_down()'s return type get changed to enum
> dev_power_type, or this needs a "error > 0" conditional.
> 
> > @@ -1267,7 +1273,9 @@ static void __hwdom_init
> intel_iommu_hwdom_init(struct domain *d)
> >  setup_hwdom_pci_devices(d, setup_hwdom_device);
> >  setup_hwdom_rmrr(d);
> >
> > -iommu_flush_all();
> > +if ( iommu_flush_all() )
> > +printk(XENLOG_WARNING VTDPREFIX
> > +   " intel_iommu_hwdom_init: IOMMU flush all failed.\n");
> 
> As said (and I think a number of times) before: At least when you already hold
> the error value in your hands, please also log it.

Agreed, and I will apply for other patches.

> Also personally I'm opposed to
> including function names in non-debug log messages, but I'll leave that
> decision to the VT-d maintainers here.
> 

Albeit Reluctantly, I will fix it.

Quan


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

Re: [Xen-devel] [PATCH] xen: sched: rtds: refactor code

2016-05-12 Thread Meng Xu

Hi Tianyang

On Wed, May 11, 2016 at 11:20 AM, Tianyang Chen  wrote:
> No functional change:
>  -Various coding style fix
>  -Added comments for UPDATE_LIMIT_SHIFT.
>
> Use non-atomic bit-ops:
>  -Vcpu flags are checked and cleared atomically. Performance can be
>   improved with corresponding non-atomic versions since schedule.c
>   already has spin_locks in place.
>
> Suggested-by: Dario Faggioli 

It's better to add the link to the thread that has the suggestion.

> @@ -930,7 +936,7 @@ burn_budget(const struct scheduler *ops, struct rt_vcpu 
> *svc, s_time_t now)
>  if ( svc->cur_budget <= 0 )
>  {
>  svc->cur_budget = 0;
> -set_bit(__RTDS_depleted, >flags);
> +__set_bit(__RTDS_depleted, >flags);
>  }
>
>  /* TRACE */
> @@ -955,7 +961,7 @@ burn_budget(const struct scheduler *ops, struct rt_vcpu 
> *svc, s_time_t now)
>   * lock is grabbed before calling this function

The comment says "lock is grabbed before calling this function".
IIRC,  we use __ to represent that we grab the lock before call this function.
Then this change violates the convention.

>   */
>  static struct rt_vcpu *
> -__runq_pick(const struct scheduler *ops, const cpumask_t *mask)
> +runq_pick(const struct scheduler *ops, const cpumask_t *mask)
>  {
>  struct list_head *runq = rt_runq(ops);
>  struct list_head *iter;
> @@ -964,9 +970,9 @@ __runq_pick(const struct scheduler *ops, const cpumask_t 
> *mask)
>  cpumask_t cpu_common;
>  cpumask_t *online;
>
> -list_for_each(iter, runq)
> +list_for_each ( iter, runq )
>  {
> -iter_svc = __q_elem(iter);
> +iter_svc = q_elem(iter);
>
>  /* mask cpu_hard_affinity & cpupool & mask */
>  online = cpupool_domain_cpumask(iter_svc->vcpu->domain);
> @@ -1028,7 +1034,7 @@ rt_schedule(const struct scheduler *ops, s_time_t now, 
> bool_t tasklet_work_sched
>  }
>  else
>  {
> -snext = __runq_pick(ops, cpumask_of(cpu));
> +snext = runq_pick(ops, cpumask_of(cpu));
>  if ( snext == NULL )
>  snext = rt_vcpu(idle_vcpu[cpu]);
>



Meng

---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

[Xen-devel] [xen-unstable test] 94050: regressions - trouble: blocked/broken/fail/pass

2016-05-12 Thread osstest service owner

flight 94050 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94050/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl3 host-install(3) broken REGR. vs. 94021
 test-amd64-i386-xl-xsm3 host-install(3) broken REGR. vs. 94021
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 94021
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 94021
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 94021

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 94021
 build-amd64-rumpuserxen   6 xen-buildfail   like 94021
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94021
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94021
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94021
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94021
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94021

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c5ed88110cd1b72af643d7d9e255d587f2c90d3d
baseline version:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47

Last test of basis94021  2016-05-11 07:32:40 Z1 days
Testing same since94050  2016-05-12 02:19:56 Z1 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Olaf Hering 
  Paul Durrant 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64

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

2016-05-12 Thread osstest service owner

flight 94052 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94052/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  6 xen-boot  fail REGR. vs. 94018

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 libvirt  df4d908d30f59678efd636d2023b3e93f0d0591e
baseline version:
 libvirt  e5aecc2f800e8e14edd561dc5af4f763f040d842

Last test of basis94018  2016-05-11 04:21:08 Z1 days
Testing same since94052  2016-05-12 04:23:09 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Erik Skultety 
  John Ferlan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 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
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Not pushing.

(No revision log; it would be 445 lines long.)

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

[Xen-devel] Question about MMU update on HVM guest

2016-05-12 Thread AnhNN

Hi,

I have some questions about MMU update operation.
I add some logging in function *do_mmu_update* (in file
/xen/arch/x86/mm.c), and start Windows 7 32 bit HVM guest.
After guest started, I look at log and see that MMU update has been called
with every page of guest, with *pt_ower = 0* and *pg_owner = 1*. And with
every page, MMU update called 2 times. The first time, * page->count_info =
0x8002* after MMU update, but after that it decrease to
*0x8001* in a different function. At the second time,
*page->count_info
= 0x8002* after MMU update, and keep that value forever.

So the question is, why domain 0 have a reference to every pages of HVM
guest ?
And why in the second time of MMU update, count_info doesn't decrease to
*0x8001* ?

Thanks & Best Regards.

-- 
Nguyễn Ngọc Anh
Student - Course 53
Department of Computer Engineering - School of Information and
Communication Technology
Hanoi University Of Science And Technology.
Mobile: 0973402195
Email: ngocanh...@gmail.com 
Y!M: pancuro
Skype: ngocanh19890
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [qemu-upstream-4.4-testing test] 94048: tolerable FAIL - PUSHED

2016-05-12 Thread osstest service owner

flight 94048 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94048/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pv  17 guest-localmigrate/x10 fail in 94023 pass in 94048
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 94023 
pass in 94048
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 94023 
pass in 94048
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 94023
 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail pass in 
94023

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 83041

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuua2fd7eba04d4c69e4ee18a43eb6cf32aaffb3c98
baseline version:
 qemuu16169ab825a03262cd66382dc0b02caa0dbd636a

Last test of basis83041  2016-02-18 17:58:50 Z   84 days
Testing same since93978  2016-05-10 11:10:44 Z2 days3 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   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-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master

[Xen-devel] [xen-4.4-testing test] 94038: regressions - FAIL

2016-05-12 Thread osstest service owner

flight 94038 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94038/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail REGR. vs. 92242

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92242
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92242
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92242
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 92242

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 xen  ab6f8993136a10fee4336e0cbb90f491ce505212
baseline version:
 xen  24ebffa9f57a14b6f20376ae422b941715af9a4e

Last test of basis92242  2016-04-21 08:21:20 Z   21 days
Testing same since94001  2016-05-10 18:47:20 Z2 days2 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 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  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

2016-05-12 Thread Olaf Hering

On Thu, May 12, Olaf Hering wrote:

> One thing to fix it in staging-4.5 is to introduce a dummy device which
> handles a section named "kvm-tpr-opt". I already have a hack which does
> that, and the migration proceeds. I will propose a patch to deal with
> this part of the bug.

Something like shown below.

> Unfortunately later the VM appears to be alive, but nothing happens in
> it. I assume it gets no further interrupts. Guess I need help with this
> part of the bug.


Olaf

---
 hw/i386/Makefile.objs|1 
 hw/i386/xen44_kvmvapic.c |  147 +++
 xen-hvm.c|3 
 3 files changed, 151 insertions(+)

--- a/hw/i386/Makefile.objs
+++ b/hw/i386/Makefile.objs
@@ -5,6 +5,7 @@ obj-y += pc_sysfw.o
 obj-$(CONFIG_XEN) += ../xenpv/ xen/
 
 obj-y += kvmvapic.o
+obj-y += xen44_kvmvapic.o
 obj-y += acpi-build.o
 obj-y += bios-linker-loader.o
 hw/i386/acpi-build.o: hw/i386/acpi-build.c hw/i386/acpi-dsdt.hex \
--- /dev/null
+++ b/hw/i386/xen44_kvmvapic.c
@@ -0,0 +1,147 @@
+/*
+ * Copy of kvmvapic to allow migration from xen-4.4 qemu-xen with "kvm-tpr-opt"
+ *
+ * Copyright (C) 2007-2008 Qumranet Technologies
+ * Copyright (C) 2012  Jan Kiszka, Siemens AG
+ *
+ * This work is licensed under the terms of the GNU GPL version 2, or
+ * (at your option) any later version. See the COPYING file in the
+ * top-level directory.
+ */
+#include "sysemu/sysemu.h"
+#include "sysemu/cpus.h"
+#include "sysemu/kvm.h"
+#include "hw/i386/apic_internal.h"
+#include "hw/sysbus.h"
+#include "hw/xen/xen.h"
+
+typedef struct VAPICHandlers {
+uint32_t set_tpr;
+uint32_t set_tpr_eax;
+uint32_t get_tpr[8];
+uint32_t get_tpr_stack;
+} QEMU_PACKED VAPICHandlers;
+
+typedef struct GuestROMState {
+char signature[8];
+uint32_t vaddr;
+uint32_t fixup_start;
+uint32_t fixup_end;
+uint32_t vapic_vaddr;
+uint32_t vapic_size;
+uint32_t vcpu_shift;
+uint32_t real_tpr_addr;
+VAPICHandlers up;
+VAPICHandlers mp;
+} QEMU_PACKED GuestROMState;
+
+typedef struct VAPICROMState {
+SysBusDevice busdev;
+MemoryRegion io;
+MemoryRegion rom;
+uint32_t state;
+uint32_t rom_state_paddr;
+uint32_t rom_state_vaddr;
+uint32_t vapic_paddr;
+uint32_t real_tpr_addr;
+GuestROMState rom_state;
+size_t rom_size;
+bool rom_mapped_writable;
+} VAPICROMState;
+
+#define TYPE_XEN_KVMVAPIC "xen_kvmvapic" /* copy of "kvmvapic" */
+
+static void xen44_vapic_realize(DeviceState *dev, Error **errp)
+{
+fprintf(stderr, "%s(%u) dev %p\n", __func__, __LINE__, dev);
+}
+
+static int xen44_vapic_post_load(void *opaque, int version_id)
+{
+if (xen_enabled()) {
+int i;
+fprintf(stderr, "%s(%u) %p 0x%x\n", __func__, __LINE__, opaque, 
version_id);
+for (i = 12; i > 0; i--) {
+   sleep(1);
+fprintf(stderr, "%s(%u) sleep %d %ld\n", __func__, __LINE__, i, 
(long)getpid());
+   }
+}
+return 0;
+}
+
+static const VMStateDescription vmstate_handlers = {
+.name = "kvmvapic-handlers",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UINT32(set_tpr, VAPICHandlers),
+VMSTATE_UINT32(set_tpr_eax, VAPICHandlers),
+VMSTATE_UINT32_ARRAY(get_tpr, VAPICHandlers, 8),
+VMSTATE_UINT32(get_tpr_stack, VAPICHandlers),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_guest_rom = {
+.name = "kvmvapic-guest-rom",
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.fields = (VMStateField[]) {
+VMSTATE_UNUSED(8), /* signature */
+VMSTATE_UINT32(vaddr, GuestROMState),
+VMSTATE_UINT32(fixup_start, GuestROMState),
+VMSTATE_UINT32(fixup_end, GuestROMState),
+VMSTATE_UINT32(vapic_vaddr, GuestROMState),
+VMSTATE_UINT32(vapic_size, GuestROMState),
+VMSTATE_UINT32(vcpu_shift, GuestROMState),
+VMSTATE_UINT32(real_tpr_addr, GuestROMState),
+VMSTATE_STRUCT(up, GuestROMState, 0, vmstate_handlers, VAPICHandlers),
+VMSTATE_STRUCT(mp, GuestROMState, 0, vmstate_handlers, VAPICHandlers),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const VMStateDescription vmstate_xen44_vapic = {
+.name = "kvm-tpr-opt",  /* compatible with qemu-kvm VAPIC */
+.version_id = 1,
+.minimum_version_id = 1,
+.minimum_version_id_old = 1,
+.post_load = xen44_vapic_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_STRUCT(rom_state, VAPICROMState, 0, vmstate_guest_rom,
+   GuestROMState),
+VMSTATE_UINT32(state, VAPICROMState),
+VMSTATE_UINT32(real_tpr_addr, VAPICROMState),
+VMSTATE_UINT32(rom_state_vaddr, VAPICROMState),
+VMSTATE_UINT32(vapic_paddr, VAPICROMState),
+VMSTATE_UINT32(rom_state_paddr, VAPICROMState),
+VMSTATE_END_OF_LIST()
+}
+};
+

[Xen-devel] [linux-4.1 baseline-only test] 44410: regressions - trouble: blocked/broken/fail/pass

2016-05-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 44410 linux-4.1 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44410/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   3 host-install(3) broken REGR. vs. 44375
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44375
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44375
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail REGR. 
vs. 44375
 test-amd64-i386-xl-qemut-debianhvm-amd64 14 guest-saverestore.2 fail REGR. vs. 
44375

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 44375
 build-amd64-rumpuserxen   6 xen-buildfail   like 44375
 build-i386-rumpuserxen6 xen-buildfail   like 44375
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 44375

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux648d744eff1aedea4ffe49dfca07aa465669e1f4
baseline version:
 linux54419e3efcd6677e4b0841666e2fc605d2e5df86

Last test of basis44375  2016-04-29 23:32:00 Z   12 days
Testing same since44410  2016-05-12 12:24:13 Z0 days1 attempts


People who touched revisions under test:
  Alex Deucher 
  Andrew Morton 
  Anton Blanchard 
  Bastien Nocera 
  cp...@redhat.com 
  Dave Airlie 
  David S. Miller 
  Dmitry Ivanov 
  Dmitry Ivanov 
  Dmitry Torokhov 
  Dominik Dingel 
  Emmanuel Grumbach 
  Felipe Balbi 
  Herbert Xu 
  Hongzhou Yang 
  Huacai Chen 
  Ingo Molnar 
  Jan Beulich 
  Jani Nikula 
  Johannes Berg 
  JÃ©rÃ´me Glisse 
  Lars-Peter Clausen 
  Linus Torvalds 
  Linus Walleij 
  Lu, Han 
  Lyude 
  Martin Schwidefsky 
  Mauro Carvalho Chehab

[Xen-devel] [ovmf test] 94046: regressions - FAIL

2016-05-12 Thread osstest service owner

flight 94046 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94046/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf fca117fd3f598ad931318bceabbd4718fafc1fc7
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  156 days
Failing since 65593  2015-12-08 23:44:51 Z  155 days  254 attempts
Testing same since94046  2016-05-11 21:27:11 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin HÃ¤user 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann 
  MichaÅ Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Sunny Wang 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng

[Xen-devel] [qemu-upstream-4.3-testing test] 94044: trouble: blocked/broken

2016-05-12 Thread osstest service owner

flight 94044 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94044/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   96 days
Testing same since93977  2016-05-10 11:09:16 Z2 days3 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked

[Xen-devel] [xen-unstable-smoke test] 94060: tolerable all pass - PUSHED

2016-05-12 Thread osstest service owner

flight 94060 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94060/

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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  cd2cd109e7db3a7e689c20b8991d41115ed5bea6
baseline version:
 xen  744fe0347d584f8b80b91ece93ef87e903c41bfa

Last test of basis94058  2016-05-12 13:02:19 Z0 days
Testing same since94060  2016-05-12 17:02:40 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Jan Beulich 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=cd2cd109e7db3a7e689c20b8991d41115ed5bea6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
cd2cd109e7db3a7e689c20b8991d41115ed5bea6
+ branch=xen-unstable-smoke
+ revision=cd2cd109e7db3a7e689c20b8991d41115ed5bea6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xcd2cd109e7db3a7e689c20b8991d41115ed5bea6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local

[Xen-devel] [TESTDAY] Test report - xl sched-rtds

2016-05-12 Thread Chong Li

* Hardware:
CPU: Intel Core2 Quad Q9400
Total Memory: 2791088 kB

* Software:
Ubuntu 14.04
Linux kernel: 3.13.0-68

* Guest operating systems:
Ubuntu 14.04 (PV)

* Functionality tested:
xl sched-rtds (for set/get per-VCPU parameters)

* Comments:
All examples about "xl sched-rtds" in xl mannual page

have been tested,
and all run successfully.

If users type in wrong parameters (e.g., budget > period), the
error/warnning messages
are returned correctly as well.

Chong Li


-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

2016-05-12 Thread osstest service owner

flight 94037 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94037/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat fail REGR. vs. 93937
 test-armhf-armhf-libvirt-qcow2  6 xen-bootfail REGR. vs. 93937

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 93937
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93937
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93937

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuubfc766d38e1fae5767d43845c15c79ac8fa6d6af
baseline version:
 qemuu860a3b34854d8abe9af9f1eb584691de926ce897

Last test of basis93937  2016-05-09 23:45:45 Z2 days
Testing same since94037  2016-05-11 16:12:23 Z1 days1 attempts


People who touched revisions under test:
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 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
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm

Re: [Xen-devel] [PATCH-for-4.7 1/2] xendriverdomain: use POSIX sh and not bash

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 04:56:30PM +0100, Wei Liu wrote:
> On Thu, May 12, 2016 at 10:29:29AM -0500, Doug Goldstein wrote:
> > The script doesn't use any bash-isms and works fine with BusyBox's ash.
> > 
> > Signed-off-by: Doug Goldstein 
> 
> Acked-by: Wei Liu 
> Release-acked-by: Wei Liu 
> 

Pushed.

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

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

2016-05-12 Thread Sahita, Ravi



>-Original Message-
>From: Tamas K Lengyel [mailto:tamas.k.leng...@gmail.com]
>Sent: Thursday, May 12, 2016 8:54 AM
>To: Wei Liu 
>Cc: Big Strong ; Sahita, Ravi ;
>White, Edmund H ; Jan Beulich
>; Xen-devel 
>Subject: Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
>
>On Thu, May 12, 2016 at 9:17 AM, Wei Liu  wrote:
>> On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote:
>>> I'm still not very clear why would do_altp2m_op change the domain to
>>> current domain (which is dom0 in my case) when the cmd is
>>> HVMOP_altp2m_vcpu_enable_notify
>>>
>=743289d0296268fe6bad64531a24d8053afeb062#l6198>.
>>> As to my case, it would prevent the dom0 to set the #ve info page for
>>> other domUs because the check of is_hvm_domain would fail
>>> >> vm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6204>and
>>> the function will returns directly.
>>>
>>
>> Maybe the intent of that HVMOP is to get called directly by the guest
>> that is interested in such event?
>>
>> I looks like a natural restriction to me because the vcpu needs to set
>> up handler for #ve AIUI. It's not likely that Dom0 can do this for
>> arbitrary guest.
>>
>
>That sounds like a reasonable explanation. When I wrote the libxc wrapper I
>pretty much just exposed what was available based on the hypervisor side. As my
>off-hand comment in the code states I did find it odd that this op works on
>current vCPU. So if it's actually issued from the domain itself it would make 
>sense.
>So with that we should probably remove the libxc wrapper for this hvmop as it
>won't work/not designed to be issued from dom0 and should add some
>comments in the header explaining its intended use.

Agree with that (and Wei's explanation is accurate).
Ravi

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

Re: [Xen-devel] [PATCH-for-4.7 1/2] xendriverdomain: use POSIX sh and not bash

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 10:29:29AM -0500, Doug Goldstein wrote:
> The script doesn't use any bash-isms and works fine with BusyBox's ash.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Wei Liu 
Release-acked-by: Wei Liu 

> ---
>  tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
> b/tools/hotplug/Linux/init.d/xendriverdomain.in
> index 5fd4e9a..8d4592a 100644
> --- a/tools/hotplug/Linux/init.d/xendriverdomain.in
> +++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
> @@ -1,4 +1,4 @@
> -#!/bin/bash
> +#!/bin/sh
>  #
>  # xendriverdomainScript to start services needed in a Xen driver domain
>  #
> -- 
> 2.7.4 (Apple Git-66)
> 

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

Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for control ring

2016-05-12 Thread Paul Durrant

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> David Miller
> Sent: 12 May 2016 16:52
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org; net...@vger.kernel.org
> Subject: Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for
> control ring
> 
> From: Paul Durrant 
> Date: Wed, 11 May 2016 16:16:26 +0100
> 
> > My recent patch to import an up-to-date include/xen/interface/io/netif.h
> > from the Xen Project brought in the necessary definitions to support the
> > new control shared ring and protocol. This patch series updates xen-
> netback
> > to support the new ring.
> 
> I lost my copy of your V3 cover letter, so I'm replying to this one, but
> be sure I tested V3 :-)
> 
> This doesn't build, please fix:
> 
> ERROR: "init_rcu_head" [drivers/net/xen-netback/xen-netback.ko]
> undefined!
> ERROR: "destroy_rcu_head" [drivers/net/xen-netback/xen-netback.ko]
> undefined!
> 

OK.

  Paul

> ___
> 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/2] xendriverdomain: don't depend on legacy /proc/xen

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 10:29:30AM -0500, Doug Goldstein wrote:
> xl devd prefers to use /dev/xen/ instead of /proc/xen so the init script
> should use the new interface as well and drop the legacy interface. To
> check for support this uses /sys/hypervisor which has been present since
> 2.6.18 Xen kernels. Fix bad whitespace at the same time.
> 
> Signed-off-by: Doug Goldstein 
> ---
>  tools/hotplug/Linux/init.d/xendriverdomain.in | 19 ---
>  1 file changed, 4 insertions(+), 15 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
> b/tools/hotplug/Linux/init.d/xendriverdomain.in
> index 8d4592a..830aa5b 100644
> --- a/tools/hotplug/Linux/init.d/xendriverdomain.in
> +++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
> @@ -27,23 +27,12 @@ test -f $xendriverdomain_config/xendriverdomain && . 
> $xendriverdomain_config/xen
>  XLDEVD_PIDFILE=/var/run/xldevd.pid
>  
>  # not running in Xen dom0 or domU
> -if ! test -d /proc/xen ; then
> +if ! grep -q '^xen' /sys/hypervisor/type ; then
>   exit 0
>  fi
>  
> -# mount xenfs in dom0 or domU with a pv_ops kernel
> -if test "x$1" = xstart && \
> -   ! test -f /proc/xen/capabilities && \
> -   ! grep '^xenfs ' /proc/mounts >/dev/null;
> -then
> - mount -t xenfs xenfs /proc/xen
> -fi

This unilaterally remove mounting xenfs. We need to keep mounting it
because some applications might use those legacy devices.

I do think we need to avoid breaking old stuff, especially when it is
not to hard to achieve.

> -
>  # run this script only in domU:
> -# no capabilities file in xenlinux domU kernel
> -# empty capabilities file in pv_ops domU kernel
> -if ! test -f /proc/xen/capabilities || \
> -   grep -q "control_d" /proc/xen/capabilities ; then
> +if grep -q '----' /sys/hypervisor/uuid; then

Here you're relying on the fact that dom0 uuid is all zeros. I don't
think this is documented in Linux, so you can't do it here.

>   exit 0
>  fi
>  
> @@ -52,7 +41,7 @@ do_start () {
>   ${sbindir}/xl devd --pidfile=$XLDEVD_PIDFILE $XLDEVD_ARGS
>  }
>  do_stop () {
> -echo Stopping xl devd...
> +echo Stopping xl devd...

Indentation looks wrong. Should use tab here.

>   if read 2>/dev/null <$XLDEVD_PIDFILE pid; then
>   kill $pid
>   while kill -9 $pid >/dev/null 2>&1; do sleep 1; done
> @@ -71,7 +60,7 @@ case "$1" in
>   echo >&2 'Reload not available; use force-reload'; exit 1
>   ;;
>force-reload|restart)
> -do_stop
> +do_stop

Ditto.

>   do_start
>   ;;
>*)
> -- 
> 2.7.4 (Apple Git-66)
> 

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

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

2016-05-12 Thread Tamas K Lengyel

On Thu, May 12, 2016 at 9:17 AM, Wei Liu  wrote:
> On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote:
>> I'm still not very clear why would do_altp2m_op change the domain to
>> current domain (which is dom0 in my case) when the cmd is
>> HVMOP_altp2m_vcpu_enable_notify
>> .
>> As to my case, it would prevent the dom0 to set the #ve info page for other
>> domUs because the check of is_hvm_domain would fail
>> and
>> the function will returns directly.
>>
>
> Maybe the intent of that HVMOP is to get called directly by the guest
> that is interested in such event?
>
> I looks like a natural restriction to me because the vcpu needs to set
> up handler for #ve AIUI. It's not likely that Dom0 can do this for
> arbitrary guest.
>

That sounds like a reasonable explanation. When I wrote the libxc
wrapper I pretty much just exposed what was available based on the
hypervisor side. As my off-hand comment in the code states I did find
it odd that this op works on current vCPU. So if it's actually issued
from the domain itself it would make sense. So with that we should
probably remove the libxc wrapper for this hvmop as it won't work/not
designed to be issued from dom0 and should add some comments in the
header explaining its intended use.

Tamas

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

Re: [Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for control ring

2016-05-12 Thread David Miller

From: Paul Durrant 
Date: Wed, 11 May 2016 16:16:26 +0100

> My recent patch to import an up-to-date include/xen/interface/io/netif.h
> from the Xen Project brought in the necessary definitions to support the
> new control shared ring and protocol. This patch series updates xen-netback
> to support the new ring.

I lost my copy of your V3 cover letter, so I'm replying to this one, but
be sure I tested V3 :-)

This doesn't build, please fix:

ERROR: "init_rcu_head" [drivers/net/xen-netback/xen-netback.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/net/xen-netback/xen-netback.ko] undefined!

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

[Xen-devel] live migrating hvm from 4.4 to 4.5 fails due to kvmvapic

2016-05-12 Thread Olaf Hering

Migrating a HVM guest from staging-4.4 to staging-4.5 fails:

# cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
char device redirected to /dev/pts/4 (label serial0)
xen_ram_alloc: do not alloc f80 bytes of ram at 0 when runstate is INMIGRATE
xen_ram_alloc: do not alloc 80 bytes of ram at f80 when runstate is 
INMIGRATE
xen_ram_alloc: do not alloc 1 bytes of ram at 1000 when runstate is 
INMIGRATE
xen_ram_alloc: do not alloc 4 bytes of ram at 1001 when runstate is 
INMIGRATE
Unknown savevm section or instance 'kvm-tpr-opt' 0
qemu-system-i386: load of migration failed: Invalid argument


Initially I thought we broke our sles12 xen, but for some reason xen.git fails
in the very same way. In 4.4 kvmvapic gets enabled, it gets migrated in the
"kvm-tpr-opt" VMStateDescription. The 4.5 qemu does not know about it because
'kvmvapic' is not enabled. As a result the entire savevm stream is rejected.

One thing to fix it in staging-4.5 is to introduce a dummy device which
handles a section named "kvm-tpr-opt". I already have a hack which does
that, and the migration proceeds. I will propose a patch to deal with
this part of the bug.

Unfortunately later the VM appears to be alive, but nothing happens in
it. I assume it gets no further interrupts. Guess I need help with this
part of the bug.


domU.cfg looks like this:

name="x"
memory=256
serial="pty"
builder="hvm"
boot="cd"
disk=[
'file:/disk0.raw,hda,w',
'file:/some.iso,hdc:cdrom,r',
]
vif=[
'bridge=br0'
]
keymap="de"
vfb = [
'type=vnc,vncunused=1,keymap=de'
]
usb=1
usbdevice='tablet'


Olaf

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

[Xen-devel] [PATCH-for-4.7 1/2] xendriverdomain: use POSIX sh and not bash

2016-05-12 Thread Doug Goldstein

The script doesn't use any bash-isms and works fine with BusyBox's ash.

Signed-off-by: Doug Goldstein 
---
 tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
b/tools/hotplug/Linux/init.d/xendriverdomain.in
index 5fd4e9a..8d4592a 100644
--- a/tools/hotplug/Linux/init.d/xendriverdomain.in
+++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 #
 # xendriverdomainScript to start services needed in a Xen driver domain
 #
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] Please reconsider bug 26

2016-05-12 Thread Wei Liu

Hello

On Wed, May 11, 2016 at 04:51:41PM +0200, Sébastien Chaumat wrote:
> Hello,
> 
>   http://bugs.xenproject.org/xen/bug/26 is nearly 3yrs old.
> 
> (bassically one can attach the same vbd rw to 2 domUs with xl without
> warning )
> 
>  Combined with a distribution behavior  like
> 
> https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1572446
> 
>  (a trailing domu.cfg~ backup file will be blindly used to launch twice a
> domU config with only the name changed)
> 
>  leads to real fun  (namely filesystem corruption)
> 
>  Recalling early discussion here about xen philosophy, isolation  accross
> domUs should be the default. Clearly xl does not provide vbd isolation by
> default.
> 
>  Would you mind considering implementing vbd usage detection in xl ?
> 

I think xen 4.7 (which to be released soon) should fix one aspect of the
issue. Toolstack won't be able to attach same vbds twice.

And looking at the block script for Linux, it does check for "!".

Are you able to test one of the RCs (latest one RC2) for xen 4.7 to see
if it fixes the bug?

Unfortunately the fixes might be too complicated to backport.

Wei.


> Thanks,
> Sebastien

> ___
> 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

[Xen-devel] [linux-3.14 baseline-only test] 44408: regressions - FAIL

2016-05-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 44408 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44408/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
44388

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44388
 build-amd64-rumpuserxen   6 xen-buildfail   like 44388
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 44388
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 44388
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44388

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux1c767107ef341cdc080d44d3ee1c9ca1b6957ce0
baseline version:
 linux48763742b1bceb119b04656b8dd06e0617dfa89a

Last test of basis44388  2016-05-05 04:53:57 Z7 days
Testing same since44408  2016-05-12 04:24:42 Z0 days1 attempts


People who touched revisions under test:
  Andrew Morton 
  Andrey Gelman 
  Andy Lutomirski  # On a Dell XPS 13 9350
  Anton Blanchard 
  Antonio Quartulli 
  Arnd Bergmann 
  Behan Webster 
  Bob Moore 
  Chen Yu 
  Chunyu Hu 
  Dan Streetman 
  Dinh Nguyen 
  Dirk Behme 
  Dmitry Torokhov 
  Greg Kroah-Hartman 
  Gregor Boirie 
  Haibo Chen 
  Igor Grinberg 
  Ingo Molnar 
  Jan-Simon MÃ¶ller 
  Jasem Mutlaq 
  Joe Perches 
  Johan Hovold 
  Jonathan Cameron 
  Julian Anastasov 
  Kevin Hilman 
  Knut Wohlrab 
  Krzysztof Kozlowski 
  Linus LÃ¼ssing 
  Linus Torvalds 
  Linus Walleij 
  Lv Zheng 
  Marco Angaroni 
  Marek Lindner 
  Markus Pargmann 
  Martin K. Petersen 
  Mathias Krause 
  Matt Fleming 
  Michael Ellerman 
  Mike Manning 
  Oleksij Rempel 
  Paolo Bonzini 
  Prarit Bhargava 
  Rafael J. Wysocki 
  Sascha Hauer 
  Sasha Levin 
  Simon Horman 
  Stephen Boyd 
  Steven Rostedt 
  Sven Eckelmann 
  Thomas Gleixner 
  Wang YanQing 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops

[Xen-devel] [PATCH 2/2] xendriverdomain: don't depend on legacy /proc/xen

2016-05-12 Thread Doug Goldstein

xl devd prefers to use /dev/xen/ instead of /proc/xen so the init script
should use the new interface as well and drop the legacy interface. To
check for support this uses /sys/hypervisor which has been present since
2.6.18 Xen kernels. Fix bad whitespace at the same time.

Signed-off-by: Doug Goldstein 
---
 tools/hotplug/Linux/init.d/xendriverdomain.in | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
b/tools/hotplug/Linux/init.d/xendriverdomain.in
index 8d4592a..830aa5b 100644
--- a/tools/hotplug/Linux/init.d/xendriverdomain.in
+++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
@@ -27,23 +27,12 @@ test -f $xendriverdomain_config/xendriverdomain && . 
$xendriverdomain_config/xen
 XLDEVD_PIDFILE=/var/run/xldevd.pid
 
 # not running in Xen dom0 or domU
-if ! test -d /proc/xen ; then
+if ! grep -q '^xen' /sys/hypervisor/type ; then
exit 0
 fi
 
-# mount xenfs in dom0 or domU with a pv_ops kernel
-if test "x$1" = xstart && \
-   ! test -f /proc/xen/capabilities && \
-   ! grep '^xenfs ' /proc/mounts >/dev/null;
-then
-   mount -t xenfs xenfs /proc/xen
-fi
-
 # run this script only in domU:
-# no capabilities file in xenlinux domU kernel
-# empty capabilities file in pv_ops domU kernel
-if ! test -f /proc/xen/capabilities || \
-   grep -q "control_d" /proc/xen/capabilities ; then
+if grep -q '----' /sys/hypervisor/uuid; then
exit 0
 fi
 
@@ -52,7 +41,7 @@ do_start () {
${sbindir}/xl devd --pidfile=$XLDEVD_PIDFILE $XLDEVD_ARGS
 }
 do_stop () {
-echo Stopping xl devd...
+echo Stopping xl devd...
if read 2>/dev/null <$XLDEVD_PIDFILE pid; then
kill $pid
while kill -9 $pid >/dev/null 2>&1; do sleep 1; done
@@ -71,7 +60,7 @@ case "$1" in
echo >&2 'Reload not available; use force-reload'; exit 1
;;
   force-reload|restart)
-do_stop
+do_stop
do_start
;;
   *)
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH v3 2/2] tests/mem-sharing: Add bulk option to memshrtool

2016-05-12 Thread Tamas K Lengyel

Add the bulk option to the test tool to perform complete deduplication
between domains.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
---
 tools/tests/mem-sharing/memshrtool.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/tools/tests/mem-sharing/memshrtool.c 
b/tools/tests/mem-sharing/memshrtool.c
index 437c7c9..3e8f467 100644
--- a/tools/tests/mem-sharing/memshrtool.c
+++ b/tools/tests/mem-sharing/memshrtool.c
@@ -24,6 +24,8 @@ static int usage(const char* prog)
 printf("  nominate- Nominate a page for sharing.\n");
 printf("  share  
\n");
 printf("  - Share two pages.\n");
+printf("  bulk  \n");
+printf("  - Share all pages between domains.\n");
 printf("  unshare - Unshare a page by grabbing a writable 
map.\n");
 printf("  add-to-physmap 
\n");
 printf("  - Populate a page in a domain with a 
shared page.\n");
@@ -180,6 +182,26 @@ int main(int argc, const char** argv)
 }
 printf("Audit returned %d errors.\n", rc);
 }
+else if( !strcasecmp(cmd, "bulk") )
+{
+domid_t sdomid, cdomid;
+int rc;
+unsigned long shared;
+
+if( argc != 4 )
+return usage(argv[0]);
+
+sdomid = strtol(argv[2], NULL, 0);
+cdomid = strtol(argv[3], NULL, 0);
 
+rc = xc_memshr_bulk_share(xch, sdomid, cdomid, );
+if ( rc < 0 )
+{
+printf("error executing xc_memshr_bulk_dedup: %s\n", 
strerror(errno));
+return rc;
+}
+
+printf("Successfully shared %lu pages between the domains\n", shared);
+}
 return 0;
 }
-- 
2.8.1


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

[Xen-devel] [xen-4.6-testing test] 94036: trouble: broken/fail/pass

2016-05-12 Thread osstest service owner

flight 94036 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94036/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   3 host-install(3) broken REGR. vs. 93932
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
93932

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  426783e661da942f8b7871613479db4daa6a16c3
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z2 days
Failing since 94000  2016-05-10 18:10:33 Z1 days2 attempts
Testing same since94036  2016-05-11 15:51:26 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops

[Xen-devel] [PATCH v3 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

2016-05-12 Thread Tamas K Lengyel

Currently mem-sharing can be performed on a page-by-page base from the control
domain. However, when completely deduplicating (cloning) a VM, this requires
at least 3 hypercalls per page. As the user has to loop through all pages up
to max_gpfn, this process is very slow and wasteful.

This patch introduces a new mem_sharing memop for bulk deduplication where
the user doesn't have to separately nominate each page in both the source and
destination domain, and the looping over all pages happen in the hypervisor.
This significantly reduces the overhead of completely deduplicating entire
domains.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Ian Jackson 
George Dunlap 
Jan Beulich 
Andrew Cooper 

v3: Bail if domains are not paused
Rename bulk_share struct to just bulk
Return -ENOMEM error if nomination fails
Return total number of shared pages (not keeping separate count)
v2: Stash hypercall continuation start point in xen_mem_sharing_op_t
Return number of successfully shared pages in xen_mem_sharing_op_t
---
 tools/libxc/include/xenctrl.h |  15 +++
 tools/libxc/xc_memshr.c   |  19 
 xen/arch/x86/mm/mem_sharing.c | 100 ++
 xen/include/public/memory.h   |  14 +-
 4 files changed, 147 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index dc54612..29ff13e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2327,6 +2327,21 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
 domid_t client_domain,
 unsigned long client_gfn);
 
+/* Allows to deduplicate the entire memory of a client domain in bulk. Using
+ * this function is equivalent of calling xc_memshr_nominate_gfn for each gfn
+ * in the two domains followed by xc_memshr_share_gfns. If successfull,
+ * returns the number of shared pages in 'shared'. Both domains must be paused.
+ *
+ * May fail with -EINVAL if the source and client domain have different
+ * memory size or if memory sharing is not enabled on either of the domains.
+ * May also fail with -ENOMEM if there isn't enough memory available to store
+ * the sharing metadata before deduplication can happen.
+ */
+int xc_memshr_bulk_share(xc_interface *xch,
+ domid_t source_domain,
+ domid_t client_domain,
+ uint64_t *shared);
+
 /* Debug calls: return the number of pages referencing the shared frame backing
  * the input argument. Should be one or greater. 
  *
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index deb0aa4..71350d2 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -181,6 +181,25 @@ int xc_memshr_add_to_physmap(xc_interface *xch,
 return xc_memshr_memop(xch, source_domain, );
 }
 
+int xc_memshr_bulk_share(xc_interface *xch,
+ domid_t source_domain,
+ domid_t client_domain,
+ uint64_t *shared)
+{
+int rc;
+xen_mem_sharing_op_t mso;
+
+memset(, 0, sizeof(mso));
+
+mso.op = XENMEM_sharing_op_bulk_share;
+mso.u.bulk.client_domain = client_domain;
+
+rc = xc_memshr_memop(xch, source_domain, );
+if ( !rc && shared ) *shared = mso.u.bulk.shared;
+
+return rc;
+}
+
 int xc_memshr_domain_resume(xc_interface *xch,
 domid_t domid)
 {
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a522423..06176aa 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1294,6 +1294,43 @@ int relinquish_shared_pages(struct domain *d)
 return rc;
 }
 
+static int bulk_share(struct domain *d, struct domain *cd, unsigned long max,
+  struct mem_sharing_op_bulk *bulk)
+{
+int rc;
+shr_handle_t sh, ch;
+
+while( bulk->start <= max )
+{
+rc = mem_sharing_nominate_page(d, bulk->start, 0, );
+if ( rc == -ENOMEM )
+break;
+if ( !rc )
+{
+rc = mem_sharing_nominate_page(cd, bulk->start, 0, );
+if ( rc == -ENOMEM )
+break;
+if ( !rc )
+mem_sharing_share_pages(d, bulk->start, sh, cd, bulk->start, 
ch);
+}
+
+++(bulk->start);
+
+/* Check for continuation if it's not the last iteration. */
+if ( bulk->start < max && hypercall_preempt_check() )
+{
+rc = 1;
+break;
+}
+}
+
+/* We only propagate -ENOMEM so reset rc here */
+if ( rc < 0 && rc != -ENOMEM )
+rc = 0;
+
+return rc;
+}
+
 int mem_sharing_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_sharing_op_t) arg)
 {
 int rc;
@@ -1468,6 +1505,69 @@ int

Re: [Xen-devel] [PATCH v5 2/3] xen: write information about supported backends

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 04:13:40PM +0200, Juergen Gross wrote:
> Add a Xenstore directory for each supported pv backend. This will allow
> Xen tools to decide which backend type to use in case there are
> multiple possibilities.
> 
> The information is added under
> /local/domain//device-model//backends
> before the "running" state is written to Xenstore. Using a directory
> for each backend enables us to add parameters for specific backends
> in the future.
> 
> This interface is documented in the Xen source repository in the file
> docs/misc/qemu-backends.txt
> 
> In order to reuse the Xenstore directory creation already present in
> hw/xen/xen_devconfig.c move the related functions to
> hw/xen/xen_backend.c where they fit better.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Anthony PERARD 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 1/3] xen: introduce dummy system device

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 04:13:39PM +0200, Juergen Gross wrote:
> Introduce a new dummy system device serving as parent for virtual
> buses. This will enable new pv backends to introduce virtual buses
> which are removable again opposed to system buses which are meant
> to stay once added.
> 
> Signed-off-by: Juergen Gross 
> Acked-by: Anthony PERARD 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [libvirt] [PATCH 1/3] libxl: switch to using libxl_domain_create_restore from v4.4 API

2016-05-12 Thread Jim Fehlig

Olaf Hering wrote:
> On Wed, May 11, Jim Fehlig wrote:
> 
>> https://www.redhat.com/archives/libvir-list/2016-May/msg00686.html
> 
> Perhaps configure.ac should be changed to reject libxl upfront.

Yes, good idea.

> It looks
> like the assignment of LIBXL_CFLAGS should be moved up, so that
> AC_CHECK_LIB gets the -DLIBXL_API_VERSION as well. I will provide a
> patch for that.

Ok, thanks for volunteering!

Regards,
Jim

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

Re: [Xen-devel] [PATCH] x86/PoD: skip eager reclaim when possible

2016-05-12 Thread George Dunlap

On 12/05/16 16:08, Jan Beulich wrote:
 On 12.05.16 at 16:40,  wrote:
>> On 10/05/16 14:44, Jan Beulich wrote:
>>> Reclaiming pages is pointless when the cache can already satisfy all
>>> outstanding PoD entries, and doing reclaims in that case can be very
>>> harmful to performance when that memory gets used by the guest, but
>>> only to store zeroes there.
>>>
>>> Signed-off-by: Jan Beulich 
>>
>> Sorry for the delay.  Just one question...
>>
>>>
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -1027,7 +1027,6 @@ static void pod_eager_record(struct p2m_
>>>  {
>>>  struct pod_mrp_list *mrp = >pod.mrp;
>>>  
>>> -ASSERT(mrp->list[mrp->idx] == INVALID_GFN);
>>>  ASSERT(gfn != INVALID_GFN);
>>
>> What's this for?
> 
> The deletion of the ASSERT()? Since we no longer always insert a
> GFN through pod_eager_reclaim(), we also can no longer assume
> all (used) entries hold a valid GFN.

Oh, right.  Should have taken a closer look, sorry for the noise:

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote:
> I'm still not very clear why would do_altp2m_op change the domain to
> current domain (which is dom0 in my case) when the cmd is
> HVMOP_altp2m_vcpu_enable_notify
> .
> As to my case, it would prevent the dom0 to set the #ve info page for other
> domUs because the check of is_hvm_domain would fail
> and
> the function will returns directly.
> 

Maybe the intent of that HVMOP is to get called directly by the guest
that is interested in such event?

I looks like a natural restriction to me because the vcpu needs to set
up handler for #ve AIUI. It's not likely that Dom0 can do this for
arbitrary guest.

Wei.

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

Re: [Xen-devel] [PATCH] x86/PoD: skip eager reclaim when possible

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 16:40,  wrote:
> On 10/05/16 14:44, Jan Beulich wrote:
>> Reclaiming pages is pointless when the cache can already satisfy all
>> outstanding PoD entries, and doing reclaims in that case can be very
>> harmful to performance when that memory gets used by the guest, but
>> only to store zeroes there.
>> 
>> Signed-off-by: Jan Beulich 
> 
> Sorry for the delay.  Just one question...
> 
>> 
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -1027,7 +1027,6 @@ static void pod_eager_record(struct p2m_
>>  {
>>  struct pod_mrp_list *mrp = >pod.mrp;
>>  
>> -ASSERT(mrp->list[mrp->idx] == INVALID_GFN);
>>  ASSERT(gfn != INVALID_GFN);
> 
> What's this for?

The deletion of the ASSERT()? Since we no longer always insert a
GFN through pod_eager_reclaim(), we also can no longer assume
all (used) entries hold a valid GFN.

Jan


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

[Xen-devel] [xen-unstable-smoke test] 94058: tolerable all pass - PUSHED

2016-05-12 Thread osstest service owner

flight 94058 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94058/

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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  744fe0347d584f8b80b91ece93ef87e903c41bfa
baseline version:
 xen  c5ed88110cd1b72af643d7d9e255d587f2c90d3d

Last test of basis94043  2016-05-11 19:03:49 Z0 days
Testing same since94058  2016-05-12 13:02:19 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=744fe0347d584f8b80b91ece93ef87e903c41bfa
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
744fe0347d584f8b80b91ece93ef87e903c41bfa
+ branch=xen-unstable-smoke
+ revision=744fe0347d584f8b80b91ece93ef87e903c41bfa
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x744fe0347d584f8b80b91ece93ef87e903c41bfa = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 16:28,  wrote:
> On May 10, 2016 2:54 PM, Jan Beulich  wrote:
>> >>> On 10.05.16 at 05:41,  wrote:
>> > On May 10, 2016 12:14 AM, Jan Beulich  wrote:
>> >> >>> On 06.05.16 at 10:54,  wrote:
>> For DomU the solution seems quite obvious: Only log a message if the domain
>> is not already marked crashed.
> 
> Jan, I am still confused about  this sentence and your another sentence ( 
> _as said_ also avoid logging any message for already dying domains).

The two say the same, so I don't see what you're confused about.
Please be more precise.

>>  For Dom0 you'll need to get a little more
>> creative (but by leveraging the fact that there's only one in the system, 
> this
>> can't be too difficult a problem to solve:
>> e.g. "manually" rate limit these messages - see printk_ratelimit() et al).
>> 
> 
> Reading this thread again and again, sorry, I am still inclined to:
> 
> +rc = hd->platform_ops->unmap_page(d, gfn);
> +
> +if ( unlikely(rc) )
> +{
> +if ( printk_ratelimit() )
> +printk(XENLOG_ERR
> +   "dom%d: IOMMU unmapping gfn %#lx failed %d.",
> +   d->domain_id, gfn, rc);
> +
> +if ( !is_hardware_domain(d) )
> +domain_crash(d);
> +}
> +
> +return rc;

This is certainly better than unconditional logging, but will still
produce more than one message per crashed guest (or for
Dom0) on a batch of unmaps.

Jan


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

Re: [Xen-devel] [PATCH] x86/PoD: skip eager reclaim when possible

2016-05-12 Thread George Dunlap

On 10/05/16 14:44, Jan Beulich wrote:
> Reclaiming pages is pointless when the cache can already satisfy all
> outstanding PoD entries, and doing reclaims in that case can be very
> harmful to performance when that memory gets used by the guest, but
> only to store zeroes there.
> 
> Signed-off-by: Jan Beulich 

Sorry for the delay.  Just one question...

> 
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -1027,7 +1027,6 @@ static void pod_eager_record(struct p2m_
>  {
>  struct pod_mrp_list *mrp = >pod.mrp;
>  
> -ASSERT(mrp->list[mrp->idx] == INVALID_GFN);
>  ASSERT(gfn != INVALID_GFN);

What's this for?

 -George


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

Re: [Xen-devel] [PATCH v4 02/10] IOMMU: handle IOMMU mapping and unmapping failures

2016-05-12 Thread Xu, Quan

On May 10, 2016 2:54 PM, Jan Beulich  wrote:
> >>> On 10.05.16 at 05:41,  wrote:
> > On May 10, 2016 12:14 AM, Jan Beulich  wrote:
> >> >>> On 06.05.16 at 10:54,  wrote:
> For DomU the solution seems quite obvious: Only log a message if the domain
> is not already marked crashed.

Jan, I am still confused about  this sentence and your another sentence ( _as 
said_ also avoid logging any message for already dying domains).

>  For Dom0 you'll need to get a little more
> creative (but by leveraging the fact that there's only one in the system, this
> can't be too difficult a problem to solve:
> e.g. "manually" rate limit these messages - see printk_ratelimit() et al).
> 

Reading this thread again and again, sorry, I am still inclined to:

+rc = hd->platform_ops->unmap_page(d, gfn);
+
+if ( unlikely(rc) )
+{
+if ( printk_ratelimit() )
+printk(XENLOG_ERR
+   "dom%d: IOMMU unmapping gfn %#lx failed %d.",
+   d->domain_id, gfn, rc);
+
+if ( !is_hardware_domain(d) )
+domain_crash(d);
+}
+
+return rc;


Waiting for Kevin's opinion..


Quan

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

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

2016-05-12 Thread Zytaruk, Kelly



> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, May 12, 2016 9:51 AM
> To: Zytaruk, Kelly
> Cc: Feng Wu; Kevin Tian; xen-devel@lists.xen.org
> Subject: RE: [Xen-devel] panic("queue invalidate wait descriptor was not
> executed\n")
> 
> >>> On 12.05.16 at 14:36,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Thursday, May 12, 2016 5:49 AM
> >> >>> On 11.05.16 at 15:51,  wrote:
> >> > During Xen boot I am seeing the panic in the subject line from
> >> > .../xen/drivers/passthrough/vgt/qinval.c
> >>
> >> And this is with current staging, or some much older version of Xen?
> >> (ISTR some issue with the invalidation request getting sent to the
> >> wrong IOMMU, leading to a timeout.)
> >
> > No this is not current Xen, it is with 4.2.
> >
> > Can you tell me more about the invalidation request getting sent to
> > the wrong IOMMU problem and approximately when it was fixed?  If you
> > could identify the patch I could back port it into my copy of Xen for 
> > testing.
> 
> Note that 4.2.5 has said change, and also note that you could have done 
> exactly
> what I have done now - go through the list of commits altering files in the 
> vtd/
> subtree. 

Unfortunately GIT is not my strong suit :( I am still learning to navigate with 
it. I guess part of my problem with GIT is that I don't yet know what I don't 
know.

>This is what I've been remembering:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb9927
> 8b6ba885616bb183b88ad67

The comment on this link describes exactly what I am experiencing.
Thanks so much.

> 
> Jan


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

Re: [Xen-devel] [PATCH v4 0/3] usb, xen: add pvUSB backend

2016-05-12 Thread Juergen Gross

On 12/05/16 15:52, Gerd Hoffmann wrote:
> On Do, 2016-05-12 at 07:47 +0200, Juergen Gross wrote:
>> This series adds a Xen pvUSB backend driver to qemu. USB devices
>> connected to the host can be passed through to a Xen guest. The
>> devices are specified via Xenstore. Access to the devices is done
>> via host-libusb.c
>>
>> I've tested the backend with various USB devices (memory sticks,
>> keyboard, ...).
> 
> Doesn't pass scripts/checkpatch.pl:

Aargh! Sorry for that. Will send V5 soon.


Juergen

> 
> Applying: xen: write information about supported backends
> === checkpatch complains ===
> WARNING: line over 80 characters
> #14: FILE: hw/xen/xen_backend.c:49:
> +static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
> QTAILQ_HEAD_INITIALIZER(xs_cleanup);
> 
> ERROR: space required after that close brace '}'
> #53: FILE: hw/xen/xen_backend.c:109:
> +}};
> 
> WARNING: space prohibited between function name and open parenthesis '('
> #85: FILE: hw/xen/xen_backend.c:785:
> +snprintf(path, sizeof (path), "device-model/%u/backends/%s",
> xen_domid,
> 
> total: 1 errors, 2 warnings, 161 lines checked
> 
> cheers,
>   Gerd
> 
> 


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

Re: [Xen-devel] [PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 02:43:03PM +0100, Paul Durrant wrote:
> Patch 562abd39 "xen-netback: support multiple extra info fragments
> passed from frontend" contained a mistake which can result in an in-
> correct number of responses being generated when handling errors
> encountered when processing packets containing extra info fragments.
> This patch fixes the problem.
> 
> Signed-off-by: Paul Durrant 
> Reported-by: Jan Beulich 
> Cc: Wei Liu 

Acked-by: Wei Liu 

> ---
>  drivers/net/xen-netback/netback.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index b42f260..4412a57 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -711,6 +711,7 @@ static void xenvif_tx_err(struct xenvif_queue *queue,
>   if (cons == end)
>   break;
>   RING_COPY_REQUEST(>tx, cons++, txp);
> + extra_count = 0; /* only the first frag can have extras */
>   } while (1);
>   queue->tx.req_cons = cons;
>  }
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH v5 3/3] xen: add pvUSB backend

2016-05-12 Thread Juergen Gross

Add a backend for para-virtualized USB devices for xen domains.

The backend is using host-libusb to forward USB requests from a
domain via libusb to the real device(s) passed through.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
---
V3: multiple small changes as requested by Anthony Perard
check for full ring in case of hotplug events as requested by
Anthony Perard
use RING_COPY_REQUEST() instead of RING_GET_REQUEST()
add check for required header version and disable backend in
case header is too old

V2: use xen_be_printf() instead of fprintf() for diagnostic prints as
requested by Stefano Stabellini
lots of small changes requested by Konrad Wilk
removed isoc request support, will be in separate patch
---
 hw/usb/Makefile.objs |4 +
 hw/usb/xen-usb.c | 1080 ++
 hw/xenpv/xen_machine_pv.c|3 +
 include/hw/xen/xen_backend.h |3 +
 include/hw/xen/xen_common.h  |2 +
 5 files changed, 1092 insertions(+)
 create mode 100644 hw/usb/xen-usb.c

diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 2717027..98b5c9d 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -38,3 +38,7 @@ common-obj-$(CONFIG_USB_REDIR) += redirect.o quirks.o
 
 # usb pass-through
 common-obj-y += $(patsubst %,host-%.o,$(HOST_USB))
+
+ifeq ($(CONFIG_USB_LIBUSB),y)
+common-obj-$(CONFIG_XEN_BACKEND) += xen-usb.o
+endif
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
new file mode 100644
index 000..664df04
--- /dev/null
+++ b/hw/usb/xen-usb.c
@@ -0,0 +1,1080 @@
+/*
+ *  xen paravirt usb device backend
+ *
+ *  (c) Juergen Gross 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; under version 2 of the License.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License along
+ *  with this program; if not, see .
+ *
+ *  Contributions after 2012-01-13 are licensed under the terms of the
+ *  GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/config-file.h"
+#include "hw/sysbus.h"
+#include "hw/usb.h"
+#include "hw/xen/xen_backend.h"
+#include "monitor/qdev.h"
+#include "qapi/qmp/qbool.h"
+#include "qapi/qmp/qint.h"
+#include "qapi/qmp/qstring.h"
+#include "sys/user.h"
+
+#include 
+#include 
+
+/*
+ * Check for required support of usbif.h: USBIF_SHORT_NOT_OK was the last
+ * macro added we rely on.
+ */
+#ifdef USBIF_SHORT_NOT_OK
+
+#define TR(xendev, lvl, fmt, args...)   \
+{   \
+struct timeval tv;  \
+\
+gettimeofday(, NULL);\
+xen_be_printf(xendev, lvl, "%8ld.%06ld xen-usb(%s):" fmt,   \
+  tv.tv_sec, tv.tv_usec, __func__, ##args); \
+}
+#define TR_BUS(xendev, fmt, args...) TR(xendev, 2, fmt, ##args)
+#define TR_REQ(xendev, fmt, args...) TR(xendev, 3, fmt, ##args)
+
+#define USBBACK_MAXPORTSUSBIF_PIPE_PORT_MASK
+#define USB_DEV_ADDR_SIZE   (USBIF_PIPE_DEV_MASK + 1)
+
+/* USB wire protocol: structure describing control request parameter. */
+struct usbif_ctrlrequest {
+uint8_tbRequestType;
+uint8_tbRequest;
+uint16_t   wValue;
+uint16_t   wIndex;
+uint16_t   wLength;
+};
+
+struct usbback_info;
+struct usbback_req;
+
+struct usbback_stub {
+USBDevice *dev;
+USBPort   port;
+unsigned int  speed;
+bool  attached;
+QTAILQ_HEAD(submit_q_head, usbback_req) submit_q;
+};
+
+struct usbback_req {
+struct usbback_info  *usbif;
+struct usbback_stub  *stub;
+struct usbif_urb_request req;
+USBPacketpacket;
+
+unsigned int nr_buffer_segs; /* # of transfer_buffer segments 
*/
+unsigned int nr_extra_segs;  /* # of iso_frame_desc segments  
*/
+
+QTAILQ_ENTRY(usbback_req) q;
+
+void *buffer;
+void *isoc_buffer;
+struct libusb_transfer   *xfer;
+};
+
+struct usbback_hotplug {
+QSIMPLEQ_ENTRY(usbback_hotplug) q;
+unsigned port;
+};
+
+struct usbback_info {
+struct XenDevice xendev;  /* must be first */
+USBBus   bus;
+void

[Xen-devel] [PATCH v5 0/3] usb, xen: add pvUSB backend

2016-05-12 Thread Juergen Gross

This series adds a Xen pvUSB backend driver to qemu. USB devices
connected to the host can be passed through to a Xen guest. The
devices are specified via Xenstore. Access to the devices is done
via host-libusb.c

I've tested the backend with various USB devices (memory sticks,
keyboard, ...).

Changes in V5:
- patch 2: silence checkpatch errors/warnings

Changes in V4:
- patch 2: don't allow guest reading the new directory as requested by
  Anthony Perard

Changes in V3:
- added new patch 2 (was sent formerly on it's own)
- patch 3 (was 2): multiple small changes as requested by Anthony Perard
- patch 3 (was 2): check for full ring in case of hotplug events as
  requested by Anthony Perard
- patch 3 (was 2): use RING_COPY_REQUEST() instead of RING_GET_REQUEST()
- patch 3 (was 2): add check for required header version and disable
  backend in case header is too old

Changes in V2:
- rebased to current qemu master
- removed support for isoc requests in this series, as the optimal way to
  support those isn't clear yet. Will be added in a followup series.
- several changes as requested by Stefano Stabellini and Konrad Wilk

Changes since RFC:
- open device via qdev_device_add(), making patch 1 obsolete
- modify patch 2 to use isoc passthrough via libusb instead of one
  job per frame

Juergen Gross (3):
  xen: introduce dummy system device
  xen: write information about supported backends
  xen: add pvUSB backend

 hw/usb/Makefile.objs |4 +
 hw/usb/xen-usb.c | 1080 ++
 hw/xen/xen_backend.c |   63 +++
 hw/xen/xen_devconfig.c   |   52 +-
 hw/xenpv/xen_machine_pv.c|   43 ++
 include/hw/xen/xen_backend.h |6 +
 include/hw/xen/xen_common.h  |2 +
 7 files changed, 1200 insertions(+), 50 deletions(-)
 create mode 100644 hw/usb/xen-usb.c

-- 
2.6.6


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

[Xen-devel] [PATCH v5 1/3] xen: introduce dummy system device

2016-05-12 Thread Juergen Gross

Introduce a new dummy system device serving as parent for virtual
buses. This will enable new pv backends to introduce virtual buses
which are removable again opposed to system buses which are meant
to stay once added.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
---
V2: NOT changed, even if requested by Stefano Stabellini: the xen dummy
system device is needed by virtfs for Xen PV(H) guests, too
---
 hw/xenpv/xen_machine_pv.c| 40 
 include/hw/xen/xen_backend.h |  1 +
 2 files changed, 41 insertions(+)

diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index fc13535..48d5bc6 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -25,10 +25,15 @@
 #include "qemu/osdep.h"
 #include "hw/hw.h"
 #include "hw/boards.h"
+#include "hw/sysbus.h"
 #include "hw/xen/xen_backend.h"
 #include "xen_domainbuild.h"
 #include "sysemu/block-backend.h"
 
+#define TYPE_XENSYSDEV "xensysdev"
+
+DeviceState *xen_sysdev;
+
 static void xen_init_pv(MachineState *machine)
 {
 DriveInfo *dinfo;
@@ -67,6 +72,9 @@ static void xen_init_pv(MachineState *machine)
 break;
 }
 
+xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
+qdev_init_nofail(xen_sysdev);
+
 xen_be_register("console", _console_ops);
 xen_be_register("vkbd", _kbdmouse_ops);
 xen_be_register("vfb", _framebuffer_ops);
@@ -101,6 +109,38 @@ static void xen_init_pv(MachineState *machine)
 xen_init_display(xen_domid);
 }
 
+static int xen_sysdev_init(SysBusDevice *dev)
+{
+return 0;
+}
+
+static Property xen_sysdev_properties[] = {
+{/* end of property list */},
+};
+
+static void xen_sysdev_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
+
+k->init = xen_sysdev_init;
+dc->props = xen_sysdev_properties;
+}
+
+static const TypeInfo xensysdev_info = {
+.name  = TYPE_XENSYSDEV,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(SysBusDevice),
+.class_init= xen_sysdev_class_init,
+};
+
+static void xenpv_register_types(void)
+{
+type_register_static(_info);
+}
+
+type_init(xenpv_register_types);
+
 static void xenpv_machine_init(MachineClass *mc)
 {
 mc->desc = "Xen Para-virtualized PC";
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index c839eeb..b4b4ff0 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -60,6 +60,7 @@ extern xc_interface *xen_xc;
 extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
+extern DeviceState *xen_sysdev;
 
 /* xenstore helper functions */
 int xenstore_write_str(const char *base, const char *node, const char *val);
-- 
2.6.6


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

[Xen-devel] [PATCH v5 2/3] xen: write information about supported backends

2016-05-12 Thread Juergen Gross

Add a Xenstore directory for each supported pv backend. This will allow
Xen tools to decide which backend type to use in case there are
multiple possibilities.

The information is added under
/local/domain//device-model//backends
before the "running" state is written to Xenstore. Using a directory
for each backend enables us to add parameters for specific backends
in the future.

This interface is documented in the Xen source repository in the file
docs/misc/qemu-backends.txt

In order to reuse the Xenstore directory creation already present in
hw/xen/xen_devconfig.c move the related functions to
hw/xen/xen_backend.c where they fit better.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
---
V4: don't allow guest reading the new directory as requested by
Anthony Perard

V3: Added .backend_register function to XenDevOps in order to have a
way to let the backend decide whether all prerequisites are met
for support.

V2: update commit message as requested by Stefano
---
 hw/xen/xen_backend.c | 63 
 hw/xen/xen_devconfig.c   | 52 ++--
 include/hw/xen/xen_backend.h |  2 ++
 3 files changed, 67 insertions(+), 50 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 60575ad..c63f9df 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -42,11 +42,36 @@ struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
 
 /* private */
+struct xs_dirs {
+char *xs_dir;
+QTAILQ_ENTRY(xs_dirs) list;
+};
+static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
+QTAILQ_HEAD_INITIALIZER(xs_cleanup);
+
 static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = 
QTAILQ_HEAD_INITIALIZER(xendevs);
 static int debug = 0;
 
 /* - */
 
+static void xenstore_cleanup_dir(char *dir)
+{
+struct xs_dirs *d;
+
+d = g_malloc(sizeof(*d));
+d->xs_dir = dir;
+QTAILQ_INSERT_TAIL(_cleanup, d, list);
+}
+
+void xen_config_cleanup(void)
+{
+struct xs_dirs *d;
+
+QTAILQ_FOREACH(d, _cleanup, list) {
+xs_rm(xenstore, 0, d->xs_dir);
+}
+}
+
 int xenstore_write_str(const char *base, const char *node, const char *val)
 {
 char abspath[XEN_BUFSIZE];
@@ -75,6 +100,30 @@ char *xenstore_read_str(const char *base, const char *node)
 return ret;
 }
 
+int xenstore_mkdir(char *path, int p)
+{
+struct xs_permissions perms[2] = {
+{
+.id= 0, /* set owner: dom0 */
+}, {
+.id= xen_domid,
+.perms = p,
+}
+};
+
+if (!xs_mkdir(xenstore, 0, path)) {
+xen_be_printf(NULL, 0, "xs_mkdir %s: failed\n", path);
+return -1;
+}
+xenstore_cleanup_dir(g_strdup(path));
+
+if (!xs_set_permissions(xenstore, 0, path, perms, 2)) {
+xen_be_printf(NULL, 0, "xs_set_permissions %s: failed\n", path);
+return -1;
+}
+return 0;
+}
+
 int xenstore_write_int(const char *base, const char *node, int ival)
 {
 char val[12];
@@ -726,6 +775,20 @@ err:
 
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
+char path[50];
+int rc;
+
+if (ops->backend_register) {
+rc = ops->backend_register();
+if (rc) {
+return rc;
+}
+}
+
+snprintf(path, sizeof(path), "device-model/%u/backends/%s", xen_domid,
+ type);
+xenstore_mkdir(path, XS_PERM_NONE);
+
 return xenstore_scan(type, xen_domid, ops);
 }
 
diff --git a/hw/xen/xen_devconfig.c b/hw/xen/xen_devconfig.c
index 1f30fe4..b7d290d 100644
--- a/hw/xen/xen_devconfig.c
+++ b/hw/xen/xen_devconfig.c
@@ -5,54 +5,6 @@
 
 /* - */
 
-struct xs_dirs {
-char *xs_dir;
-QTAILQ_ENTRY(xs_dirs) list;
-};
-static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup = 
QTAILQ_HEAD_INITIALIZER(xs_cleanup);
-
-static void xen_config_cleanup_dir(char *dir)
-{
-struct xs_dirs *d;
-
-d = g_malloc(sizeof(*d));
-d->xs_dir = dir;
-QTAILQ_INSERT_TAIL(_cleanup, d, list);
-}
-
-void xen_config_cleanup(void)
-{
-struct xs_dirs *d;
-
-QTAILQ_FOREACH(d, _cleanup, list) {
-   xs_rm(xenstore, 0, d->xs_dir);
-}
-}
-
-/* - */
-
-static int xen_config_dev_mkdir(char *dev, int p)
-{
-struct xs_permissions perms[2] = {{
-.id= 0, /* set owner: dom0 */
-},{
-.id= xen_domid,
-.perms = p,
-}};
-
-if (!xs_mkdir(xenstore, 0, dev)) {
-   xen_be_printf(NULL, 0, "xs_mkdir %s: failed\n", dev);
-   return -1;
-}
-xen_config_cleanup_dir(g_strdup(dev));
-
-if (!xs_set_permissions(xenstore, 0, dev, perms, 2)) {
-   xen_be_printf(NULL, 0, "xs_set_permissions %s: failed\n", dev);
-   return -1;
-}
-return 0;
-}
-
 static int

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Paul Durrant

> -Original Message-
[snip]
> >
> > Ok. Do you regard this as a critical issue for 4.7?
> >
> 
> Our general support statement is to support N->N+1 migration, so it is
> not really critical for me. On the other hand, if the fix is not overly
> complex, it would be nice to have for 4.7.
> 
> Note that the fix will need to be in upstream QEMU first before it can
> be cherry-picked to our tree, so there is risk that it might just be
> blocked on QEMU side (I haven't checked their schedule). So I wouldn't
> really block xen release just for that.
> 

Ok.

> If for some reason (either you don't have time or the patch is blocked
> on QEMU side) the fix doesn't make 4.7.0 I would suggest QEMU maintainer
> to backport to 4.7.1 etc.
> 

I'll try to get to it as soon as I can, but my guess is that it will miss 4.7.0.

  Paul

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 02:03:31PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 12 May 2016 14:02
> > To: Paul Durrant
> > Cc: Wei Liu; Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Anthony
> > Perard; Stefano Stabellini
> > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > server
> > 
> > On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > > Sent: 12 May 2016 11:56
> > > > To: Paul Durrant
> > > > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu
> > > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in 
> > > > ioreq
> > > > server
> > > >
> > > > On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote:
> > > > > > -Original Message-
> > > > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > > > > > Sent: 11 May 2016 13:23
> > > > > > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > > > > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in
> > ioreq
> > > > > > server
> > > > > >
> > > > > > On 11/05/16 13:18, Olaf Hering wrote:
> > > > > > > Migrating a HVM guest from staging-4.4 to staging fails:
> > > > > > >
> > > > > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > > > > > char device redirected to /dev/pts/3 (label serial0)
> > > > > > > xen: ioreq server create: Cannot allocate memory
> > > > > > > qemu-system-x86_64: xen hardware virtual machine initialisation
> > failed
> > > > > > >
> > > > > > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > > > > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that
> > 4.4
> > > > > > does not
> > > > > > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a
> > result
> > > > 4.7
> > > > > > fails to
> > > > > > > configure the guest properly?
> > > > > >
> > > > > > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.
> > > > CC'ing
> > > > > > Paul
> > > > > > who did this work.
> > > > >
> > > > > The problem is because the new QEMU will assume that the guest was
> > > > provisioned with ioreq server pages. Somehow it needs to know to
> > behave
> > > > as a 'default' ioreq server (as qemu trad would) in which case the
> > > > compatibility code in the hypervisor would DTRT. I guess it would be ok 
> > > > to
> > > > just have QEMU fall back to the old 'default' HVM param mechanism if
> > > > creation of an IOREQ server fails. The only other way out would be allow
> > Xen
> > > > to 'steal' the default server's pages if it doesn't exist.
> > > > > The former obviously requires a patch to QEMU (but the compat code
> > > > already exists as a compile-time option so it's probably a small-ish 
> > > > change)
> > > > and the latter requires a patch to Xen. Which is more preferable at this
> > > > stage?
> > > > >
> > > >
> > > > Please help me understand: both ways require patching latest xen.git or
> > > > qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?
> > > >
> > >
> > > Right. We either have to make QEMU accept that a VM can't support the
> > ioreq server hypercalls, or have Xen make them work for old VMs. Nothing
> > has to be done to the older Xen or QEMU.
> > >
> > 
> > OK. Thanks for the explanation.
> > 
> > I'm neither the QEMU maintainer nor the Xen maintainer, so I've CC'ed
> > Anthony and Stefano for you.
> > 
> > If I were to choose, I would choose to patch QEMU to keep the hypervsior
> > as simple as possible.
> > 
> > From a release point of view, both ways require us to put a patch
> > in-tree, so it doesn't make much of a difference to me.
> >
> 
> Ok. Do you regard this as a critical issue for 4.7?
> 

Our general support statement is to support N->N+1 migration, so it is
not really critical for me. On the other hand, if the fix is not overly
complex, it would be nice to have for 4.7.

Note that the fix will need to be in upstream QEMU first before it can
be cherry-picked to our tree, so there is risk that it might just be
blocked on QEMU side (I haven't checked their schedule). So I wouldn't
really block xen release just for that.

If for some reason (either you don't have time or the patch is blocked
on QEMU side) the fix doesn't make 4.7.0 I would suggest QEMU maintainer
to backport to 4.7.1 etc.

Wei.

>   Paul
>  
> > Wei.
> > 
> > >   Paul
> > >
> > > > Wei.
> > > >
> > > > >   Paul
> > > > >
> > > > > >
> > > > > > ~Andrew
> > > > > ___
> > > > > 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

[Xen-devel] [PATCH net] xen-netback: fix extra_info handling in xenvif_tx_err()

2016-05-12 Thread Paul Durrant

Patch 562abd39 "xen-netback: support multiple extra info fragments
passed from frontend" contained a mistake which can result in an in-
correct number of responses being generated when handling errors
encountered when processing packets containing extra info fragments.
This patch fixes the problem.

Signed-off-by: Paul Durrant 
Reported-by: Jan Beulich 
Cc: Wei Liu 
---
 drivers/net/xen-netback/netback.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index b42f260..4412a57 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -711,6 +711,7 @@ static void xenvif_tx_err(struct xenvif_queue *queue,
if (cons == end)
break;
RING_COPY_REQUEST(>tx, cons++, txp);
+   extra_count = 0; /* only the first frag can have extras */
} while (1);
queue->tx.req_cons = cons;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 0/3] usb, xen: add pvUSB backend

2016-05-12 Thread Gerd Hoffmann

On Do, 2016-05-12 at 07:47 +0200, Juergen Gross wrote:
> This series adds a Xen pvUSB backend driver to qemu. USB devices
> connected to the host can be passed through to a Xen guest. The
> devices are specified via Xenstore. Access to the devices is done
> via host-libusb.c
> 
> I've tested the backend with various USB devices (memory sticks,
> keyboard, ...).

Doesn't pass scripts/checkpatch.pl:

Applying: xen: write information about supported backends
=== checkpatch complains ===
WARNING: line over 80 characters
#14: FILE: hw/xen/xen_backend.c:49:
+static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup =
QTAILQ_HEAD_INITIALIZER(xs_cleanup);

ERROR: space required after that close brace '}'
#53: FILE: hw/xen/xen_backend.c:109:
+}};

WARNING: space prohibited between function name and open parenthesis '('
#85: FILE: hw/xen/xen_backend.c:785:
+snprintf(path, sizeof (path), "device-model/%u/backends/%s",
xen_domid,

total: 1 errors, 2 warnings, 161 lines checked

cheers,
  Gerd


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

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 14:36,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, May 12, 2016 5:49 AM
>> >>> On 11.05.16 at 15:51,  wrote:
>> > During Xen boot I am seeing the panic in the subject line from
>> > .../xen/drivers/passthrough/vgt/qinval.c
>> 
>> And this is with current staging, or some much older version of Xen?
>> (ISTR some issue with the invalidation request getting sent to the wrong
>> IOMMU, leading to a timeout.)
> 
> No this is not current Xen, it is with 4.2.
> 
> Can you tell me more about the invalidation request getting sent to the 
> wrong IOMMU problem and approximately when it was fixed?  If you could 
> identify the patch I could back port it into my copy of Xen for testing.

Note that 4.2.5 has said change, and also note that you could have
done exactly what I have done now - go through the list of commits
altering files in the vtd/ subtree. This is what I've been remembering:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=84c340ba4c3eb99278b6ba885616bb183b88ad67

Jan


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

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

2016-05-12 Thread Xu, Quan

On May 12, 2016 9:38 PM, Jan Beulich  wrote:
> >>> On 12.05.16 at 15:29,  wrote:
> > On May 12, 2016 4:53 PM, Jan Beulich  wrote:
> >> >>> On 12.05.16 at 09:50,  wrote:
> >> > On May 10, 2016 12:10 AM, Jan Beulich  wrote:
> >> >> >>> On 06.05.16 at 10:54,  wrote:
> >> >> > @@ -1391,13 +1399,19 @@ int domain_context_mapping_one(
> >> >> >  spin_unlock(>lock);
> >> >> >
> >> >> >  /* Context entry was previously non-present (with domid 0). */
> >> >> > -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) |
> devfn,
> >> >> > -DMA_CCMD_MASK_NOBIT, 1) )
> >> >> > -iommu_flush_write_buffer(iommu);
> >> >> > -else
> >> >> > +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8)
> >> >> > + |
> >> devfn,
> >> >> > +DMA_CCMD_MASK_NOBIT, 1);
> >> >> > +
> >> >> > +if ( !rc )
> >> >> >  {
> >> >> >  int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> >> >> > -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> >> >> > +rc = iommu_flush_iotlb_dsi(iommu, 0, 1,
> >> >> > + flush_dev_iotlb);
> >> >>
> >> >> Please take the opportunity and add the missing blank line
> >> >> (between
> >> >> declaration(s) and statement(s) in cases like this.
> >> >>
> >> >> > +}
> >> >> > +
> >> >> > +if ( rc > 0 )
> >> >>
> >> >> Can iommu_flush_context_device() return a positive value? If so,
> >> >> the logic is now likely wrong. If not (which is what I assume) I'd
> >> >> like to suggest adding a respective ASSERT() (even if only to
> >> >> document the fact). Or alternatively this
> >> >> if() could move into the immediately preceding one.
> >> >
> >> > Check it again. iommu_flush_context_device() can return a positive value.
> >> > [...]
> >> > Could you tell me why the logic is now likely wrong? I will fix it first.
> >>
> >> With
> >>
> >> rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> >> DMA_CCMD_MASK_NOBIT, 1);
> >>
> >> if ( !rc )
> >> {
> >> int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> >> rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> >> }
> >>
> >> if ( rc > 0 )
> >> {
> >> iommu_flush_write_buffer(iommu);
> >> rc = 0;
> >> }
> >>
> >> it seems pretty clear that you won't call iommu_flush_iotlb_dsi() if
> >> iommu_flush_context_device() returned 1, which doesn't look like what
> >> is wanted at the first glance. But I may be wrong, hence the "likely"
> >> in my
> > earlier
> >> reply.
> >>
> >
> > Oh, this was on purpose.
> >
> > If iommu_flush_context_device() returned 1,  the
> > iommu_flush_iotlb_dsi() returned 1 too.
> > As both flush_context_qi() and  flush_iotlb_qi () are the same at the
> > beginning of the  functions.
> 
> Such implications need to be commented on, so readers (like me) don't
> assume brokenness.
> 

ok, I will add a comment.

> > One concern is if iommu_flush_context_device() is failed, then we
> > won't call iommu_flush_iotlb_dsi(),  which is not best effort to flush.
> 
> Indeed.
> 

I'll fix it as well.


Quan

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Stefano Stabellini

On Thu, 12 May 2016, Wei Liu wrote:
> On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > Sent: 12 May 2016 11:56
> > > To: Paul Durrant
> > > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu
> > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > > server
> > > 
> > > On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > > > > Sent: 11 May 2016 13:23
> > > > > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > > > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in 
> > > > > ioreq
> > > > > server
> > > > >
> > > > > On 11/05/16 13:18, Olaf Hering wrote:
> > > > > > Migrating a HVM guest from staging-4.4 to staging fails:
> > > > > >
> > > > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > > > > char device redirected to /dev/pts/3 (label serial0)
> > > > > > xen: ioreq server create: Cannot allocate memory
> > > > > > qemu-system-x86_64: xen hardware virtual machine initialisation 
> > > > > > failed
> > > > > >
> > > > > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > > > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4
> > > > > does not
> > > > > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result
> > > 4.7
> > > > > fails to
> > > > > > configure the guest properly?
> > > > >
> > > > > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.
> > > CC'ing
> > > > > Paul
> > > > > who did this work.
> > > >
> > > > The problem is because the new QEMU will assume that the guest was
> > > provisioned with ioreq server pages. Somehow it needs to know to behave
> > > as a 'default' ioreq server (as qemu trad would) in which case the
> > > compatibility code in the hypervisor would DTRT. I guess it would be ok to
> > > just have QEMU fall back to the old 'default' HVM param mechanism if
> > > creation of an IOREQ server fails. The only other way out would be allow 
> > > Xen
> > > to 'steal' the default server's pages if it doesn't exist.
> > > > The former obviously requires a patch to QEMU (but the compat code
> > > already exists as a compile-time option so it's probably a small-ish 
> > > change)
> > > and the latter requires a patch to Xen. Which is more preferable at this
> > > stage?
> > > >
> > > 
> > > Please help me understand: both ways require patching latest xen.git or
> > > qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?
> > > 
> > 
> > Right. We either have to make QEMU accept that a VM can't support the ioreq 
> > server hypercalls, or have Xen make them work for old VMs. Nothing has to 
> > be done to the older Xen or QEMU.
> > 
> 
> OK. Thanks for the explanation.
> 
> I'm neither the QEMU maintainer nor the Xen maintainer, so I've CC'ed
> Anthony and Stefano for you.
> 
> If I were to choose, I would choose to patch QEMU to keep the hypervsior
> as simple as possible.
> 
> >From a release point of view, both ways require us to put a patch
> in-tree, so it doesn't make much of a difference to me.

I think it might be better to fix QEMU too.

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

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 15:29,  wrote:
> On May 12, 2016 4:53 PM, Jan Beulich  wrote:
>> >>> On 12.05.16 at 09:50,  wrote:
>> > On May 10, 2016 12:10 AM, Jan Beulich  wrote:
>> >> >>> On 06.05.16 at 10:54,  wrote:
>> >> > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned
>> >> > long gfn, unsigned int page_count)
>> >> > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long
>> gfn,
>> >> > +   unsigned int page_count)
>> >>
>> >> The new name suggests just one page. Please use e.g.
>> >> iommu_flush_iotlb_pages() instead.
>> >>
>> >
>> > Make sense.
>> >
>> >> >  {
>> >> > -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
>> >> > +iommu_flush_iotlb(d, gfn, 1, page_count);
>> >> >  }
>> >>
>> >> But of course the question is whether having this wrapper is useful
>> >> in the first place,
>> >
>> >
>> > This wrapper assumes the 'dma_old_pte_present' is '1', but in another
>> > caller intel_iommu_map_page(), i.e.
>> >
>> >
>> >  intel_iommu_map_page()
>> > {
>> >...
>> >  if ( !this_cpu(iommu_dont_flush_iotlb) )
>> >   iommu_flush_iotlb(d, gfn, dma_pte_present(old), 1);
>> >...
>> > }
>> >
>> >
>> > the 'dma_old_pte_present' is not sure.
>> 
>> I'm sorry, but you're looking at this backwards: I suggested to remove the
>> wrapper, not to move any check into iommu_flush_iotlb().
>> Removing the wrapper simply means to move the passing of the hard coded 1
>> into the current callers of that wrapper.
>> 
> 
> A little bit confused.
> Check one thing, do the wrappers refer to iommu_flush_iotlb_page() and 
> iommu_flush_iotlb_all() ?
> 
> If yes, we can't ignore another thing:
> 
> These two wrappers are also initialized for 2 .callbacks at the bottom of 
> this file:
> 
> 
> .iotlb_flush = iommu_flush_iotlb_pages,
> .iotlb_flush_all = iommu_flush_iotlb_all,
> 

Ah, good point. With the renaming going on I didn't realize these
are used here. So in fact they're not just wrappers. Please disregard
my respective comments then.

>> >> > @@ -1391,13 +1399,19 @@ int domain_context_mapping_one(
>> >> >  spin_unlock(>lock);
>> >> >
>> >> >  /* Context entry was previously non-present (with domid 0). */
>> >> > -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | 
>> >> > devfn,
>> >> > -DMA_CCMD_MASK_NOBIT, 1) )
>> >> > -iommu_flush_write_buffer(iommu);
>> >> > -else
>> >> > +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) |
>> devfn,
>> >> > +DMA_CCMD_MASK_NOBIT, 1);
>> >> > +
>> >> > +if ( !rc )
>> >> >  {
>> >> >  int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
>> >> > -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
>> >> > +rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
>> >>
>> >> Please take the opportunity and add the missing blank line (between
>> >> declaration(s) and statement(s) in cases like this.
>> >>
>> >> > +}
>> >> > +
>> >> > +if ( rc > 0 )
>> >>
>> >> Can iommu_flush_context_device() return a positive value? If so, the
>> >> logic is now likely wrong. If not (which is what I assume) I'd like
>> >> to suggest adding a respective ASSERT() (even if only to document the
>> >> fact). Or alternatively this
>> >> if() could move into the immediately preceding one.
>> >
>> > Check it again. iommu_flush_context_device() can return a positive value.
>> > [...]
>> > Could you tell me why the logic is now likely wrong? I will fix it first.
>> 
>> With
>> 
>> rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
>> DMA_CCMD_MASK_NOBIT, 1);
>> 
>> if ( !rc )
>> {
>> int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
>> rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
>> }
>> 
>> if ( rc > 0 )
>> {
>> iommu_flush_write_buffer(iommu);
>> rc = 0;
>> }
>> 
>> it seems pretty clear that you won't call iommu_flush_iotlb_dsi() if
>> iommu_flush_context_device() returned 1, which doesn't look like what is
>> wanted at the first glance. But I may be wrong, hence the "likely" in my 
> earlier
>> reply.
>> 
> 
> Oh, this was on purpose.
> 
> If iommu_flush_context_device() returned 1,  the iommu_flush_iotlb_dsi() 
> returned 1 too.
> As both flush_context_qi() and  flush_iotlb_qi () are the same at the 
> beginning of the  functions.

Such implications need to be commented on, so readers (like me)
don't assume brokenness.

> One concern is if iommu_flush_context_device() is failed, then we won't call 
> iommu_flush_iotlb_dsi(),  which is not best effort to flush.

Indeed.

Jan

___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

2016-05-12 Thread Xu, Quan

On May 12, 2016 4:53 PM, Jan Beulich  wrote:
> >>> On 12.05.16 at 09:50,  wrote:
> > On May 10, 2016 12:10 AM, Jan Beulich  wrote:
> >> >>> On 06.05.16 at 10:54,  wrote:
> >> > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned
> >> > long gfn, unsigned int page_count)
> >> > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long
> gfn,
> >> > +   unsigned int page_count)
> >>
> >> The new name suggests just one page. Please use e.g.
> >> iommu_flush_iotlb_pages() instead.
> >>
> >
> > Make sense.
> >
> >> >  {
> >> > -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
> >> > +iommu_flush_iotlb(d, gfn, 1, page_count);
> >> >  }
> >>
> >> But of course the question is whether having this wrapper is useful
> >> in the first place,
> >
> >
> > This wrapper assumes the 'dma_old_pte_present' is '1', but in another
> > caller intel_iommu_map_page(), i.e.
> >
> >
> >  intel_iommu_map_page()
> > {
> >...
> >  if ( !this_cpu(iommu_dont_flush_iotlb) )
> >   iommu_flush_iotlb(d, gfn, dma_pte_present(old), 1);
> >...
> > }
> >
> >
> > the 'dma_old_pte_present' is not sure.
> 
> I'm sorry, but you're looking at this backwards: I suggested to remove the
> wrapper, not to move any check into iommu_flush_iotlb().
> Removing the wrapper simply means to move the passing of the hard coded 1
> into the current callers of that wrapper.
> 

A little bit confused.
Check one thing, do the wrappers refer to iommu_flush_iotlb_page() and 
iommu_flush_iotlb_all() ?

If yes, we can't ignore another thing:

These two wrappers are also initialized for 2 .callbacks at the bottom of this 
file:


.iotlb_flush = iommu_flush_iotlb_pages,
.iotlb_flush_all = iommu_flush_iotlb_all,





> >> > @@ -1391,13 +1399,19 @@ int domain_context_mapping_one(
> >> >  spin_unlock(>lock);
> >> >
> >> >  /* Context entry was previously non-present (with domid 0). */
> >> > -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> >> > -DMA_CCMD_MASK_NOBIT, 1) )
> >> > -iommu_flush_write_buffer(iommu);
> >> > -else
> >> > +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) |
> devfn,
> >> > +DMA_CCMD_MASK_NOBIT, 1);
> >> > +
> >> > +if ( !rc )
> >> >  {
> >> >  int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> >> > -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> >> > +rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> >>
> >> Please take the opportunity and add the missing blank line (between
> >> declaration(s) and statement(s) in cases like this.
> >>
> >> > +}
> >> > +
> >> > +if ( rc > 0 )
> >>
> >> Can iommu_flush_context_device() return a positive value? If so, the
> >> logic is now likely wrong. If not (which is what I assume) I'd like
> >> to suggest adding a respective ASSERT() (even if only to document the
> >> fact). Or alternatively this
> >> if() could move into the immediately preceding one.
> >
> > Check it again. iommu_flush_context_device() can return a positive value.
> > [...]
> > Could you tell me why the logic is now likely wrong? I will fix it first.
> 
> With
> 
> rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> DMA_CCMD_MASK_NOBIT, 1);
> 
> if ( !rc )
> {
> int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> }
> 
> if ( rc > 0 )
> {
> iommu_flush_write_buffer(iommu);
> rc = 0;
> }
> 
> it seems pretty clear that you won't call iommu_flush_iotlb_dsi() if
> iommu_flush_context_device() returned 1, which doesn't look like what is
> wanted at the first glance. But I may be wrong, hence the "likely" in my 
> earlier
> reply.
> 

Oh, this was on purpose.

If iommu_flush_context_device() returned 1,  the iommu_flush_iotlb_dsi() 
returned 1 too.
As both flush_context_qi() and  flush_iotlb_qi () are the same at the beginning 
of the  functions.

One concern is if iommu_flush_context_device() is failed, then we won't call 
iommu_flush_iotlb_dsi(),  which is not best effort to flush.


Quan










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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Olaf Hering

On Thu, May 12, Paul Durrant wrote:

> Ok. Do you regard this as a critical issue for 4.7?

I do, coming from 4.4 ;-)

Olaf

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Paul Durrant

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 12 May 2016 14:02
> To: Paul Durrant
> Cc: Wei Liu; Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Anthony
> Perard; Stefano Stabellini
> Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> server
> 
> On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > Sent: 12 May 2016 11:56
> > > To: Paul Durrant
> > > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu
> > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > > server
> > >
> > > On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > > > > Sent: 11 May 2016 13:23
> > > > > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > > > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in
> ioreq
> > > > > server
> > > > >
> > > > > On 11/05/16 13:18, Olaf Hering wrote:
> > > > > > Migrating a HVM guest from staging-4.4 to staging fails:
> > > > > >
> > > > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > > > > char device redirected to /dev/pts/3 (label serial0)
> > > > > > xen: ioreq server create: Cannot allocate memory
> > > > > > qemu-system-x86_64: xen hardware virtual machine initialisation
> failed
> > > > > >
> > > > > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > > > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that
> 4.4
> > > > > does not
> > > > > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a
> result
> > > 4.7
> > > > > fails to
> > > > > > configure the guest properly?
> > > > >
> > > > > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.
> > > CC'ing
> > > > > Paul
> > > > > who did this work.
> > > >
> > > > The problem is because the new QEMU will assume that the guest was
> > > provisioned with ioreq server pages. Somehow it needs to know to
> behave
> > > as a 'default' ioreq server (as qemu trad would) in which case the
> > > compatibility code in the hypervisor would DTRT. I guess it would be ok to
> > > just have QEMU fall back to the old 'default' HVM param mechanism if
> > > creation of an IOREQ server fails. The only other way out would be allow
> Xen
> > > to 'steal' the default server's pages if it doesn't exist.
> > > > The former obviously requires a patch to QEMU (but the compat code
> > > already exists as a compile-time option so it's probably a small-ish 
> > > change)
> > > and the latter requires a patch to Xen. Which is more preferable at this
> > > stage?
> > > >
> > >
> > > Please help me understand: both ways require patching latest xen.git or
> > > qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?
> > >
> >
> > Right. We either have to make QEMU accept that a VM can't support the
> ioreq server hypercalls, or have Xen make them work for old VMs. Nothing
> has to be done to the older Xen or QEMU.
> >
> 
> OK. Thanks for the explanation.
> 
> I'm neither the QEMU maintainer nor the Xen maintainer, so I've CC'ed
> Anthony and Stefano for you.
> 
> If I were to choose, I would choose to patch QEMU to keep the hypervsior
> as simple as possible.
> 
> From a release point of view, both ways require us to put a patch
> in-tree, so it doesn't make much of a difference to me.
>

Ok. Do you regard this as a critical issue for 4.7?

  Paul
 
> Wei.
> 
> >   Paul
> >
> > > Wei.
> > >
> > > >   Paul
> > > >
> > > > >
> > > > > ~Andrew
> > > > ___
> > > > 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

[Xen-devel] [PATCH V2] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

2016-05-12 Thread Peng Fan

On ARM64, "frametable_size >> SECOND_SHIFT" computes the number
of second level entries, not the number of second level pages.

"ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT" which computes
the number of the first level entries (the number of second level pages),
is the correct one that should be used.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

V2:
 Take Julien's suggestion in 
http://lists.xen.org/archives/html/xen-devel/2016-05/msg01145.html.
 Refine commit log.

 xen/arch/arm/mm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0a4f845..5f60aa4 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -767,7 +767,8 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
 base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));

 #ifdef CONFIG_ARM_64
-nr_second = frametable_size >> SECOND_SHIFT;
+/* Compute the number of second level pages. */
+nr_second = ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;
 second_base = alloc_boot_pages(nr_second, 1);
 second = mfn_to_virt(second_base);
 for ( i = 0; i < nr_second; i++ )
-- 
2.6.2

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Wei Liu

On Thu, May 12, 2016 at 01:39:49PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 12 May 2016 11:56
> > To: Paul Durrant
> > Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu
> > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > server
> > 
> > On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > > > Sent: 11 May 2016 13:23
> > > > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in 
> > > > ioreq
> > > > server
> > > >
> > > > On 11/05/16 13:18, Olaf Hering wrote:
> > > > > Migrating a HVM guest from staging-4.4 to staging fails:
> > > > >
> > > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > > > char device redirected to /dev/pts/3 (label serial0)
> > > > > xen: ioreq server create: Cannot allocate memory
> > > > > qemu-system-x86_64: xen hardware virtual machine initialisation failed
> > > > >
> > > > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4
> > > > does not
> > > > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result
> > 4.7
> > > > fails to
> > > > > configure the guest properly?
> > > >
> > > > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.
> > CC'ing
> > > > Paul
> > > > who did this work.
> > >
> > > The problem is because the new QEMU will assume that the guest was
> > provisioned with ioreq server pages. Somehow it needs to know to behave
> > as a 'default' ioreq server (as qemu trad would) in which case the
> > compatibility code in the hypervisor would DTRT. I guess it would be ok to
> > just have QEMU fall back to the old 'default' HVM param mechanism if
> > creation of an IOREQ server fails. The only other way out would be allow Xen
> > to 'steal' the default server's pages if it doesn't exist.
> > > The former obviously requires a patch to QEMU (but the compat code
> > already exists as a compile-time option so it's probably a small-ish change)
> > and the latter requires a patch to Xen. Which is more preferable at this
> > stage?
> > >
> > 
> > Please help me understand: both ways require patching latest xen.git or
> > qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?
> > 
> 
> Right. We either have to make QEMU accept that a VM can't support the ioreq 
> server hypercalls, or have Xen make them work for old VMs. Nothing has to be 
> done to the older Xen or QEMU.
> 

OK. Thanks for the explanation.

I'm neither the QEMU maintainer nor the Xen maintainer, so I've CC'ed
Anthony and Stefano for you.

If I were to choose, I would choose to patch QEMU to keep the hypervsior
as simple as possible.

From a release point of view, both ways require us to put a patch
in-tree, so it doesn't make much of a difference to me.

Wei.

>   Paul
> 
> > Wei.
> > 
> > >   Paul
> > >
> > > >
> > > > ~Andrew
> > > ___
> > > 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] xc_altp2m_set_vcpu_enable_notify fail

2016-05-12 Thread Big Strong

I'm still not very clear why would do_altp2m_op change the domain to
current domain (which is dom0 in my case) when the cmd is
HVMOP_altp2m_vcpu_enable_notify
.
As to my case, it would prevent the dom0 to set the #ve info page for other
domUs because the check of is_hvm_domain would fail
and
the function will returns directly.

2016-05-12 0:26 GMT+08:00 Sahita, Ravi :

> Hi Fangtuo,
>
>
>
> #VE can be setup to be delivered to any dom that is a HVM.
>
>
>
> Ravi
>
>
>
> *From:* Big Strong [mailto:fangtu...@gmail.com]
> *Sent:* Wednesday, May 11, 2016 8:38 AM
> *To:* Wei Liu 
> *Cc:* Tamas K Lengyel ; Sahita, Ravi <
> ravi.sah...@intel.com>; Xen-devel 
> *Subject:* Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail
>
>
>
> Is that a bug or does #ve info page can only exist on dom0? If this is
> true, why would there be a is_hvm_domain check which will stop the
> execution of xc_altp2m_vcpu_enable_notify?
>
>
>
> 2016-05-11 15:56 GMT+08:00 Big Strong :
>
> From what I analyzed, can I draw a concolusion that the current
> implementation of do_altp2m_op means #ve info page can only be set on dom0
> memory and the dom0 must be a hvm? This seems like ridiculous as dom0 is a
> special pv guest.
>
>
>
> 2016-05-11 11:37 GMT+08:00 Big Strong :
>
> Further debugging shows that the domain is changed to domain 0 during the
> check of whether the cmd of do_altp2m_op
> is HVMOP_altp2m_vcpu_enable_notify, located at here
> .
> As domain 0 is a pv guest, it causes the is_hvm_domain
> 
> check failed, and thus the execution never goes to
> HVMOP_altp2m_vcpu_enable_notify
> ,
> which in the end cause xc_altp2m_set_vcpu_enable_notify fail. Why would *the
> logic of do_altp2m_op change the domain to dom0 when the cmd of
> do_altp2m_op is HVMOP_altp2m_vcpu_enable_notify*?
>
>
>
> Thanks for the suggestion, after adding printk to all the routines
> of xc_altp2m_set_vcpu_enable_notify, it turns out that the problem is
> because* the check of is_hvm_domain()
> 
> failed* in function do_altp2m_op()
> .
> However, I've already configure the VM to build as a HVM by adding option
> "builder=hvm" in the config file, but for unknown reason the .printk of
> domain->type is guest_type_pv. I've tried both windows and linux as the
> guest VM, both failed for the same reason. Any ideas?
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Paul Durrant

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 12 May 2016 11:56
> To: Paul Durrant
> Cc: Andrew Cooper; Olaf Hering; xen-devel@lists.xen.org; Wei Liu
> Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> server
> 
> On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > > Sent: 11 May 2016 13:23
> > > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > > server
> > >
> > > On 11/05/16 13:18, Olaf Hering wrote:
> > > > Migrating a HVM guest from staging-4.4 to staging fails:
> > > >
> > > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > > char device redirected to /dev/pts/3 (label serial0)
> > > > xen: ioreq server create: Cannot allocate memory
> > > > qemu-system-x86_64: xen hardware virtual machine initialisation failed
> > > >
> > > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4
> > > does not
> > > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result
> 4.7
> > > fails to
> > > > configure the guest properly?
> > >
> > > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.
> CC'ing
> > > Paul
> > > who did this work.
> >
> > The problem is because the new QEMU will assume that the guest was
> provisioned with ioreq server pages. Somehow it needs to know to behave
> as a 'default' ioreq server (as qemu trad would) in which case the
> compatibility code in the hypervisor would DTRT. I guess it would be ok to
> just have QEMU fall back to the old 'default' HVM param mechanism if
> creation of an IOREQ server fails. The only other way out would be allow Xen
> to 'steal' the default server's pages if it doesn't exist.
> > The former obviously requires a patch to QEMU (but the compat code
> already exists as a compile-time option so it's probably a small-ish change)
> and the latter requires a patch to Xen. Which is more preferable at this
> stage?
> >
> 
> Please help me understand: both ways require patching latest xen.git or
> qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?
> 

Right. We either have to make QEMU accept that a VM can't support the ioreq 
server hypercalls, or have Xen make them work for old VMs. Nothing has to be 
done to the older Xen or QEMU.

  Paul

> Wei.
> 
> >   Paul
> >
> > >
> > > ~Andrew
> > ___
> > 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] panic("queue invalidate wait descriptor was not executed\n")

2016-05-12 Thread Zytaruk, Kelly



> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, May 12, 2016 5:49 AM
> To: Zytaruk, Kelly
> Cc: Feng Wu; Kevin Tian; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] panic("queue invalidate wait descriptor was not
> executed\n")
> 
> >>> On 11.05.16 at 15:51,  wrote:
> > During Xen boot I am seeing the panic in the subject line from
> > .../xen/drivers/passthrough/vgt/qinval.c
> 
> And this is with current staging, or some much older version of Xen?
> (ISTR some issue with the invalidation request getting sent to the wrong
> IOMMU, leading to a timeout.)

No this is not current Xen, it is with 4.2.

Can you tell me more about the invalidation request getting sent to the wrong 
IOMMU problem and approximately when it was fixed?  If you could identify the 
patch I could back port it into my copy of Xen for testing.

This is a NUMA system with 2 IOMMUs
I have 4 devices on 2 PCIe cards (2 per card)
They reside at the following locations 3:0.0, 5:0.0, 83:0.0 and 85:0.0
From what I understand about NUMA, based on the BDFs,  2 devices should be on 
one IOMMU and the other 2 should on the other IOMMU.

I put in some more print statements last night and discovered that during boot 
Xen attaches all 4 devices to the same IOMMU structure. Xen sends out a flush 
to all 4 devices on the first IOMMU and then follows it with a Wait 
invalidation packet to the same IOMMU.  Below is what I am seeing;

(XEN) IOMMU LIST - List of defined IOMMU structures
(XEN) iommu[00] @ 83103fffa5c0, Q=2060c04002, HEAD=90, TAIL=90
(XEN) Seq Num = 0, pt_levels = 4, cap = 0x00d2078c106f0466, ecap = 
0x00f020df, domid_bitmap = 1, domid_map=0x0
(XEN) iommu[01] @ 83103fffa790, Q=103ffec002, HEAD=bd0, TAIL=bd0
(XEN) Seq Num = 1, pt_levels = 4, cap = 0x00d2078c106f0466, ecap = 
0x00f020df, domid_bitmap = 1, domid_map=0x0

(XEN) gen_dev_iotlb_inv_dsc - DEVICE IOTLB Descriptor 0x7001 
0x8303 for 83:00.0 (index = 9), iommu = 83103fffa5c0, fault = 
0x
(XEN) gen_dev_iotlb_inv_dsc - DEVICE IOTLB Descriptor 0x7001 
0x8103 for 81:00.0 (index = 10), iommu = 83103fffa5c0, fault = 
0x
(XEN) gen_dev_iotlb_inv_dsc - DEVICE IOTLB Descriptor 0x7001 
0x0503 for 05:00.0 (index = 11), iommu = 83103fffa5c0, fault = 
0x
(XEN) gen_dev_iotlb_inv_dsc - DEVICE IOTLB Descriptor 0x7001 
0x0303 for 03:00.0 (index = 12), iommu = 83103fffa5c0, fault = 
0x
(XEN) queue_invalidate_wait (iommu = 83103fffa5c0)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) queue invalidate wait descriptor was not executed
(XEN) 

Is it a bug to have all 4 devices on the same IOMMU?  Is this why the Wait 
Invalidation is failing?
Actually I am not sure if Xen is attaching all 4 devices to the same IOMMU or 
if it is generating the dev iotlb descriptors wrong

> 
> > From the Fault Status Register (= 0x40 (ITE)). I am seeing a hardware
> > timeout on the invalidate
> >
> > Disabling queued invalidation is not an option.  I need to find out
> > why the operation is timing out and fix it.
> >
> > I found two timeouts; one in software and one in hardware.
> > After the invalidate is submitted there is a wait packet submitted and
> > the boot software waits for the wait packet to complete in a loop with
> > a software timeout.  At the end of the software timeout it issues the
> > panic.  I can increase the software timeout but it still doesn't solve
> > the problem.  Just before the panic I dump the value of the Fault
> > Status Register and I see that the hardware has already timed out
> > (FSTS_REG = 0x40 = ITE = "Invalidation Timeout Error").  As a first
> > step in solving this I would like to increase the hardware timeout value.
> >
> > I have the Intel spec and I was reading from the spec...
> >
> > " Hardware starts an invalidation completion timer for this ITag, and
> > issues the invalidation request message to the specified endpoint. If
> > the invalidation command from software is for a first-level mapping,
> > the invalidation request message is generated with the appropriate
> > PASID prefix to identify the target PASID. The invalidation completion
> > time-out value is recommended to be sufficiently larger than the
> > PCI-Express read completion time-outs. "
> >
> > The above leads me to believe that there should be some way of setting
> > the invalidation completion time-out value.  Unfortunately I couldn't
> > find anything in the Intel spec that tells me how to set the "invalidation
> > completion time-out".   Can someone point me in the right direction to
> > setting the completion timer?
> 
> For this I guess you should have Cc-ed the VT-d maintainers, which I have now
> done.
> 
> Jan


___
Xen-devel mailing list

[Xen-devel] [linux-3.18 test] 94035: regressions - FAIL

2016-05-12 Thread osstest service owner

flight 94035 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94035/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 fail REGR. 
vs. 92982
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 92982
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs. 
92982

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail REGR. vs. 92982
 build-i386-rumpuserxen6 xen-buildfail   like 92982
 build-amd64-rumpuserxen   6 xen-buildfail   like 92982
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92982

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 linux6b12ebc0ecce75d7bd3660cd85f8b47a615c2071
baseline version:
 linux834125557e0a4e5afafee3caf79696078d0820ae

Last test of basis92982  2016-04-27 16:21:58 Z   14 days
Testing same since94035  2016-05-11 15:51:18 Z0 days1 attempts


People who touched revisions under test:
  Alex Deucher 
  Andrew Morton 
  Aneesh Kumar K.V 
  Anton Blanchard 
  Dave Airlie 
  Dmitry Ivanov 
  Dmitry Ivanov 
  Dmitry Torokhov 
  Dominik Dingel 
  Herbert Xu 
  Huacai Chen 
  Ingo Molnar 
  Jan Beulich 
  Johannes Berg 
  JÃ©rÃ´me Glisse 
  Linus Torvalds 
  Martin Schwidefsky 
  Mauro Carvalho Chehab 
  Maxim Sheviakov

[Xen-devel] [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

2016-05-12 Thread Shannon Zhao

From: Shannon Zhao 

The EFI DT parameters for bare metal are located under /chosen node,
while for Xen Dom0 they are located under /hyperviosr/uefi node. These
parameters under /chosen and /hyperviosr/uefi are not expected to appear
at the same time.
Parse these EFI parameters and initialize EFI like the way for bare
metal except the runtime services because the runtime services for Xen
Dom0 are available through hypercalls and they are always enabled. So it
sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and
bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES
flag is set already.

CC: Matt Fleming 
Signed-off-by: Shannon Zhao 
---
v2: rebase it on top of EFI and Xen next branch, add some comments to
explain the codes. 
---
 arch/arm/xen/enlighten.c   | 22 +++
 drivers/firmware/efi/arm-runtime.c |  5 +++
 drivers/firmware/efi/efi.c | 81 ++
 3 files changed, 92 insertions(+), 16 deletions(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 13e3e9f..d4f36eb 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -15,7 +15,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -261,6 +263,19 @@ static int __init fdt_find_hyper_node(unsigned long node, 
const char *uname,
!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
hyper_node.version = s + strlen(hyper_node.prefix);
 
+   /*
+* Check if Xen supports EFI by checking whether there is the
+* "/hypervisor/uefi" node in DT. If so, runtime services are available
+* through proxy functions (e.g. in case of Xen dom0 EFI implementation
+* they call special hypercall which executes relevant EFI functions)
+* and that is why they are always enabled.
+*/
+   if (IS_ENABLED(CONFIG_XEN_EFI)) {
+   if ((of_get_flat_dt_subnode_by_name(node, "uefi") > 0) &&
+   !efi_runtime_disabled())
+   set_bit(EFI_RUNTIME_SERVICES, );
+   }
+
return 0;
 }
 
@@ -352,6 +367,13 @@ static int __init xen_guest_init(void)
return -ENODEV;
}
 
+   /*
+* The fdt parsing codes have set EFI_RUNTIME_SERVICES if Xen EFI
+* parameters are found. Force enable runtime services.
+*/
+   if (efi_enabled(EFI_RUNTIME_SERVICES))
+   xen_efi_runtime_setup();
+
shared_info_page = (struct shared_info *)get_zeroed_page(GFP_KERNEL);
 
if (!shared_info_page) {
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 17ccf0a..c394b81 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -107,6 +107,11 @@ static int __init arm_enable_runtime_services(void)
return 0;
}
 
+   if (efi_enabled(EFI_RUNTIME_SERVICES)) {
+   pr_info("EFI runtime services access via paravirt.\n");
+   return 0;
+   }
+
pr_info("Remapping and enabling EFI services.\n");
 
mapsize = efi.memmap.map_end - efi.memmap.map;
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 05509f3..1c6f9dd 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -472,12 +472,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static __initdata struct params fdt_params[] = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -485,44 +487,91 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static __initdata struct params xen_fdt_params[] = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
+#define EFI_FDT_PARAMS_SIZEARRAY_SIZE(fdt_params)
+
+static __initdata struct {
+   const char *uname;
+   const char *subnode;
+   struct params *params;
+} dt_params[] = {
+   { "hypervisor", "uefi", xen_fdt_params },
+   { "chosen", NULL, fdt_params },
+};
+
 struct param_info {
int found;
void *params;
+   const char *missing;
 };
 
-static int __init

[Xen-devel] [linux-4.1 test] 94034: tolerable FAIL - PUSHED

2016-05-12 Thread osstest service owner

flight 94034 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94034/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeatfail like 93111
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93111
 build-amd64-rumpuserxen   6 xen-buildfail   like 93220
 build-i386-rumpuserxen6 xen-buildfail   like 93220
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail   like 93220
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 93220
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93220
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93220
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93220
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93220
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 93220

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass

version targeted for testing:
 linux648d744eff1aedea4ffe49dfca07aa465669e1f4
baseline version:
 linux54419e3efcd6677e4b0841666e2fc605d2e5df86

Last test of basis93220  2016-04-29 15:29:22 Z   12 days
Testing same since94034  2016-05-11 15:50:32 Z0 days1 attempts


People who touched revisions under test:
  Alex Deucher 
  Andrew Morton 
  Anton Blanchard 
  Bastien Nocera 
  cp...@redhat.com 
  Dave Airlie 
  David S. Miller 
  Dmitry Ivanov 
  Dmitry Ivanov 
  Dmitry Torokhov 
  Dominik Dingel 
  Emmanuel Grumbach 
  Felipe Balbi 
  Herbert Xu 
  Hongzhou Yang 
  Huacai Chen 
  Ingo Molnar 
  Jan Beulich 
  Jani Nikula 
  Johannes Berg

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

2016-05-12 Thread Julien Grall




On 12/05/16 12:30, Peng Fan wrote:

Hi Julien,

On Thu, May 12, 2016 at 11:48:30AM +0100, Julien Grall wrote:

Hi Peng,

On 12/05/16 07:36, Peng Fan wrote:

To ARM64, "frametable_size >> SECOND_SHIFT" means the number
of second level entries, not the number of second level pages.

"DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)"
is the correct way to calculate the second level pages needed
for frametable mapping.


Good catch!


Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
  xen/arch/arm/mm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0a4f845..7c7f8e9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -767,7 +767,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
  base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));

  #ifdef CONFIG_ARM_64
-nr_second = frametable_size >> SECOND_SHIFT;
+nr_second = DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES);



I think the following would be clearer:

ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;


Agree.



This would also benefit a comment to explain that second level of page table
are populating.


Do you mean I need to add a comment for the upper code?


Yes.



For the commit log, I would like to change to this:
"
To ARM64, "frametable_size >> SECOND_SHIFT" means the number


On ARM64,

s/means/computes/



of second level entries, not the number of second level pages.

"ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT" which means


s/means/computes/


the number of the first level entries(the number of second level pages),


missing space after "entries"


is the correct one that should be used.
"


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH V3 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

2016-05-12 Thread Peng Fan

CPU0 is using the boot pages table before relocating xen and
xen_second is not part of them. So, no need to flush the TLB
when filling xen_second.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Reviewed-by: Julien Grall 
---
V3:
 Add Julien's review tag.

V2:
 Following Julien's comments:
   split the V1 patch into two patches. This patch only remove tlb flush.
   refine commit log

 xen/arch/arm/mm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..addd699 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -447,7 +447,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 dest_va = BOOT_RELOC_VIRT_START;
 pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
 write_pte(xen_second + second_table_offset(dest_va), pte);
-flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
 
 /* Calculate virt-to-phys offset for the new location */
 phys_offset = xen_paddr - (unsigned long) _start;
-- 
2.6.2


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

[Xen-devel] [PATCH V3 2/2] xen/arm: mm: clean up code in setup_pagetables

2016-05-12 Thread Peng Fan

The base of address for the relocated xen needs to be mapped
at the same virtual address (BOOT_RELOC_VIRT_START) in both
the boot and runtime page tables. So we can merge the two pieces
of code into on code block

Also no need to use write_pte when mapping BOOT_RELOC_VIRT_START
in xen_second, because CPU0 is using boot page tables.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

V3:
 Refine the commit log.

V2:
 Follow Julien's comments:
   split the V1 patch into two patches, this patch is the code movement part.

 xen/arch/arm/mm.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index addd699..0a4f845 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,11 +443,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 lpae_t pte, *p;
 int i;
 
-/* Map the destination in the boot misc area. */
-dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
-write_pte(xen_second + second_table_offset(dest_va), pte);
-
 /* Calculate virt-to-phys offset for the new location */
 phys_offset = xen_paddr - (unsigned long) _start;
 
@@ -494,9 +489,12 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START)];
 xen_second[second_table_offset(BOOT_FDT_VIRT_START)] = pte;
 
-/* Map the destination in the boot misc area. */
+/* ... Boot Misc area for xen relocation */
 dest_va = BOOT_RELOC_VIRT_START;
 pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
+/* Map the destination in xen_second. */
+xen_second[second_table_offset(dest_va)] = pte;
+/* Map the destination in boot_second. */
 write_pte(boot_second + second_table_offset(dest_va), pte);
 flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
 #ifdef CONFIG_ARM_64
-- 
2.6.2


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

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

2016-05-12 Thread Peng Fan

Hi Julien,

On Thu, May 12, 2016 at 11:48:30AM +0100, Julien Grall wrote:
>Hi Peng,
>
>On 12/05/16 07:36, Peng Fan wrote:
>>To ARM64, "frametable_size >> SECOND_SHIFT" means the number
>>of second level entries, not the number of second level pages.
>>
>>"DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)"
>>is the correct way to calculate the second level pages needed
>>for frametable mapping.
>
>Good catch!
>
>>Signed-off-by: Peng Fan 
>>Cc: Stefano Stabellini 
>>Cc: Julien Grall 
>>---
>>  xen/arch/arm/mm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>>diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>>index 0a4f845..7c7f8e9 100644
>>--- a/xen/arch/arm/mm.c
>>+++ b/xen/arch/arm/mm.c
>>@@ -767,7 +767,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
>>pe)
>>  base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));
>>
>>  #ifdef CONFIG_ARM_64
>>-nr_second = frametable_size >> SECOND_SHIFT;
>>+nr_second = DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES);
>
>
>I think the following would be clearer:
>
>ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;

Agree.

>
>This would also benefit a comment to explain that second level of page table
>are populating.

Do you mean I need to add a comment for the upper code?

For the commit log, I would like to change to this:
"
To ARM64, "frametable_size >> SECOND_SHIFT" means the number
of second level entries, not the number of second level pages.

"ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT" which means
the number of the first level entries(the number of second level pages),
is the correct one that should be used.
"
How do you think?

Thanks,
Peng.
>
>>  second_base = alloc_boot_pages(nr_second, 1);
>>  second = mfn_to_virt(second_base);
>>  for ( i = 0; i < nr_second; i++ )
>>
>
>Regards,
>
>-- 
>Julien Grall

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

Re: [Xen-devel] [PATCH] v3 - Add exclusive locking option to block-iscsi

2016-05-12 Thread Wei Liu

Hi Steven

On Mon, May 09, 2016 at 02:22:48PM +1000, Steven Haigh wrote:
> On 2016-05-05 15:52, Steven Haigh wrote:
> >On 2016-05-05 12:32, Steven Haigh wrote:
> >>Overview
> >>
> >>If you're using iSCSI, you can mount a target by multiple Dom0
> >>machines on the same target. For non-cluster aware filesystems, this
> >>can lead to disk corruption and general bad times by all. The iSCSI
> >>protocol allows the use of persistent reservations as per the SCSI
> >>disk spec. Low level SCSI commands for locking are handled by the
> >>sg_persist program (bundled with sg3_utils package in EL).
> >>
> >>The aim of this patch is to create a 'locktarget=y' option specified
> >>within the disk 'target' command for iSCSI to lock the target in
> >>exclusive mode on VM start with a key generated from the local systems
> >>IP, and release this lock on the shutdown of the DomU.
> >>
> >>Example Config:
> >>disk=
> >>['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']

You seem to suggest an extension (locktarget) to disk spec as well but
you patch doesn't contain modification to
docs/txt/misc/xl-disk-configuration.txt.

Wei.

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

Re: [Xen-devel] [PATCH V2 2/2] xen/arm: mm: clean up code in setup_pagetables

2016-05-12 Thread Julien Grall


Hi Peng,

Hi Peng,

On 12/05/16 03:01, Peng Fan wrote:

In setup_pagetables, need to map BOOT_RELOC_VIRT_START
in xen_second and boot_second, so we can merge the two
pieces code into one code block.


There is a missing subject for "need". I would say:

"The base of address for the relocated xen needs to be mapped at the 
same virtual address (BOOT_RELOC_VIRT_START) in both the boot and 
runtime page tables. So we can merge the two pieces of code into on code 
block."




Also no need to use write_pte when map BOOT_RELOC_VIRT_START
in xen_second, because CPU0 is using boot page tables now.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

V2:
  Follow Julien's comments:
split the V1 patch into two patches, this patch is the code movement part.

  xen/arch/arm/mm.c | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index addd699..0a4f845 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,11 +443,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  lpae_t pte, *p;
  int i;

-/* Map the destination in the boot misc area. */
-dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
-write_pte(xen_second + second_table_offset(dest_va), pte);
-
  /* Calculate virt-to-phys offset for the new location */
  phys_offset = xen_paddr - (unsigned long) _start;

@@ -494,9 +489,12 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START)];
  xen_second[second_table_offset(BOOT_FDT_VIRT_START)] = pte;

-/* Map the destination in the boot misc area. */
+/* ... Boot Misc area for xen relocation */
  dest_va = BOOT_RELOC_VIRT_START;
  pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
+/* Map the destination in xen_second. */
+xen_second[second_table_offset(dest_va)] = pte;
+/* Map the destination in boot_second. */
  write_pte(boot_second + second_table_offset(dest_va), pte);
  flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
  #ifdef CONFIG_ARM_64



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

2016-05-12 Thread Stefano Stabellini

On Thu, 12 May 2016, Matt Fleming wrote:
> On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote:
> > 
> > As said above, I will rebase this patch on top of the EFI next branch.
> 
> OK thanks.
> 
> Note that it is not possible to escape merge conflicts, since there
> are changes in the xen tip tree that are not in the EFI next branch
> and vice versa.
> 
> For example these commits from xen/linux-next look relevant,
> 
>   8e147fcc3ffa ("FDT: Add a helper to get the subnode by given name")
>   37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI 
> runtime services")
>   acb2c923a860 ("XEN: EFI: Move x86 specific codes to architecture directory")
>   055be2d42408 ("ARM: Xen: Document UEFI support on Xen ARM virtual 
> platforms")
>   3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")

From a diffstat perspective, the changes introduced by these commits
affect drivers/of/fdt.c, arch/arm/xen, arch/x86/xen, drivers/xen and
little else. I don't think they should cause merge troubles.


> Linus, Stefano, tip-folks: I'm soliciting opinions on the correct way
> to handle this inter-tree dependency where we've got changes to EFI
> code in two separate trees and Shannon wants to write patches on top
> of both.
> 
> I'm guessing the best solution is to merge xen/linux-next and efi/next
> into a topic branch either in the EFI tree or Xen tree, but I want to
> be cautious of the branch history that will create.

I am OK with that. You and I will have to be careful with the pull
requests.


> (In hindsight all of these change should have probably gone via the
> EFI tree.)

That is still possible if deemed best. 

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Wei Liu

On Wed, May 11, 2016 at 12:38:46PM +, Paul Durrant wrote:
> > -Original Message-
> > From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> > Sent: 11 May 2016 13:23
> > To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> > Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> > server
> > 
> > On 11/05/16 13:18, Olaf Hering wrote:
> > > Migrating a HVM guest from staging-4.4 to staging fails:
> > >
> > > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > > char device redirected to /dev/pts/3 (label serial0)
> > > xen: ioreq server create: Cannot allocate memory
> > > qemu-system-x86_64: xen hardware virtual machine initialisation failed
> > >
> > > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4
> > does not
> > > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7
> > fails to
> > > configure the guest properly?
> > 
> > HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.  CC'ing
> > Paul
> > who did this work.
> 
> The problem is because the new QEMU will assume that the guest was 
> provisioned with ioreq server pages. Somehow it needs to know to behave as a 
> 'default' ioreq server (as qemu trad would) in which case the compatibility 
> code in the hypervisor would DTRT. I guess it would be ok to just have QEMU 
> fall back to the old 'default' HVM param mechanism if creation of an IOREQ 
> server fails. The only other way out would be allow Xen to 'steal' the 
> default server's pages if it doesn't exist.
> The former obviously requires a patch to QEMU (but the compat code already 
> exists as a compile-time option so it's probably a small-ish change) and the 
> latter requires a patch to Xen. Which is more preferable at this stage?
> 

Please help me understand: both ways require patching latest xen.git or
qemu.git, not patching xen 4.4 or the qemu shipped in 4.4. Right?

Wei.

>   Paul
> 
> > 
> > ~Andrew
> ___
> 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] live migrating hvm from 4.4 to 4.7 fails in ioreq server

2016-05-12 Thread Wei Liu

On Wed, May 11, 2016 at 03:07:16PM +0200, Olaf Hering wrote:
> On Wed, May 11, Olaf Hering wrote:
> 
> > Migration from staging-4.4 to staging-4.6 fails in the same way. We did
> > not have a 4.6 based Xen, so noone noticed until now.
> 
> And migration from staging-4.5 to staging works as well. So this leaves
> staging-4.4.
> 

`git log` shows that the support of multiple ioreq servers was added in
4.5. That probably explains it.

Wei.

> Olaf
> 
> ___
> 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 V2 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

2016-05-12 Thread Julien Grall


Hi Peng,

On 12/05/16 03:01, Peng Fan wrote:

CPU0 is using the boot pages table before relocating xen and
xen_second is not part of them. So, no need to flush the TLB
when filling xen_second.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 


This will be Xen 4.8 material:

Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

2016-05-12 Thread Julien Grall


Hi Peng,

On 12/05/16 07:36, Peng Fan wrote:

To ARM64, "frametable_size >> SECOND_SHIFT" means the number
of second level entries, not the number of second level pages.

"DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)"
is the correct way to calculate the second level pages needed
for frametable mapping.


Good catch!


Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
  xen/arch/arm/mm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0a4f845..7c7f8e9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -767,7 +767,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
  base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));

  #ifdef CONFIG_ARM_64
-nr_second = frametable_size >> SECOND_SHIFT;
+nr_second = DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES);



I think the following would be clearer:

ROUNDUP(frametable_size, FIRST_SIZE) >> FIRST_SHIFT;

This would also benefit a comment to explain that second level of page 
table are populating.



  second_base = alloc_boot_pages(nr_second, 1);
  second = mfn_to_virt(second_base);
  for ( i = 0; i < nr_second; i++ )



Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable baseline-only test] 44407: regressions - trouble: blocked/broken/fail/pass

2016-05-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 44407 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44407/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44400
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44400
 build-armhf   3 host-install(3) broken REGR. vs. 44400
 test-amd64-i386-migrupgrade  20 guest-start/debianfail REGR. vs. 44400

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 44400
 build-i386-rumpuserxen6 xen-buildfail   like 44400
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44400
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44400

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47
baseline version:
 xen  4084fee7a3204bf8ccf7d993dea09186e4e7dd48

Last test of basis44400  2016-05-10 08:19:39 Z2 days
Testing same since44407  2016-05-12 02:20:16 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Ross Lagerwall 
  Tim Deegan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvops

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

2016-05-12 Thread Andrew Cooper

On 12/05/16 10:40, He Chen wrote:
> % Intel L2 Cache Allocation Technology (L2 CAT) Feature
> % Revision 1.0
>
> \clearpage
>
> Hi all,
>
> We plan to bring new PQoS feature called Intel L2 Cache Allocation
> Technology (L2 CAT) to Xen.
>
> L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
> Xeon does not support L2 CAT in current generations.
>
> This is the initial design of L2 CAT. It might be a little long and
> detailed, hope it doesn't matter.
>
> Comments and suggestions are welcome :-)

First of all, thankyou very much for choosing to do the doc like this. 
It is nice to see this format starting to get used.

> ## The relationship between L2 CAT and L3 CAT/CDP
>
> L2 CAT is independent of L3 CAT/CDP, which means L2 CAT would be enabled
> while L3 CAT/CDP is disabled, or L2 CAT and L3 CAT/CDP are all enabled.

The wording here is a little odd, given that no hardware currently
supports both L2 and L3.

It might be easier to say:

L2 CAT is independent of L3 CAT/CDP, and both may be enabled at the same
time.

Otherwise, everything else looks great.

~Andrew

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

Re: [Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 11:40,  wrote:
> % Intel L2 Cache Allocation Technology (L2 CAT) Feature
> % Revision 1.0
> 
> \clearpage
> 
> Hi all,
> 
> We plan to bring new PQoS feature called Intel L2 Cache Allocation
> Technology (L2 CAT) to Xen.
> 
> L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
> Xeon does not support L2 CAT in current generations.

Looks mostly like a direct (and hence reasonable) extension of what
we have for L3 right now. One immediate question I have is whether
tying this to per-socket information is a good idea. As soon as Xeon-s
would also gain such functionality, things would (aiui) need to become
per-core (as L2 is per core there iirc).

The other question is whether with Xen we care enough about Atoms
to add code that's of use only there.

Jan

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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

2016-05-12 Thread Matt Fleming

On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote:
> 
> As said above, I will rebase this patch on top of the EFI next branch.

OK thanks.

Note that it is not possible to escape merge conflicts, since there
are changes in the xen tip tree that are not in the EFI next branch
and vice versa.

For example these commits from xen/linux-next look relevant,

  8e147fcc3ffa ("FDT: Add a helper to get the subnode by given name")
  37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI 
runtime services")
  acb2c923a860 ("XEN: EFI: Move x86 specific codes to architecture directory")
  055be2d42408 ("ARM: Xen: Document UEFI support on Xen ARM virtual platforms")
  3915fea959b6 ("ARM: XEN: Move xen_early_init() before efi_init()")

Linus, Stefano, tip-folks: I'm soliciting opinions on the correct way
to handle this inter-tree dependency where we've got changes to EFI
code in two separate trees and Shannon wants to write patches on top
of both.

I'm guessing the best solution is to merge xen/linux-next and efi/next
into a topic branch either in the EFI tree or Xen tree, but I want to
be cautious of the branch history that will create.

(In hindsight all of these change should have probably gone via the
EFI tree.)

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

[Xen-devel] [xen-4.5-testing test] 94030: regressions - FAIL

2016-05-12 Thread osstest service owner

flight 94030 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94030/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 93989
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 93989

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 93989
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93989

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z1 days
Testing same since94030  2016-05-11 13:08:55 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  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-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 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

Re: [Xen-devel] [PATCH v4 2/3] xen: write information about supported backends

2016-05-12 Thread Anthony PERARD

On Thu, May 12, 2016 at 07:47:46AM +0200, Juergen Gross wrote:
> Add a Xenstore directory for each supported pv backend. This will allow
> Xen tools to decide which backend type to use in case there are
> multiple possibilities.
> 
> The information is added under
> /local/domain//device-model//backends
> before the "running" state is written to Xenstore. Using a directory
> for each backend enables us to add parameters for specific backends
> in the future.
> 
> This interface is documented in the Xen source repository in the file
> docs/misc/qemu-backends.txt
> 
> In order to reuse the Xenstore directory creation already present in
> hw/xen/xen_devconfig.c move the related functions to
> hw/xen/xen_backend.c where they fit better.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

2016-05-12 Thread Jan Beulich

>>> On 11.05.16 at 15:51,  wrote:
> During Xen boot I am seeing the panic in the subject line from 
> .../xen/drivers/passthrough/vgt/qinval.c

And this is with current staging, or some much older version of Xen?
(ISTR some issue with the invalidation request getting sent to the
wrong IOMMU, leading to a timeout.)

> From the Fault Status Register (= 0x40 (ITE)). I am seeing a hardware 
> timeout on the invalidate
> 
> Disabling queued invalidation is not an option.  I need to find out why the 
> operation is timing out and fix it.  
> 
> I found two timeouts; one in software and one in hardware. 
> After the invalidate is submitted there is a wait packet submitted and the 
> boot software waits for the wait packet to complete in a loop with a software 
> timeout.  At the end of the software timeout it issues the panic.  I can 
> increase the software timeout but it still doesn't solve the problem.  Just 
> before the panic I dump the value of the Fault Status Register and I see that 
> the hardware has already timed out (FSTS_REG = 0x40 = ITE = "Invalidation 
> Timeout Error").  As a first step in solving this I would like to increase 
> the hardware timeout value.
> 
> I have the Intel spec and I was reading from the spec...
> 
> " Hardware starts an invalidation completion timer for this ITag, and issues 
> the invalidation request message to the specified endpoint. If the 
> invalidation command from software is for a first-level mapping, the 
> invalidation request message is generated with the appropriate PASID prefix 
> to identify the target PASID. The invalidation completion time-out value is 
> recommended to be sufficiently larger than the PCI-Express read completion 
> time-outs. "
> 
> The above leads me to believe that there should be some way of setting the 
> invalidation completion time-out value.  Unfortunately I couldn't find 
> anything in the Intel spec that tells me how to set the "invalidation 
> completion time-out".   Can someone point me in the right direction to 
> setting the completion timer?

For this I guess you should have Cc-ed the VT-d maintainers, which
I have now done.

Jan


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

[Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

2016-05-12 Thread He Chen

% Intel L2 Cache Allocation Technology (L2 CAT) Feature
% Revision 1.0

\clearpage

Hi all,

We plan to bring new PQoS feature called Intel L2 Cache Allocation
Technology (L2 CAT) to Xen.

L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
Xeon does not support L2 CAT in current generations.

This is the initial design of L2 CAT. It might be a little long and
detailed, hope it doesn't matter.

Comments and suggestions are welcome :-)

# Basics

 
 Status: **Tech Preview**

Architecture(s): Intel x86

   Component(s): Hypervisor, toolstack

   Hardware: Atom codename Goldmont and beyond
 

# Overview

L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
CPU's shared L2 cache based on application priority or Class of Service
(COS). Each CLOS is configured using capacity bitmasks (CBM) which
represent cache capacity and indicate the degree of overlap and
isolation between classes. Once L2 CAT is configured, the processor
allows access to portions of L2 cache according to the established
class of service (COS).

# Technical information

L2 CAT is a member of Intel PQoS features and part of CAT, it shares
some base PSR infrastructure in Xen.

## Hardware perspective

L2 CAT defines a new range MSRs to assign different L2 cache access
patterns which are known as CBMs (Capacity BitMask), each CBM is
associated with a COS.

```

+++
   IA32_PQR_ASSOC   | MSR (per socket)   |Address |
 ++---+---+ +++
 ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
 ++---+---+ +++
└-> | ...|  ...   |
+++
| IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
+++
```

When context switch happens, the COS of VCPU is written to per-thread
MSR `IA32_PQR_ASSOC`, and then hardware enforces L2 cache allocation
according to the corresponding CBM.

## The relationship between L2 CAT and L3 CAT/CDP

L2 CAT is independent of L3 CAT/CDP, which means L2 CAT would be enabled
while L3 CAT/CDP is disabled, or L2 CAT and L3 CAT/CDP are all enabled.

L2 CAT uses a new range CBMs from 0xD10 ~ 0xD10+n (n<64), following by
the L3 CAT/CDP CBMs, and supports setting different L2 cache accessing
patterns from L3 cache.

N.B. L2 CAT and L3 CAT/CDP share the same COS field in the same
associate register `IA32_PQR_ASSOC`, that means one COS corresponds to a
pair of L2 CBM and L3 CBM.

In the initial implementation, L2 CAT is shown up on Atom codename
Goldmont firstly and there is no platform support both L2 & L3 CAT so
far.

## Design Overview

* Core COS/CBM association

  When enforcing L2 CAT, all cores of domains have the same default
  COS (COS0) which associated to the fully open CBM (all ones bitmask)
  to access all L2 cache. The default COS is used only in hypervisor
  and is transparent to tool stack and user.

  System administrator can change PQoS allocation policy at runtime by
  tool stack. Since L2 CAT share COS with L3 CAT/CDP, a COS corresponds
  to a 2-tuple, like [L2 CBM, L3 CBM] with only-CAT enabled, when CDP
  is enabled, one COS corresponds to a 3-tuple, like [L2 CBM,
  L3 Code_CBM, L3 Data_CBM]. If neither L3 CAT nor L3 CDP is enabled,
  things would be easier, one COS corresponds to one L2 CBM.

* VCPU schedule

  This part reuses L3 CAT COS infrastructure.

* Multi-sockets

  Different sockets may have different L2 CAT capability (e.g. max COS)
  although it is consistent on the same socket. So the capability of
  per-socket L2 CAT is specified.

## Implementation Description

* Hypervisor interfaces:

  1. Ext: Boot line parameter "psr=cat" now will enable L2 CAT and L3
  CAT if hardware supported.

  2. New: SYSCTL:
  - XEN_SYSCTL_PSR_CAT_get_l2_info: Get L2 CAT information.

  3. New: DOMCTL:
  - XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM: Get L2 CBM for a domain.
  - XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM: Set L2 CBM for a domain.

* xl interfaces:

  1. Ext: psr-cat-show: Show system/domain L2 CAT information.
  => XEN_SYSCTL_PSR_CAT_get_l2_info /
 XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM

  2. Ext: psr-mba-set -l2 domain-id cbm
  Set L2 cbm for a domain.
  => XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM

* Key data structure:

  1. Combined PSR bitmasks structure

 ```
 struct psr_mask {
 struct l3_cat {
 union {
 uint64_t cbm;
 struct {
 uint64_t code;
 uint64_t data;
 };

[Xen-devel] [RFC Design Doc] Intel L2 Cache Allocation Technology (L2 CAT) Feature enabling

2016-05-12 Thread He Chen

% Intel L2 Cache Allocation Technology (L2 CAT) Feature
% Revision 1.0

\clearpage

Hi all,

We plan to bring new PQoS feature called Intel L2 Cache Allocation
Technology (L2 CAT) to Xen.

L2 CAT is supported on Atom codename Goldmont and beyond. “Big-core”
Xeon does not support L2 CAT in current generations.

This is the initial design of L2 CAT. It might be a little long and
detailed, hope it doesn't matter.

Comments and suggestions are welcome :-)

# Basics

 
 Status: **Tech Preview**

Architecture(s): Intel x86

   Component(s): Hypervisor, toolstack

   Hardware: Atom codename Goldmont and beyond
 

# Overview

L2 CAT allows an OS or Hypervisor/VMM to control allocation of a
CPU's shared L2 cache based on application priority or Class of Service
(COS). Each CLOS is configured using capacity bitmasks (CBM) which
represent cache capacity and indicate the degree of overlap and
isolation between classes. Once L2 CAT is configured, the processor
allows access to portions of L2 cache according to the established
class of service (COS).

# Technical information

L2 CAT is a member of Intel PQoS features and part of CAT, it shares
some base PSR infrastructure in Xen.

## Hardware perspective

L2 CAT defines a new range MSRs to assign different L2 cache access
patterns which are known as CBMs (Capacity BitMask), each CBM is
associated with a COS.

```

+++
   IA32_PQR_ASSOC   | MSR (per socket)   |Address |
 ++---+---+ +++
 ||COS|   | | IA32_L2_QOS_MASK_0 | 0xD10  |
 ++---+---+ +++
└-> | ...|  ...   |
+++
| IA32_L2_QOS_MASK_n | 0xD10+n (n<64) |
+++
```

When context switch happens, the COS of VCPU is written to per-thread
MSR `IA32_PQR_ASSOC`, and then hardware enforces L2 cache allocation
according to the corresponding CBM.

## The relationship between L2 CAT and L3 CAT/CDP

L2 CAT is independent of L3 CAT/CDP, which means L2 CAT would be enabled
while L3 CAT/CDP is disabled, or L2 CAT and L3 CAT/CDP are all enabled.

L2 CAT uses a new range CBMs from 0xD10 ~ 0xD10+n (n<64), following by
the L3 CAT/CDP CBMs, and supports setting different L2 cache accessing
patterns from L3 cache.

N.B. L2 CAT and L3 CAT/CDP share the same COS field in the same
associate register `IA32_PQR_ASSOC`, that means one COS corresponds to a
pair of L2 CBM and L3 CBM.

In the initial implementation, L2 CAT is shown up on Atom codename
Goldmont firstly and there is no platform support both L2 & L3 CAT so
far.

## Design Overview

* Core COS/CBM association

  When enforcing L2 CAT, all cores of domains have the same default
  COS (COS0) which associated to the fully open CBM (all ones bitmask)
  to access all L2 cache. The default COS is used only in hypervisor
  and is transparent to tool stack and user.

  System administrator can change PQoS allocation policy at runtime by
  tool stack. Since L2 CAT share COS with L3 CAT/CDP, a COS corresponds
  to a 2-tuple, like [L2 CBM, L3 CBM] with only-CAT enabled, when CDP
  is enabled, one COS corresponds to a 3-tuple, like [L2 CBM,
  L3 Code_CBM, L3 Data_CBM]. If neither L3 CAT nor L3 CDP is enabled,
  things would be easier, one COS corresponds to one L2 CBM.

* VCPU schedule

  This part reuses L3 CAT COS infrastructure.

* Multi-sockets

  Different sockets may have different L2 CAT capability (e.g. max COS)
  although it is consistent on the same socket. So the capability of
  per-socket L2 CAT is specified.

## Implementation Description

* Hypervisor interfaces:

  1. Ext: Boot line parameter "psr=cat" now will enable L2 CAT and L3
  CAT if hardware supported.

  2. New: SYSCTL:
  - XEN_SYSCTL_PSR_CAT_get_l2_info: Get L2 CAT information.

  3. New: DOMCTL:
  - XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM: Get L2 CBM for a domain.
  - XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM: Set L2 CBM for a domain.

* xl interfaces:

  1. Ext: psr-cat-show: Show system/domain L2 CAT information.
  => XEN_SYSCTL_PSR_CAT_get_l2_info /
 XEN_DOMCTL_PSR_CAT_OP_GET_L2_CBM

  2. Ext: psr-mba-set -l2 domain-id cbm
  Set L2 cbm for a domain.
  => XEN_DOMCTL_PSR_CAT_OP_SET_L2_CBM

* Key data structure:

  1. Combined PSR bitmasks structure

 ```
 struct psr_mask {
 struct l3_cat {
 union {
 uint64_t cbm;
 struct {
 uint64_t code;
 uint64_t data;
 };

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

2016-05-12 Thread Dushyant Behl

Hi Meng,

On Thu, May 12, 2016 at 6:30 AM, Meng Xu  wrote:
> Hi Dushyant,
>
> On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl  
> wrote:
>
> May I know which u-boot repo and which branch you used to enable the
> non-secure mode? If you could also share your u-boot config file, that
> will be awesome!

I'm using the u-boot from mainline git://git.denx.de/u-boot.git on my
Jetson board, I'm using the tegra-uboot-flasher-scripts from Nvidia
(https://github.com/NVIDIA/tegra-uboot-flasher-scripts)
to flash u-boot and they use the denx mainline branch with default
Jetson-TK1 configuration.

> The u-boot from NVIDEA didn't turn on the HYP mode. I tried the
> git://git.denx.de/u-boot.git, tag v2016.03, but the board won't boot
> after I flashed the uboot. No message at all... :-(
> If I use NVIDEA's uboot, I can boot into the linux kernel without problem.

The default configuration of u-boot doesn't enables HYP mode when you boot
the kernel. You can change that in the configuration by disabling

CONFIG_ARMV7_BOOT_SEC_DEFAULT in the config file.

But you can also achieve the same thing by setting the environment
variable in u-boot

"bootm_boot_mode=nonsec"

now booting the linux kernel through bootm command will boot it in HYP mode.
I'm also using the bootm_boot_mode variable set to nonsec without
changing the default
configuration of u-boot.

I had some problems booting the L4T kernel in HYP mode on Jetson, so I was using
the linux kernel from Jan Kiszka's development tree -
http://git.kiszka.org/linux.git/,  branch queues/assorted
which has some of the PSCI patches required to boot linux. Although If
you do get the
mainline linux or l4t kernel to boot in nonsec mode or on Xen, please
do let me know.

Thanks,
Dushyant

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

Re: [Xen-devel] [PATCH v3 5/6] build: convert perfc{, _arrays} to Kconfig

2016-05-12 Thread Jan Beulich

>>> On 11.05.16 at 20:39,  wrote:
> On 5/11/16 4:53 AM, Jan Beulich wrote:
> On 10.05.16 at 23:05,  wrote:
>>> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
>>> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.
>> 
>> I don't understand the "to minimize code changes" part.
> 
> Instead of calling the options "CONFIG_PERFC" and CONFIG_PERFC_ARRAYS"
> as the originals would be called.

How would using those have resulted in more code changes? The
changes would have looked a little different, but it would have been
the same amount of lines modified.

> I do most of these Kconfig patches with sed and not by hand.

Sure, but that's unrelated to this afaict.

>>> @@ -12,18 +10,15 @@ lto   ?= n
>>>  
>>>  include $(XEN_ROOT)/Config.mk
>>>  
>>> -# Hardcoded configuration implications and dependencies.
>>> -# Do this is a neater way if it becomes unwieldy.
>>> -ifeq ($(perfc_arrays),y)
>>> -perfc := y
>>> -endif
>>> -
>>>  ifneq ($(origin kexec),undefined)
>>>  $(error "You must use 'make menuconfig' to enable/disable kexec now.")
>>>  endif
>>>  ifneq ($(origin crash_debug),undefined)
>>>  $(error "You must use 'make menuconfig' to enable/disable crash_debug 
>>> now.")
>>>  endif
>>> +ifneq ($(origin perfc),undefined)
>>> +$(error "You must use 'make menuconfig' to enable/disable perfc now.")
>>> +endif
>> 
>> I'm pretty sure I've asked before: Why do you add something
>> here for crash_debug and perfc, but not for debug, verbose,
>> and frame_pointer?
> 
> I added the one you had mentioned. I didn't realize it was a uniform
> statement. In the past (for other series) I've been told to drop those
> statements for not common options.

Hmm, I don't recall such requests, but if there were - what is the
criteria for being "not common"?

Jan


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

Re: [Xen-devel] [PATCH v3 3/6] build: convert verbose to Kconfig

2016-05-12 Thread Jan Beulich

>>> On 11.05.16 at 19:37,  wrote:
> On 5/11/16 4:45 AM, Jan Beulich wrote:
> On 10.05.16 at 23:05,  wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -15,4 +15,11 @@ config DEBUG
>>>   option is intended for development purposes only, and not for
>>>   production use.
>>>  
>>> +config VERBOSE_DEBUG
>>> +   bool "Verbose debug messages"
>>> +   default DEBUG
>>> +   ---help---
>>> + Guest output from HYPERVISOR_console_io and hypervisor parsing
>>> + ELF images (dom0) is logged in the Xen ring buffer.
>> 
>> The "depends on DEBUG || EXPERT" did get lost here (or, looking at
>> the following patch, a respective "if" framing them all).
> 
> This option is always visible to someone and is not dependent on DEBUG
> due to the if not being possible in the form you asked. So I adjusted it
> to "default DEBUG" as you had asked. I can make this option dependent on
> DEBUG or EXPERT.

Same here - with the menuconfig gone, I don't see why.

Jan


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

Re: [Xen-devel] [PATCH v3 2/6] build: convert crash_debug to Kconfig

2016-05-12 Thread Jan Beulich

>>> On 11.05.16 at 19:35,  wrote:
> On 5/11/16 4:47 AM, Jan Beulich wrote:
> On 10.05.16 at 23:05,  wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -1,6 +1,13 @@
>>>  
>>>  menu "Debugging Options"
>>>  
>>> +config CRASH_DEBUG
>>> +   bool "Crash Debugging Support"
>>> +   depends on X86
>>> +   ---help---
>>> + If you want to be able to attach gdb to Xen to be able to debug
>>> + Xen if it crashes then say Y.
>>> +
>>>  config DEBUG
>>> bool "Developer Checks"
>>> ---help---
>> 
>> Is this really meant to be independent of DEBUG (or EXPERT), as it's
>> being placed ahead of DEBUG?
> 
> That's what we talked about with v2. You wanted it to be independent if
> EXPERT was set but when you have something defined as "menuconfig "
> you cannot then have a rule "if  || EXPERT" as you asked for in v2.
> So I needed to make them independent always which is what I did.
> 
> Let me restate more generically, if things are dependent on a menu for
> the sub-menu items to be displayed (as in v2) then the menu must be
> enabled and cannot be conditionally displayed on another option.
> 
> Roughly think of it this way:
> 
> menuconfig SOME_STATE
> 
> if SOME_STATE || EXPERT
> 
> config OTHER
> 
> endif
> 
> 
> is the following code:
> 
> 
> if (SOME_STATE) {
>   if (SOME_STATE or EXPERT) {
> printf("got here\n");
>   }
> }

But there's no menuconfig anymore, for precisely that reason (aiui).

Jan


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

Re: [Xen-devel] [PATCH v4 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

2016-05-12 Thread Xu, Quan

On May 12, 2016 4:45 PM, Jan Beulich  wrote:
> >>> On 12.05.16 at 07:16,  wrote:
> > Taken together, there are 3 call trees to me_wifi_quirk():
> >
> >  1).
> > ...--me_wifi_quirk()--domain_context_mapping_one()--
> domain_context_map
> > ping()--se
> > tup_hwdom_device()
> >
> > There is no use in calling this function if an
> > earlier error occurred. The change can be more lightweight (the
> > detailed change is pending).
> >
> > 2).  me_wifi_quirk()--domain_context_unmap_one()--...
> >
> >As you mentioned,  while in the unmap case it
> > should probably stay as is, to fit the "best effort" theme.
> >
> >   Then I need to remove the  __must_check annotation
> > of me_wifi_quirk().
> 
> This does not follow from the above. You again should propagate the error in
> all cases (unless it would overwrite an earlier error - as you're doing in 
> various
> other places).
> 

Sorry, I know the item 2).  is tricky,  as I am confused about ' while in the 
unmap case it should probably stay as is, to fit the "best effort" theme '.


Actually, what I need to enhance the p10 are:

- drop ret
- replace the 

 if ( !seg )
-me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
+{
+ret = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
+
+if ( !rc )
+rc = ret;
+}


TO_


-if ( !seg )
-me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
+if ( !seg && !rc )
+rc = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);



btw, I found I am struggling in this v4 and I will spend more time fixing. 
thanks for your patience.
Quan

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

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 09:50,  wrote:
> On May 10, 2016 12:10 AM, Jan Beulich  wrote:
>> >>> On 06.05.16 at 10:54,  wrote:
>> > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long
>> > gfn, unsigned int page_count)
>> > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long gfn,
>> > +   unsigned int page_count)
>> 
>> The new name suggests just one page. Please use e.g.
>> iommu_flush_iotlb_pages() instead.
>> 
> 
> Make sense. 
> 
>> >  {
>> > -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
>> > +iommu_flush_iotlb(d, gfn, 1, page_count);
>> >  }
>> 
>> But of course the question is whether having this wrapper is useful in the 
>> first
>> place,
> 
> 
> This wrapper assumes the 'dma_old_pte_present' is '1', but in another caller 
> intel_iommu_map_page(), i.e. 
> 
> 
>  intel_iommu_map_page()
> {
>...
>  if ( !this_cpu(iommu_dont_flush_iotlb) )
>   iommu_flush_iotlb(d, gfn, dma_pte_present(old), 1);
>...
> }
> 
> 
> the 'dma_old_pte_present' is not sure. 

I'm sorry, but you're looking at this backwards: I suggested to
remove the wrapper, not to move any check into iommu_flush_iotlb().
Removing the wrapper simply means to move the passing of the
hard coded 1 into the current callers of that wrapper.

>> > @@ -1391,13 +1399,19 @@ int domain_context_mapping_one(
>> >  spin_unlock(>lock);
>> >
>> >  /* Context entry was previously non-present (with domid 0). */
>> > -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
>> > -DMA_CCMD_MASK_NOBIT, 1) )
>> > -iommu_flush_write_buffer(iommu);
>> > -else
>> > +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
>> > +DMA_CCMD_MASK_NOBIT, 1);
>> > +
>> > +if ( !rc )
>> >  {
>> >  int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
>> > -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
>> > +rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
>> 
>> Please take the opportunity and add the missing blank line (between
>> declaration(s) and statement(s) in cases like this.
>> 
>> > +}
>> > +
>> > +if ( rc > 0 )
>> 
>> Can iommu_flush_context_device() return a positive value? If so, the logic is
>> now likely wrong. If not (which is what I assume) I'd like to suggest adding 
>> a
>> respective ASSERT() (even if only to document the fact). Or alternatively 
>> this
>> if() could move into the immediately preceding one.
> 
> Check it again. iommu_flush_context_device() can return a positive value.
> [...]
> Could you tell me why the logic is now likely wrong? I will fix it first.

With

rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
DMA_CCMD_MASK_NOBIT, 1);

if ( !rc )
{
int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
}

if ( rc > 0 )
{
iommu_flush_write_buffer(iommu);
rc = 0;
}

it seems pretty clear that you won't call iommu_flush_iotlb_dsi() if
iommu_flush_context_device() returned 1, which doesn't look like
what is wanted at the first glance. But I may be wrong, hence the
"likely" in my earlier reply.

Jan


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

Re: [Xen-devel] [PATCH v4 6/6] hwmon: use smp_call_on_cpu() for dell-smm i8k

2016-05-12 Thread Pali Rohár

On Monday 09 May 2016 16:37:01 Juergen Gross wrote:
> On 21/04/16 15:27, Pali Rohár wrote:
> > On Thursday 21 April 2016 15:12:52 Juergen Gross wrote:
> >> On 21/04/16 12:57, Pali Rohár wrote:
> >>> On Tuesday 05 April 2016 21:31:52 Pali Rohár wrote:
>  On Tuesday 05 April 2016 16:54:14 Guenter Roeck wrote:
> > On Tue, Apr 05, 2016 at 07:10:07AM +0200, Juergen Gross wrote:
> >> Use the smp_call_on_cpu() function to call system management
> >> mode on cpu 0.
> >> Make call secure by adding get_online_cpus() to avoid e.g. suspend
> >> resume cycles in between.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >> V4: add call to get_online_cpus()
> >
> > Pali, any chance to test this ?
> 
>  I can test it, but just on machine where (probably) smm calls can be 
>  send from any cpu... Need some time for testing and I believe I can do 
>  that at the end of the week.
> >>>
> >>> Sorry I had absolutely no more free time last weekend :-( And same
> >>> prediction is for this weekend and also next one...
> >>
> >> Pali, I've got a Dell laptop (Latitude E6440) here. Would this device be
> >> okay for a test?
> > 
> > Hi!
> > 
> > Proper regression test should check if this patch does not break any
> > function or drivers dependent on dcdbas.ko. And should be done on both
> > notebook devices: which needs to issue that smm call on cpu 0 and also
> > on which it is not needed.
> 
> Hmm, couldn't get one which needs smm to be called on cpu 0.
> OTOH I've done various tests and added a printk() in raise_smm()
> and i8k_smm_func() issuing the cpu number it was called on.

Understood, those machines are old and probably rare now.

> > Some notebooks which needs smm call to issued from cpu 0 can be found in
> > git commit messages of i8k, dell-laptop or dcdbas kernel drivers.
> > 
> >> What would you do for testing? In case you can give me
> >> some hints how to do a sensible test I'd do it.
> > 
> > Test e.g. dell-laptop.ko driver. It provides /sys interface for changing
> > keyboard backlight or changing rfkill switches (bluetooth wifi).
> 
> Done.
> 
> > Also test tools from libsmbios (userspace) package.
> 
> Done.
> 
> > There must be no difference in output/functionality with or without your
> > patches.
> 
> Verified.
> 
> >> I've verified by adding a printk() to smp_call_on_cpu() that at least
> >> one of the modified drivers has been used during system boot.
> > 
> > Also you can patch i8k/dcdbas smm function to print cpu number on which
> > is code running (to verify that it was really called on cpu 0 as
> > needed).
> 
> Done.
> 
> I tested suspend/resume, too, as adding get_online_cpus() might have
> changed behavior. Worked like a charm. :-)

Ok, I think this should be enough. You can add my Acked-by.

-- 
Pali Rohár
pali.ro...@gmail.com

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

Re: [Xen-devel] [PATCH v4 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

2016-05-12 Thread Jan Beulich

>>> On 12.05.16 at 07:16,  wrote:
> Taken together, there are 3 call trees to me_wifi_quirk():
> 
>  1). 
> ...--me_wifi_quirk()--domain_context_mapping_one()--domain_context_mapping()--se
> tup_hwdom_device()
> 
> There is no use in calling this function if an earlier 
> error occurred. The change can be more lightweight (the detailed change is 
> pending).
> 
> 2).  me_wifi_quirk()--domain_context_unmap_one()--...
> 
>As you mentioned,  while in the unmap case it should 
> probably stay as is, to fit the "best effort" theme. 
> 
>   Then I need to remove the  __must_check annotation  of 
> me_wifi_quirk().

This does not follow from the above. You again should propagate
the error in all cases (unless it would overwrite an earlier error - as
you're doing in various other places).

Jan


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

[Xen-devel] [distros-debian-wheezy test] 44409: trouble: blocked/broken

2016-05-12 Thread Platform Team regression test user

flight 44409 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44409/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]

Regressions which are regarded as allowable (not blocking):
 build-armhf   3 host-install(3)  broken like 44389
 build-armhf-pvops 3 host-install(3)  broken like 44389
 build-amd64-pvops 3 host-install(3)  broken like 44389
 build-amd64   3 host-install(3)  broken like 44389
 build-i3863 host-install(3)  broken like 44389
 build-i386-pvops  3 host-install(3)  broken like 44389

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a

baseline version:
 flight   44389

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  blocked 



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] Xen 4.7 Test Day Instructions for RC2+ : Call to action for people who added new features / functionality to Xen 4.7

2016-05-12 Thread Dario Faggioli

On Tue, May 10, 2016 at 10:46 AM, George Dunlap
 wrote:
> On 10/05/16 03:18, Dario Faggioli wrote:
>> On Mon, 2016-05-09 at 17:55 +0100, Lars Kurth wrote:
 Hard affinity tests shouldn't be too difficult to add in.
>>>
>>> That would be great
>>>
>> George, if you are not into this already, I can do it.
>
> That would be great, thanks. :-)
>
I've added a section about the new features in Credit2:
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Credit2_runqueue_arrangement_and_hard-affinity_support

And I've also added more info and more examples about RTDS:
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#RTDS_scheduler_improvements

Regards,
Dario
-- 
<> (Raistlin Majere)
---
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH v4 01/10] vt-d: fix the IOMMU flush issue

2016-05-12 Thread Xu, Quan

On May 10, 2016 12:10 AM, Jan Beulich  wrote:
> >>> On 06.05.16 at 10:54,  wrote:
> > -static void intel_iommu_iotlb_flush(struct domain *d, unsigned long
> > gfn, unsigned int page_count)
> > +static void iommu_flush_iotlb_page(struct domain *d, unsigned long gfn,
> > +   unsigned int page_count)
> 
> The new name suggests just one page. Please use e.g.
> iommu_flush_iotlb_pages() instead.
> 

Make sense. 

> >  {
> > -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
> > +iommu_flush_iotlb(d, gfn, 1, page_count);
> >  }
> 
> But of course the question is whether having this wrapper is useful in the 
> first
> place,


This wrapper assumes the 'dma_old_pte_present' is '1', but in another caller 
intel_iommu_map_page(), i.e. 


 intel_iommu_map_page()
{
   ...
 if ( !this_cpu(iommu_dont_flush_iotlb) )
  iommu_flush_iotlb(d, gfn, dma_pte_present(old), 1);
   ...
}


the 'dma_old_pte_present' is not sure. 

in intel_iommu_map_page(),  if we can check the 'dma_pte_present(old)':
  -- 1, flush the pages.
  -- 0, don't flush the pages.

Then we can remove this wrapper.

If my description is not clear, I can send out the related change.

> the more that ...
> 
> > @@ -639,7 +646,7 @@ static void dma_pte_clear_one(struct domain
> *domain, u64 addr)
> >  iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
> >
> >  if ( !this_cpu(iommu_dont_flush_iotlb) )
> > -__intel_iommu_iotlb_flush(domain, addr >> PAGE_SHIFT_4K, 1, 1);
> > +iommu_flush_iotlb(domain, addr >> PAGE_SHIFT_4K, 1, 1);
> 
> ... it's being open coded here. IOW if you want to retain the wrapper, please
> use it here.
>

Waiting for the above discussion, if we still need the wrapper, I will use it 
here.


 
> > @@ -1391,13 +1399,19 @@ int domain_context_mapping_one(
> >  spin_unlock(>lock);
> >
> >  /* Context entry was previously non-present (with domid 0). */
> > -if ( iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> > -DMA_CCMD_MASK_NOBIT, 1) )
> > -iommu_flush_write_buffer(iommu);
> > -else
> > +rc = iommu_flush_context_device(iommu, 0, (((u16)bus) << 8) | devfn,
> > +DMA_CCMD_MASK_NOBIT, 1);
> > +
> > +if ( !rc )
> >  {
> >  int flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> > -iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> > +rc = iommu_flush_iotlb_dsi(iommu, 0, 1, flush_dev_iotlb);
> 
> Please take the opportunity and add the missing blank line (between
> declaration(s) and statement(s) in cases like this.
> 
> > +}
> > +
> > +if ( rc > 0 )
> 
> Can iommu_flush_context_device() return a positive value? If so, the logic is
> now likely wrong. If not (which is what I assume) I'd like to suggest adding a
> respective ASSERT() (even if only to document the fact). Or alternatively this
> if() could move into the immediately preceding one.
> 


Check it again. iommu_flush_context_device() can return a positive value.

If VT-d QI is enabled, the call tree up to iommu_flush_context_device():
 -- flush_context_qi()  -- iommu_flush_context_device() 


i.e. 

In flush_context_qi()
{
...
if ( flush_non_present_entry )
{
if ( !cap_caching_mode(iommu->cap) )
return 1;
else
did = 0;
}
...
}


and the ' flush_non_present_entry '  is really '1' for above code.



Could you tell me why the logic is now likely wrong? I will fix it first.

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

Re: [Xen-devel] [libvirt] [PATCH 1/3] libxl: switch to using libxl_domain_create_restore from v4.4 API

2016-05-12 Thread Olaf Hering

On Wed, May 11, Jim Fehlig wrote:

> https://www.redhat.com/archives/libvir-list/2016-May/msg00686.html

Perhaps configure.ac should be changed to reject libxl upfront. It looks
like the assignment of LIBXL_CFLAGS should be moved up, so that
AC_CHECK_LIB gets the -DLIBXL_API_VERSION as well. I will provide a
patch for that.

Olaf

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

[Xen-devel] [PATCH] xen/arm: mm: fix nr_second calculation in setup_frametable_mappings

2016-05-12 Thread Peng Fan

To ARM64, "frametable_size >> SECOND_SHIFT" means the number
of second level entries, not the number of second level pages.

"DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES)"
is the correct way to calculate the second level pages needed
for frametable mapping.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/mm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0a4f845..7c7f8e9 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -767,7 +767,7 @@ void __init setup_frametable_mappings(paddr_t ps, paddr_t 
pe)
 base_mfn = alloc_boot_pages(frametable_size >> PAGE_SHIFT, 32<<(20-12));
 
 #ifdef CONFIG_ARM_64
-nr_second = frametable_size >> SECOND_SHIFT;
+nr_second = DIV_ROUND_UP(frametable_size >> SECOND_SHIFT, LPAE_ENTRIES);
 second_base = alloc_boot_pages(nr_second, 1);
 second = mfn_to_virt(second_base);
 for ( i = 0; i < nr_second; i++ )
-- 
2.6.2


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

99 matches

Mail list logo