[Xen-devel] [linux-mingo-tip-master test] 66922: regressions - FAIL

[osstest service owner]

flight 66922 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/66922/

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 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-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3  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-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a

version targeted for testing:
 linux3a02f35dee2867eca8966d01848a3f523260f675
baseline version:
 linux

[Xen-devel] [xen-unstable test] 66879: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 10 guest-startfail like 66415
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66415
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 66415
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66415

Tests which did not succeed, but are not blocking:
 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-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-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-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-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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-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-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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass

version targeted for testing:
 xen  bf925a9f1254391749f569c1b8fc606036340488
baseline version:
 xen  18fcef8d62b28766e7b373a71d54bcf7578cea23

Last test of basis66415  2015-12-16 04:50:52 Z7 days
Failing since 66454  2015-12-17 07:52:08 Z5 days5 attempts
Testing same since66879  2015-12-21 21:25:56 Z1 days1 attempts


People who touched revisions under test:
  Alex Xu 
  Andrew Cooper 
  Boris Ostrovsky 
  Daniel De Graaf 
  David Vrabel 
  Doug Goldstein 
  Huaitong Han 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Malcolm Crossley 
  Razvan Cojocaru 
  Shuai Ruan 
  Stefano Stabellini 
  Yu Zhang 

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-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  

Re: [Xen-devel] [PATCH v3 0/2] VT-d flush issue

[Tian, Kevin]

> From: Xu, Quan
> Sent: Tuesday, December 22, 2015 6:26 PM
> 
> > On 22.12.2015 at 5:09pm,  wrote:
> > >>> On 22.12.15 at 09:43,  wrote:
> > > Let's finish our discussion. I accept your idea. But I need to
> > > separate it into 3 patch set (It is complicated for me, sometime it makes 
> > > me
> > crash.):
> > >Patch set 1:  Device-TLB/iotlb flush error. (send out this week)
> > >Patch set 2:  context flush error. (need 2 ~ 3 weeks)
> > >Patch set 3:  iec flush error. (need 3 ~ 4 weeks)
> > >
> > > If it is acceptable, we can discuss in detail one by one..
> >
> > Splitting up is of course acceptable.
> 
> Jan,
>Just update the combination,
> 
>Patch set 1:  Device-TLB flush error. (send out this week)
>Patch set 2:  context/iotlb flush error. (need 2 ~ 3 weeks)
>Patch set 3:  iec flush error. (need 3 ~ 4 weeks)
> 
> -Quan

Sorry being late to this discussion. Thanks Jan/Andrew's comments
for overall gap in VT-d error handling. Intel is definitely committed 
to continue improve current code quality, but let's do things one-by-one.

Above is a good split. Let's start from there.

Thanks
Kevin

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

Re: [Xen-devel] [PATCH] x86/VPMU: Check more carefully which bits are allowed to be written to MSRs

[Tian, Kevin]

> From: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Sent: Wednesday, December 23, 2015 12:25 AM
> 
> Current Intel VPMU emulation needs to perform more checks when writing
> PMU MSRs on guest's behalf:
> * MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
> * MSR_CORE_PERF_FIXED_CTR_CTRL has more reserved bits in PMU version 2
> * MSR_CORE_PERF_GLOBAL_OVF_CTRL's bit 61 is allowed on versions greater
> * than 2.
> 
> We can also use precomputed mask in core2_vpmu_do_interrupt().
> 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Tian, Kevin
> Sent: Wednesday, December 23, 2015 1:17 PM
> To: Wu, Feng ; Dario Faggioli ;
> xen-devel@lists.xen.org
> Cc: Keir Fraser ; George Dunlap ;
> Andrew Cooper ; Jan Beulich
> 
> Subject: RE: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic
> handling
> 
> > From: Wu, Feng
> > Sent: Wednesday, December 23, 2015 10:29 AM
> > >
> > > > +}
> > > > +
> > > > +static void vmx_pi_state_to_normal(struct vcpu *v)
> > > > +{
> > > >
> > > I'm still a bit puzzled about the name... But it's better than in the
> > > previous round, and I can't suggest a solution that I would like myself
> > > better... so I'm fine with this one.
> >
> > Yeah, I also didn't find a better name, I will continue to think about it:)
> >
> 
> I guess what you say 'normal' you actually mean resuming to
> non-root mode to get posted-interrupt benefit, i.e. direct delivery
> of external interrupt w/o VMM intervention.

Exactly.

> 
> Then what about vmx_pi_do_resume?

Sounds great ! :)

Thanks,
Feng

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

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Tian, Kevin]

> From: Wu, Feng
> Sent: Wednesday, December 23, 2015 10:29 AM
> >
> > > +}
> > > +
> > > +static void vmx_pi_state_to_normal(struct vcpu *v)
> > > +{
> > >
> > I'm still a bit puzzled about the name... But it's better than in the
> > previous round, and I can't suggest a solution that I would like myself
> > better... so I'm fine with this one.
> 
> Yeah, I also didn't find a better name, I will continue to think about it:)
> 

I guess what you say 'normal' you actually mean resuming to 
non-root mode to get posted-interrupt benefit, i.e. direct delivery
of external interrupt w/o VMM intervention.

Then what about vmx_pi_do_resume?

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 63732

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pvh-amd   9 debian-install  fail pass in 66698
 test-amd64-i386-xl-raw   18 guest-start/debian.repeat   fail pass in 66698

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 63732
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 66698 like 63676
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail in 66698 like 63732
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail in 66698 like 63732
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 63676
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 63732
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 63732
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 63732
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 63732

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start   fail in 66698 never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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  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-amd64-i386-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 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-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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-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-vhd   9 debian-di-installfail   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:
 linux60917545df1ffc7f918550512dc4a14758f74784
baseline version:
 linuxb12403044336e7d567f309eb443aa9acf76380af

Last test of basis63732  2015-11-06 18:01:35 Z   46 days
Testing same since66410  2015-12-16 01:55:28 Z7 days6 attempts


People who touched revisions under test:
  Aaro Koskinen 
  Aaron Conole 
  Alex Deucher 
  Alex Williamson 
  Alexander Couzens 
  Alexander Drozdov 
  Alexander Duyck 
  Alexandre Belloni 
  Andrew Morton 
  Andrey Vagin 
  Ani Sinha 
  Ben Hutchings 
  Ben Skeggs 
  Benjamin Tissoires 
  Bin Liu 
  Bjorn Helgaas 
  Bjørn Mork 
  Carol L Soto 
  Cathy Avery 
  Charles Keepax 
  Chris Mason 
  Cong Wang 
  Dan Carpenter 
  Daniel Borkmann 
  Dann Frazier 
  Dave Kleikamp 
  David Howells 
  David S. Miller 
  Dmitry Torokhov 
  Dmitry Vyukov 
  Doron Tsur 
  Doug Ledford 
  Dāvis Mosāns 
  Emmanuel Grumbach 
  Eric Dumazet 
  Eric Northup 
  Eric Whitney 
  Eryu Guan 
  Felipe Ba

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

Hi Jan,

Kevin and Dario gave some comments about this patch. I would like to
know whether you have any comments about this patch, it is highly
appreciated if you can give your opinions, which is very important for
it to get merged as soon as possible. Thank you!

Thanks,
Feng

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, December 23, 2015 10:21 AM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Tian, Kevin ; Keir Fraser ; George
> Dunlap ; Andrew Cooper
> ; Jan Beulich 
> Subject: Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic
> handling
> 
> Here I am,
> 
> On Thu, 2015-12-03 at 16:35 +0800, Feng Wu wrote:
> > This is the core logic handling for VT-d posted-interrupts. Basically
> > it
> > deals with how and when to update posted-interrupts during the
> > following
> > scenarios:
> > - vCPU is preempted
> > - vCPU is slept
> > - vCPU is blocked
> >
> > [..]
> >
> Thanks for changing the changelog, making it look like much more an
> high level description of what happens and why.
> 
> > v10:
> > - Check iommu_intpost first
> > - Remove pointless checking of has_hvm_container_vcpu(v)
> > - Rename 'vmx_pi_state_change' to 'vmx_pi_state_to_normal'
> > - Since vcpu_unblock() doesn't acquire 'pi_blocked_vcpu_lock', we
> >   don't need use another list to save the vCPUs with 'ON' set, just
> >   directly call vcpu_unblock(v).
> >
> This were all my comments to v9 and, I've verified in the patch, they
> actually have been all addressed... Thanks for this.
> 
> This patch looks fine to me now. There are a few minor issues that I'll
> raise inline, but in general, I think this is a good design, and the
> patch does it job fine at implementing it.
> 
> Here they are the detailed comments.
> 
> First of all, trying to apply it, I got:
> 
> :105: trailing whitespace.
> void arch_vcpu_block(struct vcpu *v)
> :106: trailing whitespace.
> {
> :107: trailing whitespace.
> if ( v->arch.vcpu_block )
> :108: trailing whitespace.
> v->arch.vcpu_block(v);
> :109: trailing whitespace.
> }
> 
> It may not be accurate, though (i.e., it may be due to what I used for
> applying the patches), so, please, double check.
> 
> And there are also a couple of long lines, which you should split.
> 
> > +void vmx_vcpu_block(struct vcpu *v)
> > +{
> > +unsigned long flags;
> > +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> > +
> > +if ( !has_arch_pdevs(v->domain) )
> > +return;
> > +
> > +ASSERT(v->arch.hvm_vmx.pi_block_cpu == NR_CPUS);
> > +
> > +/*
> > + * The vCPU is blocking, we need to add it to one of the per
> > pCPU lists.
> > + * We save v->processor to v->arch.hvm_vmx.pi_block_cpu and use
> > it for
> > + * the per-CPU list, we also save it to posted-interrupt
> > descriptor and
> > + * make it as the destination of the wake-up notification event.
> > + */
> > +v->arch.hvm_vmx.pi_block_cpu = v->processor;
> > +
> > +spin_lock_irqsave(&per_cpu(pi_blocked_vcpu_lock,
> > +  v->arch.hvm_vmx.pi_block_cpu), flags);
> > +list_add_tail(&v->arch.hvm_vmx.pi_blocked_vcpu_list,
> > +  &per_cpu(pi_blocked_vcpu, v-
> > >arch.hvm_vmx.pi_block_cpu));
> > +spin_unlock_irqrestore(&per_cpu(pi_blocked_vcpu_lock,
> > +   v->arch.hvm_vmx.pi_block_cpu), flags);
> > +
> > +ASSERT(!pi_test_sn(pi_desc));
> > +
> > +/*
> > + * We don't need to set the 'NDST' field, since it should point
> > to
> > + * the same pCPU as v->processor.
> > + */
> > +
> So, maybe we can ASSERT() that?
> 
> > +write_atomic(&pi_desc->nv, pi_wakeup_vector);
> > +}
> 
> > +static void vmx_pi_switch_from(struct vcpu *v)
> > +{
> > +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> > +
> > +if ( !iommu_intpost || !has_arch_pdevs(v->domain) ||
> > + test_bit(_VPF_blocked, &v->pause_flags) )
> > +return;
> > +
> > +/*
> > + * The vCPU has been preempted or went to sleep. We don't need
> > to send
> > + * notification event to a non-running vcpu, the interrupt
> > information
> > + * will be delivered to it before VM-ENTRY when the vcpu is
> > scheduled
> > + * to run next time.
> > + */
> > +pi_set_sn(pi_desc);
> > +}
> > +
> > +static void vmx_pi_switch_to(struct vcpu *v)
> > +{
> > +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> > +
> > +if ( !iommu_intpost || !has_arch_pdevs(v->domain) )
> > +return;
> > +
> > +if ( x2apic_enabled )
> > +write_atomic(&pi_desc->ndst, cpu_physical_id(v->processor));
> > +else
> > +write_atomic(&pi_desc->ndst,
> > + MASK_INSR(cpu_physical_id(v->processor),
> > + PI_xAPIC_NDST_MASK));
> > +
> > +pi_clear_sn(pi_desc);
> >
> No comment matching the one above (for pi_set_sn(), in
> vmx_pi_switch_from())? I don't feel too strong about this, but it would
> be nice to h

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, December 23, 2015 10:21 AM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Tian, Kevin ; Keir Fraser ; George
> Dunlap ; Andrew Cooper
> ; Jan Beulich 
> Subject: Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic
> handling
> 
> Here I am,

Nice to having you reviewing the code :)

> 
> On Thu, 2015-12-03 at 16:35 +0800, Feng Wu wrote:
> > This is the core logic handling for VT-d posted-interrupts. Basically
> > it
> > deals with how and when to update posted-interrupts during the
> > following
> > scenarios:
> > - vCPU is preempted
> > - vCPU is slept
> > - vCPU is blocked
> >
> > [..]
> >
> Thanks for changing the changelog, making it look like much more an
> high level description of what happens and why.
> 
> > v10:
> > - Check iommu_intpost first
> > - Remove pointless checking of has_hvm_container_vcpu(v)
> > - Rename 'vmx_pi_state_change' to 'vmx_pi_state_to_normal'
> > - Since vcpu_unblock() doesn't acquire 'pi_blocked_vcpu_lock', we
> >   don't need use another list to save the vCPUs with 'ON' set, just
> >   directly call vcpu_unblock(v).
> >
> This were all my comments to v9 and, I've verified in the patch, they
> actually have been all addressed... Thanks for this.
> 
> This patch looks fine to me now. There are a few minor issues that I'll
> raise inline, but in general, I think this is a good design, and the
> patch does it job fine at implementing it.
> 
> Here they are the detailed comments.
> 
> First of all, trying to apply it, I got:
> 
> :105: trailing whitespace.
> void arch_vcpu_block(struct vcpu *v)
> :106: trailing whitespace.
> {
> :107: trailing whitespace.
> if ( v->arch.vcpu_block )
> :108: trailing whitespace.
> v->arch.vcpu_block(v);
> :109: trailing whitespace.
> }
> 
> It may not be accurate, though (i.e., it may be due to what I used for
> applying the patches), so, please, double check.

Sure, will double check it.

> 
> And there are also a couple of long lines, which you should split.
> 
> > +void vmx_vcpu_block(struct vcpu *v)
> > +{
> > +unsigned long flags;
> > +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> > +
> > +if ( !has_arch_pdevs(v->domain) )
> > +return;
> > +
> > +ASSERT(v->arch.hvm_vmx.pi_block_cpu == NR_CPUS);
> > +
> > +/*
> > + * The vCPU is blocking, we need to add it to one of the per
> > pCPU lists.
> > + * We save v->processor to v->arch.hvm_vmx.pi_block_cpu and use
> > it for
> > + * the per-CPU list, we also save it to posted-interrupt
> > descriptor and
> > + * make it as the destination of the wake-up notification event.
> > + */
> > +v->arch.hvm_vmx.pi_block_cpu = v->processor;
> > +
> > +spin_lock_irqsave(&per_cpu(pi_blocked_vcpu_lock,
> > +  v->arch.hvm_vmx.pi_block_cpu), flags);
> > +list_add_tail(&v->arch.hvm_vmx.pi_blocked_vcpu_list,
> > +  &per_cpu(pi_blocked_vcpu, v-
> > >arch.hvm_vmx.pi_block_cpu));
> > +spin_unlock_irqrestore(&per_cpu(pi_blocked_vcpu_lock,
> > +   v->arch.hvm_vmx.pi_block_cpu), flags);
> > +
> > +ASSERT(!pi_test_sn(pi_desc));
> > +
> > +/*
> > + * We don't need to set the 'NDST' field, since it should point
> > to
> > + * the same pCPU as v->processor.
> > + */
> > +
> So, maybe we can ASSERT() that?

Yes, I think ASSERT() is preferred here.

> 
> > +write_atomic(&pi_desc->nv, pi_wakeup_vector);
> > +}
> 
> > +static void vmx_pi_switch_from(struct vcpu *v)
> > +{
> > +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> > +
> > +if ( !iommu_intpost || !has_arch_pdevs(v->domain) ||
> > + test_bit(_VPF_blocked, &v->pause_flags) )
> > +return;
> > +
> > +/*
> > + * The vCPU has been preempted or went to sleep. We don't need
> > to send
> > + * notification event to a non-running vcpu, the interrupt
> > information
> > + * will be delivered to it before VM-ENTRY when the vcpu is
> > scheduled
> > + * to run next time.
> > + */
> > +pi_set_sn(pi_desc);
> > +}
> > +
> > +static void vmx_pi_switch_to(struct vcpu *v)
> > +{
> > +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> > +
> > +if ( !iommu_intpost || !has_arch_pdevs(v->domain) )
> > +return;
> > +
> > +if ( x2apic_enabled )
> > +write_atomic(&pi_desc->ndst, cpu_physical_id(v->processor));
> > +else
> > +write_atomic(&pi_desc->ndst,
> > + MASK_INSR(cpu_physical_id(v->processor),
> > + PI_xAPIC_NDST_MASK));
> > +
> > +pi_clear_sn(pi_desc);
> >
> No comment matching the one above (for pi_set_sn(), in
> vmx_pi_switch_from())? I don't feel too strong about this, but it would
> be nice to have both (or none, but I'd prefer both! :-D).

I will add some comments here.

> 
> > +}
> > +
> > +static void vmx_pi_state_to_normal(struct vcpu *v)
> > +{
> >

[Xen-devel] [PATCH V12 4/5] xl: add pvusb commands

[Chunyan Liu]

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
 docs/man/xl.pod.1 |  41 
 tools/libxl/xl.h  |   5 +
 tools/libxl/xl_cmdimpl.c  | 243 ++
 tools/libxl/xl_cmdtable.c |  25 +
 4 files changed, 314 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..746f49f 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,47 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I I[] [I] 
[I]
+
+Create a new USB controller for the specified domain.
+B is the usb controller type.  Currently only 'pv' and 'auto'
+are supported.
+B is the usb controller version.  Possible values include
+1 (USB1.1) and 2 (USB2.0).
+B is the total ports of the usb controller. The maximum
+number is 31.
+By default, it will create a USB2.0 controller with 8 ports.
+
+=item B I I
+
+Destroy a USB controller from the specified domain.
+B is devid of the USB controller.
+
+=item B I I I 
[I [I]]
+
+Hot-plug a new pass-through USB device to the specified domain.
+B and B are the bus and device number of the physical
+USB device to pass through.
+B B is the USB controller:port to hotplug the
+USB device to. By default, it will find the first available controller:port
+and use it; if there is no controller, a new controller will be created.
+
+=item B I I I
+
+Hot-unplug a previously assigned USB device from a domain.
+B and B is USB controller:port in guest where 
the
+USB device is attached to.
+
+=item B I
+
+List pass-through usb devices for a domain.
+
+=back
+
 =head1 TMEM
 
 =over 4
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index bdab125..309627a 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -92,6 +92,11 @@ int main_blockdetach(int argc, char **argv);
 int main_vtpmattach(int argc, char **argv);
 int main_vtpmlist(int argc, char **argv);
 int main_vtpmdetach(int argc, char **argv);
+int main_usbctrl_attach(int argc, char **argv);
+int main_usbctrl_detach(int argc, char **argv);
+int main_usbdev_attach(int argc, char **argv);
+int main_usbdev_detach(int argc, char **argv);
+int main_usblist(int argc, char **argv);
 int main_uptime(int argc, char **argv);
 int main_claims(int argc, char **argv);
 int main_tmem_list(int argc, char **argv);
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f9933cb..b84ec98d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -1255,6 +1255,58 @@ static void parse_vnuma_config(const XLU_Config *config,
 free(vcpu_parsed);
 }
 
+/* Parses usbctrl data and adds info into usbctrl
+ * Returns 1 if the input token does not match one of the keys
+ * or parsed values are not correct. Successful parse returns 0 */
+static int parse_usbctrl_config(libxl_device_usbctrl *usbctrl, char *token)
+{
+char *oparg;
+
+if (MATCH_OPTION("type", token, oparg)) {
+if (libxl_usbctrl_type_from_string(oparg, &usbctrl->type)) {
+fprintf(stderr, "Invalid usb controller type '%s'\n", oparg);
+return 1;
+}
+} else if (MATCH_OPTION("version", token, oparg)) {
+usbctrl->version = atoi(oparg);
+} else if (MATCH_OPTION("ports", token, oparg)) {
+usbctrl->ports = atoi(oparg);
+} else {
+fprintf(stderr, "Unknown string `%s' in usbctrl spec\n", token);
+return 1;
+}
+
+return 0;
+}
+
+/* Parses usbdev data and adds info into usbdev
+ * Returns 1 if the input token does not match one of the keys
+ * or parsed values are not correct. Successful parse returns 0 */
+static int parse_usbdev_config(libxl_device_usbdev *usbdev, char *token)
+{
+char *oparg;
+
+if (MATCH_OPTION("type", token, oparg)) {
+if (libxl_usbdev_type_from_string(oparg, &usbdev->type)) {
+fprintf(stderr, "Invalid usb device type: %s\n", optarg);
+return 1;
+}
+} else if (MATCH_OPTION("hostbus", token, oparg)) {
+usbdev->u.hostdev.hostbus = strtoul(oparg, NULL, 0);
+} else if (MATCH_OPTION("hostaddr", token, oparg)) {
+usbdev->u.hostdev.hostaddr = strtoul(oparg, NULL, 0);
+} else if (MATCH_OPTION("controller", token, oparg)) {
+usbde

[Xen-devel] [PATCH V12 5/5] domcreate: support pvusb in configuration file

[Chunyan Liu]

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
 docs/man/xl.cfg.pod.5| 84 
 tools/libxl/libxl_create.c   | 73 --
 tools/libxl/libxl_device.c   |  4 +++
 tools/libxl/libxl_internal.h |  8 +
 tools/libxl/xl_cmdimpl.c | 55 -
 5 files changed, 220 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 8899f75..99ef9ca 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item B
+
+Specifies the USB controllers created for this guest. Each
+B has the form C where:
+
+=over 4
+
+=item B
+
+Possible Bs are:
+
+=over 4
+
+=item B
+
+Specifies the usb controller type.  Currently only 'pv' and 'auto'
+are supported.
+
+=item B
+
+Specifies the usb controller version.  Possible values include
+1 (USB1.1) and 2 (USB2.0). Default is 2 (USB2.0).
+
+=item B
+
+Specifies the total ports of the usb controller. The maximum
+number is 31. Default is 8.
+
+USB controler ids start from 0.  In line with the USB spec, however,
+ports on a controller start from 1.
+
+E.g.
+usbctrl=["version=1,ports=4", "version=2,ports=8",]
+The first controller has:
+controller id = 0, and port 1,2,3,4.
+The second controller has:
+controller id = 1, and port 1,2,3,4,5,6,7,8.
+
+=back
+
+=back
+
+=item B
+
+Specifies the USB devices to be attached to the guest at boot. Each
+B has the form C where:
+
+=over 4
+
+=item B
+
+Possible Bs are:
+
+=over 4
+
+=item B
+
+Specifies USB device type. Currently only support 'hostdev'.
+
+=item B
+
+Specifies busnum of the USB device from the host perspective.
+
+=item B
+
+Specifies devnum of the USB device from the host perspective.
+
+=item B
+
+Specifies USB controller id, to which controller the USB device is attached.
+
+=item B
+
+Specifies USB port, to which port the USB device is attached. B
+is valid only when B is specified.
+
+=back
+
+If no controller is specified, an available controller:port combination
+will be used.  If there are no available controller:port options,
+a new controller will be created.
+
+=back
+
 =item B
 
 Specifies the host PCI devices to passthrough to this guest. Each 
B
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 261816a..7c87c34 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -733,6 +733,10 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *aodevs,
 
 static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
int ret);
+static void domcreate_attach_usbctrls(libxl__egc *egc,
+  libxl__multidev *multidev, int ret);
+static void domcreate_attach_usbdevs(libxl__egc *egc, libxl__multidev 
*multidev,
+ int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
  int ret);
 static void domcreate_attach_dtdev(libxl__egc *egc,
@@ -1398,13 +1402,13 @@ static void domcreate_attach_vtpms(libxl__egc *egc,
if (d_config->num_vtpms > 0) {
/* Attach vtpms */
libxl__multidev_begin(ao, &dcs->multidev);
-   dcs->multidev.callback = domcreate_attach_pci;
+   dcs->multidev.callback = domcreate_attach_usbctrls;
libxl__add_vtpms(egc, ao, domid, d_config, &dcs->multidev);
libxl__multidev_prepared(egc, &dcs->multidev, 0);
return;
}
 
-   domcreate_attach_pci(egc, multidev, 0);
+   domcreate_attach_usbctrls(egc, multidev, 0);
return;
 
 error_out:
@@ -1412,6 +1416,69 @@ error_out:
domcreate_complete(egc, dcs, ret);
 }
 
+static void domcreate_attach_usbctrls(libxl__egc *egc,
+  libxl__multidev *multidev, int ret)
+{
+libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
+STATE_AO_GC(dcs->ao);
+int domid = dcs->guest_domid;
+
+libxl_domain_config *const d_config = dcs->guest_config;
+
+if (ret) {
+LOG(ERROR, "unable to add vtpm devices");
+goto error_out;
+}
+
+if (d_config->num_usbctrls > 0) {
+/* Attach usbctrls */
+libxl__multidev_begin(ao, &dcs->multidev);
+dcs->multidev.callback = domcreate_attach_usbdevs;
+libxl__add_usbctrls(egc, ao, domid, d_config, &dcs->multidev);
+libxl__multidev_prepared(egc, &dcs

[Xen-devel] [PATCH V12 1/5] libxl: export some functions for pvusb use

[Chunyan Liu]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 00d9ec4..43d5709 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2036,7 +2036,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -2055,8 +2055,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4c01a82..9e94835 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1176,6 +1176,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

[Xen-devel] [PATCH V12 0/5] xen pvusb toolstack work

[Chunyan Liu]

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V11:
* remov unnecessary check in patch 2/5

V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html

V10:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html

V9:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['1.6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['1.6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usb-ctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usb-attach domain 1.6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status of the domain by usb-list.
e.g.
xl usb-list domain
It will list USB controllers and USB devices under each controller.

You could detach a USB device with usb-detach command.
e.g.
xl usb-detach domain 1.6

You can also remove the whole USB controller by usb-ctrl-detach
command.
e.g.
xl usb-ctrl-detach domain 0
It will remove the USB controller with index 0 and a

[Xen-devel] [PATCH V12 3/5] libxl: add pvusb API

[Chunyan Liu]

Add pvusb APIs, including:
 - attach/detach (create/destroy) virtual usb controller.
 - attach/detach usb device
 - list usb controller and usb devices
 - some other helper functions

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Signed-off-by: George Dunlap 
Reviewed-by: George Dunlap 
---
 tools/libxl/Makefile |2 +-
 tools/libxl/libxl.c  |   34 +-
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |   13 +-
 tools/libxl/libxl_internal.h |   22 +-
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1548 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1766 insertions(+), 13 deletions(-)
 create mode 100644 tools/libxl/libxl_pvusb.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 6ff5bee..a36145a 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -103,7 +103,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 43d5709..920c135 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3204,7 +3204,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4172,8 +4172,10 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4193,13 +4195,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4223,6 +4231,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
+/* usbctrl */
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
+
 /* channel/console hotunplug is not implemented. There are 2 possibilities:
  * 1. add support for secondary consoles to xenconsoled
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
@@ -4236,6 +4248,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * libxl_device_disk_add
  * libxl_device_nic_add
  * libxl_device_vtpm_add
+ * libxl_device_usbctrl_add
+ * libxl_device_usbdev_add
  */
 
 #define DEFINE_DEVICE_ADD(type) \
@@ -4267,6 +4281,12 @@ DEFINE_DEVICE_ADD(nic)
 /* vtpm */
 DEFINE_DEVICE_ADD(vtpm)
 
+/* usbctrl */
+DEFINE_DEVICE_ADD(usbctrl)
+
+/* usb */
+DEFINE_DEVICE_ADD(usbdev)
+
 #undef DEFINE_DEVICE_ADD
 
 
/**/
@@ -4432,7 +4452,7 @@ static int remove_device(libxl__egc *egc, libxl__ao *ao,
 aodev->dev = dev;
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->callback = device_complete;
- 

[Xen-devel] [PATCH V12 2/5] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
---
Changes:
  * remove unnecessary null pointer check after libxl__alloc and
libxl__realloc

 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 74 
 2 files changed, 78 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9e94835..d1eb18f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4039,6 +4039,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index e42422a..e64f301 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,80 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), &stab)) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Dario Faggioli]

Here I am,

On Thu, 2015-12-03 at 16:35 +0800, Feng Wu wrote:
> This is the core logic handling for VT-d posted-interrupts. Basically
> it
> deals with how and when to update posted-interrupts during the
> following
> scenarios:
> - vCPU is preempted
> - vCPU is slept
> - vCPU is blocked
> 
> [..]
>
Thanks for changing the changelog, making it look like much more an
high level description of what happens and why.

> v10:
> - Check iommu_intpost first
> - Remove pointless checking of has_hvm_container_vcpu(v)
> - Rename 'vmx_pi_state_change' to 'vmx_pi_state_to_normal'
> - Since vcpu_unblock() doesn't acquire 'pi_blocked_vcpu_lock', we
>   don't need use another list to save the vCPUs with 'ON' set, just
>   directly call vcpu_unblock(v).
> 
This were all my comments to v9 and, I've verified in the patch, they
actually have been all addressed... Thanks for this.

This patch looks fine to me now. There are a few minor issues that I'll
raise inline, but in general, I think this is a good design, and the
patch does it job fine at implementing it.

Here they are the detailed comments.

First of all, trying to apply it, I got:

:105: trailing whitespace.
void arch_vcpu_block(struct vcpu *v)
:106: trailing whitespace.
{
:107: trailing whitespace.
if ( v->arch.vcpu_block )
:108: trailing whitespace.
v->arch.vcpu_block(v);
:109: trailing whitespace.
}

It may not be accurate, though (i.e., it may be due to what I used for
applying the patches), so, please, double check.

And there are also a couple of long lines, which you should split.

> +void vmx_vcpu_block(struct vcpu *v)
> +{
> +unsigned long flags;
> +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> +if ( !has_arch_pdevs(v->domain) )
> +return;
> +
> +ASSERT(v->arch.hvm_vmx.pi_block_cpu == NR_CPUS);
> +
> +/*
> + * The vCPU is blocking, we need to add it to one of the per
> pCPU lists.
> + * We save v->processor to v->arch.hvm_vmx.pi_block_cpu and use
> it for
> + * the per-CPU list, we also save it to posted-interrupt
> descriptor and
> + * make it as the destination of the wake-up notification event.
> + */
> +v->arch.hvm_vmx.pi_block_cpu = v->processor;
> +
> +spin_lock_irqsave(&per_cpu(pi_blocked_vcpu_lock,
> +  v->arch.hvm_vmx.pi_block_cpu), flags);
> +list_add_tail(&v->arch.hvm_vmx.pi_blocked_vcpu_list,
> +  &per_cpu(pi_blocked_vcpu, v-
> >arch.hvm_vmx.pi_block_cpu));
> +spin_unlock_irqrestore(&per_cpu(pi_blocked_vcpu_lock,
> +   v->arch.hvm_vmx.pi_block_cpu), flags);
> +
> +ASSERT(!pi_test_sn(pi_desc));
> +
> +/*
> + * We don't need to set the 'NDST' field, since it should point
> to
> + * the same pCPU as v->processor.
> + */
> +
So, maybe we can ASSERT() that?

> +write_atomic(&pi_desc->nv, pi_wakeup_vector);
> +}

> +static void vmx_pi_switch_from(struct vcpu *v)
> +{
> +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> +if ( !iommu_intpost || !has_arch_pdevs(v->domain) ||
> + test_bit(_VPF_blocked, &v->pause_flags) )
> +return;
> +
> +/*
> + * The vCPU has been preempted or went to sleep. We don't need
> to send
> + * notification event to a non-running vcpu, the interrupt
> information
> + * will be delivered to it before VM-ENTRY when the vcpu is
> scheduled
> + * to run next time.
> + */
> +pi_set_sn(pi_desc);
> +}
> +
> +static void vmx_pi_switch_to(struct vcpu *v)
> +{
> +struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +
> +if ( !iommu_intpost || !has_arch_pdevs(v->domain) )
> +return;
> +
> +if ( x2apic_enabled )
> +write_atomic(&pi_desc->ndst, cpu_physical_id(v->processor));
> +else
> +write_atomic(&pi_desc->ndst,
> + MASK_INSR(cpu_physical_id(v->processor),
> + PI_xAPIC_NDST_MASK));
> +
> +pi_clear_sn(pi_desc);
>
No comment matching the one above (for pi_set_sn(), in
vmx_pi_switch_from())? I don't feel too strong about this, but it would
be nice to have both (or none, but I'd prefer both! :-D).

> +}
> +
> +static void vmx_pi_state_to_normal(struct vcpu *v)
> +{
>
I'm still a bit puzzled about the name... But it's better than in the
previous round, and I can't suggest a solution that I would like myself
better... so I'm fine with this one.

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



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-prev  5 xen-build fail REGR. vs. 66458
 build-i386-prev   5 xen-build fail REGR. vs. 66458
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 66458
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 66458
 build-armhf   5 xen-buildfail in 66718 REGR. vs. 66458

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 66583 pass 
in 66864
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 66583 pass in 
66864
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 66718 
pass in 66864
 test-armhf-armhf-xl-vhd   6 xen-bootfail pass in 66583
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
66718
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 66718

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 66718 
like 66418
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 66718 like 66458
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeatfail  like 66458
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66458

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)  blocked in 66718 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)blocked in 66718 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked in 66718 n/a
 test-armhf-armhf-xl   1 build-check(1)blocked in 66718 n/a
 test-armhf-armhf-libvirt  1 build-check(1)blocked in 66718 n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)blocked in 66718 n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)  blocked in 66718 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)blocked in 66718 n/a
 build-armhf-libvirt   1 build-check(1)blocked in 66718 n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)blocked in 66718 n/a
 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-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   9 debian-di-install fail in 66583 never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 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-i386-libvirt  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 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-libvirt 11 guest-start  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-amd64-xl-qemut-win7-amd64 16 guest-stop 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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass

version targeted for testing:
 xen  fd4db045339863c901e887fe35fe958ce766351e
baseline version:
 xen  d0b73c9bf21f9199401a36eeda7ba0a4412aad6d

Last test of basis66458  2015-12-17 09:42:47 Z5 days
Failing since 66520  2015-12-18 10:37:08 Z4 days4 attempts
Testing same since66583  2015-12-1

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543

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

Last test of basis65543  2015-12-08 08:45:15 Z   14 days
Failing since 65593  2015-12-08 23:44:51 Z   14 days   11 attempts
Testing same since66870  2015-12-21 18:11:07 Z1 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

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 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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 2441 lines long.)

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

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

[osstest service owner]

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

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. 66426
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 66426

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  3 host-install(3) broken in 6 pass in 66856
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 6 
pass in 66856
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
6 pass in 66856
 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail pass in 6
 test-armhf-armhf-xl-credit2   5 xen-install fail pass in 6

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 6 like 66426
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail in 6 like 66426
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 66426
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66426
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66426

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2  12 migrate-support-check fail in 6 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 6 never 
pass
 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-raw  9 debian-di-installfail   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-amd64-i386-libvirt  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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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  10 guest-start  fail   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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass

version targeted for testing:
 xen  172797ecdfd4e2cfece6a401b7b000799534c84e
baseline version:
 xen  4c11414775a28ccd29a33c62cd89e202feb631d7

Last test of basis66426  2015-12-16 11:30:16 Z6 days
Failing since 66473  2015-12-17 18:53:22 Z5 days4 attempts
Testing same since66553  2015-12-18 21:22:14 Z4 days3 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 

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

Re: [Xen-devel] Sub page Grant Table mappings

[Mike Belopuhov]

> On Tue, Dec 22, 2015 at 21:59 +0100, Mike Belopuhov wrote:
> > Hi,
> > 
> > I'm trying to get grant table sub page mappings working on Xen 4.5.
> > I know there have been some changes in the trunk regarding moving src/
> > dst checks closer together, but I can't test this easily atm.  Please
> > bear with me for a moment.  Or tell me that it might have been broken
> > previously.
> > 
> > What I'm trying to do is to map in a 2k cluster from the networking
> > stack (we call it an mbuf cluster, you might call it skb something)
> > onto the Netfront Rx ring.  2 clusters fit one page.  Therefore for
> > one frame address which is a (PA >> 12) I might have 2 entries one
> > after the other, both with sub_page.length = 2048 but one with a
> > sub_page.page_off = 2048 and the other with a 0 offset.  Both come
> > with (GTF_permit_access | GTF_sub_page) flags.
> > 
> > When I do that, Xen stops liking me and says:
> > 
> > (XEN) grant_table.c:2162:d0v1 copy dest out of bounds: 0 < 2048 || 90 > 2048
> > (XEN) grant_table.c:2162:d0v1 copy dest out of bounds: 0 < 2048 || 119 > 
> > 2048
> > (XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 70 > 2048
> > (XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 119 > 
> > 2048
> > (XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 119 > 
> > 2048
> > ...
> > 
> > The relevant code does this:
> > 
> > if ( dest_is_gref )
> > {
> > unsigned dest_off, dest_len;
> > rc = __acquire_grant_for_copy(dd, op->dest.u.ref,
> >   current->domain->domain_id, 0,
> >   &d_frame, &d_pg, &dest_off, 
> > &dest_len, 1);
> > if ( rc != GNTST_okay )
> > goto error_out;
> > have_d_grant = 1;
> > if ( op->dest.offset < dest_off ||
> >  op->len > dest_len )
> > PIN_FAIL(error_out, GNTST_general_error,
> >  "copy dest out of bounds: %d < %d || %d > %d\n",
> >  op->dest.offset, dest_off,
> >  op->len, dest_len);
> > }
> > 
> > I fail to understand what am I doing wrong in this case.  Any clues
> > will be greatly appreciated.
> > 
> > 4k clusters mapped in as full_page mappings work as expected.
> > 
> > Cheers,
> > Mike


Hi Andrew!

I'm sorry I have to fake up this reply.  I'm not subscribe to the list
and either greylisting services or what not prevents me from receiving
your mail verbatim.

Thanks for your prompt response!

> I presume you are on x86 here.
>

Ack.

> Architecturally, a 4k page is the minimum granularity which permissions
> can be applied to.  It is not possible to make a 2k block accessible,
> but an adjacent 2k block inaccessible.
>

Sure.

What I probably didn't realise is that this sub page mapping exists for
situations when one region of the page needs to be granted access to,
but not the whole page.  I'm clearly trying to grant different regions
of the same page twice.

I would have figured this quickly out if I was dealing with different
page protections, but in this case page protections are supposed to be
the same.

> As a result, grant mapping of a subpage grant is prohibited, but you are
> (or at least should be) able to grant copy it.
>
> Can you describe precisely which domains are doing what in your example?
>

Just a domU trying to configure its Netfront's Rx ring.

> ~Andrew

Thanks a lot for your comments!

Cheers,
Mike

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

Re: [Xen-devel] [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory

[Andrew Morton]

On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov  wrote:

> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
> 
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", 
> ATTR{state}="online"
> 
> to make this happen automatically. This is not a great solution for virtual
> machines where memory hotplug is being used to address high memory pressure
> situations as such onlining is slow and a userspace process doing this
> (udev) has a chance of being killed by the OOM killer as it will probably
> require to allocate some memory.
> 
> Introduce default policy for the newly added memory blocks in
> /sys/devices/system/memory/hotplug_autoonline file with two possible
> values: "offline" which preserves the current behavior and "online" which
> causes all newly added memory blocks to go online as soon as they're added.
> The default is "online" when MEMORY_HOTPLUG_AUTOONLINE kernel config option
> is selected.

I think the default should be "offline" so vendors can ship kernels
which have CONFIG_MEMORY_HOTPLUG_AUTOONLINE=y while being
back-compatible with previous kernels.

> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2537,6 +2537,8 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   shutdown the other cpus.  Instead use the REBOOT_VECTOR
>   irq.
>  
> + nomemhp_autoonline  Don't automatically online newly added memory.
> +

This wasn't mentioned in the changelog.  Why do we need a boot
parameter as well as the sysfs knob?

> +config MEMORY_HOTPLUG_AUTOONLINE
> + bool "Automatically online hot-added memory"
> + depends on MEMORY_HOTPLUG_SPARSE
> + help
> +   When memory is hot-added, it is not at ready-to-use state, a special

"When memory is hot-added it is not in a ready-to-use state.  A special"

> +   userspace action is required to online the newly added blocks. With
> +   this option enabled, the kernel will try to online all newly added
> +   memory automatically.
> +
>
> ...
>

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

Re: [Xen-devel] [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Andrew Cooper]

On 22/12/2015 21:26, Doug Goldstein wrote:
> diff --git a/INSTALL b/INSTALL
> index c51447b..3d2e86a 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -275,14 +275,10 @@ Building the python tools may fail unless certain 
> options are passed to
>  setup.py. Config.mk contains additional info how to use this variable.
>  PYTHON_PREFIX_ARG=
>  
> -The hypervisor may be build with XSM support, which can be changed with
> -the following variables.
> -XSM_ENABLE=y
> -
> -The hypervisor may be build with Flask support, which can be changed
> +he hypervisor may be build with XSM/Flask support, which can be changed

Missing a T.

The x86 bits appear to be entirely mechanical, so Acked-by: Andrew
Cooper 

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

[Xen-devel] [PATCH 2/2] xen: convert XSM_ENABLE to Kconfig

[Doug Goldstein]

Converts the existing XSM_ENABLE flag from Config.mk to CONFIG_XSM
within Kconfig. This also re-adds the dependency of CONFIG_FLASK on
CONFIG_XSM.

CC: Daniel De Graaf 
CC: Keir Fraser 
CC: Jan Beulich 
CC: Andrew Cooper 
Signed-off-by: Doug Goldstein 
---
 Config.mk|  3 ---
 INSTALL  |  8 ++--
 docs/misc/xsm-flask.txt  |  6 +++---
 xen/Rules.mk |  1 -
 xen/common/Kconfig   | 23 ++-
 xen/include/asm-x86/config.h |  4 
 xen/include/xen/sched.h  |  2 +-
 xen/include/xsm/dummy.h  | 10 +-
 xen/include/xsm/xsm.h|  6 +++---
 xen/xsm/Makefile |  6 ++
 10 files changed, 38 insertions(+), 31 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7e56b48..8e58c36 100644
--- a/Config.mk
+++ b/Config.mk
@@ -212,9 +212,6 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
 EMBEDDED_EXTRA_CFLAGS := -nopie -fno-stack-protector -fno-stack-protector-all
 EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
-# Enable XSM security module (by default, Flask).
-XSM_ENABLE ?= n
-
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
 # the internet.  The original download URL is preserved as a comment
diff --git a/INSTALL b/INSTALL
index c51447b..3d2e86a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -275,14 +275,10 @@ Building the python tools may fail unless certain options 
are passed to
 setup.py. Config.mk contains additional info how to use this variable.
 PYTHON_PREFIX_ARG=
 
-The hypervisor may be build with XSM support, which can be changed with
-the following variables.
-XSM_ENABLE=y
-
-The hypervisor may be build with Flask support, which can be changed
+he hypervisor may be build with XSM/Flask support, which can be changed
 by running:
 make -C xen menuconfig
-and enabling Flask in the 'Common Features' menu.
+and enabling XSM/Flask in the 'Common Features' menu.
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index f2f0fd4..fb2fe9f 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -172,9 +172,9 @@ Setting up FLASK
 
 
 Xen must be compiled with XSM and FLASK enabled; by default, the security
-framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE to
-"y" and running 'make -C xen menuconfig' and enabling FLASK inside 'Common
-Features'; this change requires a make clean and rebuild.
+framework is disabled. Running 'make -C xen menuconfig' and enabling XSM
+and FLASK inside 'Common Features'; this change requires a make clean and
+rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 489cfd1..bdd8ccf 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -52,7 +52,6 @@ CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
 CFLAGS += -pipe -g -D__XEN__ -include $(BASEDIR)/include/xen/config.h
 CFLAGS += '-D__OBJECT_FILE__="$@"'
 
-CFLAGS-$(XSM_ENABLE)+= -DXSM_ENABLE
 CFLAGS-$(verbose)   += -DVERBOSE
 CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3419816..dea01eb 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -10,7 +10,8 @@ config COMPAT
 
 config FLASK
bool "FLux Advanced Security Kernel support"
-   default n
+   default y
+   depends on XSM
---help---
  Enables the FLASK (FLux Advanced Security Kernel) support which
  provides a mandatory access control framework by which security
@@ -62,4 +63,24 @@ config KEXEC
 
  If unsure, say Y.
 
+# Allows "late" initialization of the hardware domain
+config LATE_HWDOM
+   bool
+   ---help---
+ Late hardware domain initialization
+
+# Enable/Disable XSM support
+config XSM
+   bool "Xen Security Modules support"
+   default n
+   select LATE_HWDOM if X86
+   ---help---
+ Enables the security framework known as Xen Security Modules which
+ allows administrators fine-grained control over a Xen domain and
+ its capabilities by defining permissible interactions between domains,
+ the hypervisor itself, and related resources such as memory and
+ devices.
+
+ If unsure, say N.
+
 endmenu
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index f25d92e..3305a75 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -52,10 +52,6 @@
 
 #define CONFIG_MULTIBOOT 1
 
-#ifdef XSM_ENABLE
-#define CONFIG_LATE_HWDOM 1
-#endif
-
 #define HZ 100
 
 #define OPT_CONSOLE_STR "vga"
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 6ea3cc7..e1428f7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -110,7 +110,7 @@ 

[Xen-devel] [PATCH 1/2] xen: convert FLASK_ENABLE to Kconfig

[Doug Goldstein]

Converts the Config.mk option of FLASK_ENABLE into a Kconfig option for
the hypervisor called CONFIG_FLASK. This commit knowingly breaks the
dependent relationship on XSM_ENABLE which is addressed when XSM_ENABLE
is converted to Kconfig.

CC: Daniel De Graaf 
Signed-off-by: Doug Goldstein 
---
 Config.mk|  1 -
 INSTALL  |  6 +-
 docs/misc/xsm-flask.txt  |  5 +++--
 xen/Rules.mk |  1 -
 xen/common/Kconfig   | 11 +++
 xen/include/Makefile |  2 +-
 xen/include/xen/config.h |  2 +-
 xen/include/xen/sched.h  |  2 +-
 xen/xsm/Makefile |  2 +-
 9 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/Config.mk b/Config.mk
index 7b2aa07..7e56b48 100644
--- a/Config.mk
+++ b/Config.mk
@@ -214,7 +214,6 @@ EMBEDDED_EXTRA_CFLAGS += -fno-exceptions
 
 # Enable XSM security module (by default, Flask).
 XSM_ENABLE ?= n
-FLASK_ENABLE ?= $(XSM_ENABLE)
 
 XEN_EXTFILES_URL ?= http://xenbits.xen.org/xen-extfiles
 # All the files at that location were downloaded from elsewhere on
diff --git a/INSTALL b/INSTALL
index b7e426c..c51447b 100644
--- a/INSTALL
+++ b/INSTALL
@@ -278,7 +278,11 @@ PYTHON_PREFIX_ARG=
 The hypervisor may be build with XSM support, which can be changed with
 the following variables.
 XSM_ENABLE=y
-FLASK_ENABLE=y
+
+The hypervisor may be build with Flask support, which can be changed
+by running:
+make -C xen menuconfig
+and enabling Flask in the 'Common Features' menu.
 
 Do a build for coverage.
 coverage=y
diff --git a/docs/misc/xsm-flask.txt b/docs/misc/xsm-flask.txt
index 7249f40..f2f0fd4 100644
--- a/docs/misc/xsm-flask.txt
+++ b/docs/misc/xsm-flask.txt
@@ -172,8 +172,9 @@ Setting up FLASK
 
 
 Xen must be compiled with XSM and FLASK enabled; by default, the security
-framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE and
-FLASK_ENABLE to "y"; this change requires a make clean and rebuild.
+framework is disabled. Edit Config.mk or the .config file to set XSM_ENABLE to
+"y" and running 'make -C xen menuconfig' and enabling FLASK inside 'Common
+Features'; this change requires a make clean and rebuild.
 
 FLASK uses only one domain configuration parameter (seclabel) defining the
 full security label of the newly created domain. If using the example policy,
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 8839dca..489cfd1 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -53,7 +53,6 @@ CFLAGS += -pipe -g -D__XEN__ -include 
$(BASEDIR)/include/xen/config.h
 CFLAGS += '-D__OBJECT_FILE__="$@"'
 
 CFLAGS-$(XSM_ENABLE)+= -DXSM_ENABLE
-CFLAGS-$(FLASK_ENABLE)  += -DFLASK_ENABLE
 CFLAGS-$(verbose)   += -DVERBOSE
 CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 046e257..3419816 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -8,6 +8,17 @@ config COMPAT
  HVM and PV guests. HVMLoader makes 32-bit hypercalls irrespective
  of the destination runmode of the guest.
 
+config FLASK
+   bool "FLux Advanced Security Kernel support"
+   default n
+   ---help---
+ Enables the FLASK (FLux Advanced Security Kernel) support which
+ provides a mandatory access control framework by which security
+ enforcement, isolation, and auditing can be achieved with fine
+ granular control via a security policy.
+
+ If unsure, say N.
+
 # Select HAS_DEVICE_TREE if device tree is supported
 config HAS_DEVICE_TREE
bool
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 94ba3d8..9c8188b 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -28,7 +28,7 @@ headers-$(CONFIG_X86) += compat/arch-x86/xen.h
 headers-$(CONFIG_X86) += compat/arch-x86/xen-$(compat-arch-y).h
 headers-$(CONFIG_X86) += compat/hvm/hvm_vcpu.h
 headers-y += compat/arch-$(compat-arch-y).h compat/pmu.h 
compat/xlat.h
-headers-$(FLASK_ENABLE)   += compat/xsm/flask_op.h
+headers-$(CONFIG_FLASK)   += compat/xsm/flask_op.h
 
 cppflags-y:= -include public/xen-compat.h
 cppflags-$(CONFIG_X86)+= -m32
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index 7595599..bba015a 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -86,7 +86,7 @@
 #define mk_unsigned_long(x) x
 #endif /* !__ASSEMBLY__ */
 
-#ifdef FLASK_ENABLE
+#ifdef CONFIG_FLASK
 #define XSM_MAGIC 0xf97cff8c
 /* Maintain statistics on the access vector cache */
 #define FLASK_AVC_STATS 1
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index fc61fc3..6ea3cc7 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -119,7 +119,7 @@ struct evtchn
  */
 void *generic;
 #endif
-#ifdef FLASK_ENABLE
+#ifdef CONFIG_FLASK
 /*
  * Inlining the contents of the structure for FLASK avoids unneeded
  * allocations, and on 64-bit platforms with only FLASK enabled,

Re: [Xen-devel] Sub page Grant Table mappings

[Andrew Cooper]

On 22/12/15 20:59, Mike Belopuhov wrote:
> Hi,
>
> I'm trying to get grant table sub page mappings working on Xen 4.5.
> I know there have been some changes in the trunk regarding moving src/
> dst checks closer together, but I can't test this easily atm.  Please
> bear with me for a moment.  Or tell me that it might have been broken
> previously.
>
> What I'm trying to do is to map in a 2k cluster from the networking
> stack (we call it an mbuf cluster, you might call it skb something)
> onto the Netfront Rx ring.  2 clusters fit one page.  Therefore for
> one frame address which is a (PA >> 12) I might have 2 entries one
> after the other, both with sub_page.length = 2048 but one with a
> sub_page.page_off = 2048 and the other with a 0 offset.  Both come
> with (GTF_permit_access | GTF_sub_page) flags.
>
> When I do that, Xen stops liking me and says:
>
> (XEN) grant_table.c:2162:d0v1 copy dest out of bounds: 0 < 2048 || 90 > 2048
> (XEN) grant_table.c:2162:d0v1 copy dest out of bounds: 0 < 2048 || 119 > 2048
> (XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 70 > 2048
> (XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 119 > 2048
> (XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 119 > 2048
> ...
>
> The relevant code does this:
>
> if ( dest_is_gref )
> {
> unsigned dest_off, dest_len;
> rc = __acquire_grant_for_copy(dd, op->dest.u.ref,
>   current->domain->domain_id, 0,
>   &d_frame, &d_pg, &dest_off, &dest_len, 
> 1);
> if ( rc != GNTST_okay )
> goto error_out;
> have_d_grant = 1;
> if ( op->dest.offset < dest_off ||
>  op->len > dest_len )
> PIN_FAIL(error_out, GNTST_general_error,
>  "copy dest out of bounds: %d < %d || %d > %d\n",
>  op->dest.offset, dest_off,
>  op->len, dest_len);
> }
>
> I fail to understand what am I doing wrong in this case.  Any clues
> will be greatly appreciated.
>
> 4k clusters mapped in as full_page mappings work as expected.
>
> Cheers,
> Mike

I presume you are on x86 here.

Architecturally, a 4k page is the minimum granularity which permissions
can be applied to.  It is not possible to make a 2k block accessible,
but an adjacent 2k block inaccessible.

As a result, grant mapping of a subpage grant is prohibited, but you are
(or at least should be) able to grant copy it.

Can you describe precisely which domains are doing what in your example?

~Andrew

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

[Xen-devel] Sub page Grant Table mappings

[Mike Belopuhov]

Hi,

I'm trying to get grant table sub page mappings working on Xen 4.5.
I know there have been some changes in the trunk regarding moving src/
dst checks closer together, but I can't test this easily atm.  Please
bear with me for a moment.  Or tell me that it might have been broken
previously.

What I'm trying to do is to map in a 2k cluster from the networking
stack (we call it an mbuf cluster, you might call it skb something)
onto the Netfront Rx ring.  2 clusters fit one page.  Therefore for
one frame address which is a (PA >> 12) I might have 2 entries one
after the other, both with sub_page.length = 2048 but one with a
sub_page.page_off = 2048 and the other with a 0 offset.  Both come
with (GTF_permit_access | GTF_sub_page) flags.

When I do that, Xen stops liking me and says:

(XEN) grant_table.c:2162:d0v1 copy dest out of bounds: 0 < 2048 || 90 > 2048
(XEN) grant_table.c:2162:d0v1 copy dest out of bounds: 0 < 2048 || 119 > 2048
(XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 70 > 2048
(XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 119 > 2048
(XEN) grant_table.c:2162:d0v2 copy dest out of bounds: 0 < 2048 || 119 > 2048
...

The relevant code does this:

if ( dest_is_gref )
{
unsigned dest_off, dest_len;
rc = __acquire_grant_for_copy(dd, op->dest.u.ref,
  current->domain->domain_id, 0,
  &d_frame, &d_pg, &dest_off, &dest_len, 1);
if ( rc != GNTST_okay )
goto error_out;
have_d_grant = 1;
if ( op->dest.offset < dest_off ||
 op->len > dest_len )
PIN_FAIL(error_out, GNTST_general_error,
 "copy dest out of bounds: %d < %d || %d > %d\n",
 op->dest.offset, dest_off,
 op->len, dest_len);
}

I fail to understand what am I doing wrong in this case.  Any clues
will be greatly appreciated.

4k clusters mapped in as full_page mappings work as expected.

Cheers,
Mike

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

Re: [Xen-devel] [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

[kbuild test robot]

Hi Stefano,

[auto build test WARNING on arm/for-next]
[also build test WARNING on v4.4-rc6 next-20151222]

url:
https://github.com/0day-ci/linux/commits/Stefano-Stabellini/arm-remove-CPU_V6-and-GENERIC_ATOMIC64-build-dependencies-for-XEN/20151222-222129
base:   http://repo.or.cz/linux-2.6/linux-2.6-arm.git for-next
config: arm-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/exynos/exynos_drm_ipp.c: In function 'ipp_get_mem_node':
>> drivers/gpu/drm/exynos/exynos_drm_ipp.c:585:4: warning: format '%x' expects 
>> argument of type 'unsigned int', but argument 4 has type 'dma_addr_t' 
>> [-Wformat=]
   DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
   ^
--
   In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/clk.h:16,
from drivers/gpu/drm/sti/sti_hqvdp.c:7:
   drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_vtg_cb':
   include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument 
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
 static struct _ddebug  __aligned(8)   \
   ^
   include/linux/dynamic_debug.h:84:2: note: in expansion of macro 
'DEFINE_DYNAMIC_DEBUG_METADATA'
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
 ^
   include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
 dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
 ^
>> drivers/gpu/drm/sti/sti_hqvdp.c:605:3: note: in expansion of macro 'dev_dbg'
  dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
  ^
   drivers/gpu/drm/sti/sti_hqvdp.c: In function 'sti_hqvdp_atomic_update':
   include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument 
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
 static struct _ddebug  __aligned(8)   \
   ^
   include/linux/dynamic_debug.h:84:2: note: in expansion of macro 
'DEFINE_DYNAMIC_DEBUG_METADATA'
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
 ^
   include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
 dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
 ^
   drivers/gpu/drm/sti/sti_hqvdp.c:931:2: note: in expansion of macro 'dev_dbg'
 dev_dbg(hqvdp->dev, "%s Posted command:0x%x\n",
 ^
--
   In file included from include/linux/printk.h:277:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/media/platform/soc_camera/mx3_camera.c:13:
   drivers/media/platform/soc_camera/mx3_camera.c: In function 
'mx3_cam_dma_done':
   include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument 
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
 static struct _ddebug  __aligned(8)   \
   ^
   include/linux/dynamic_debug.h:84:2: note: in expansion of macro 
'DEFINE_DYNAMIC_DEBUG_METADATA'
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
 ^
   include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
 dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
 ^
>> drivers/media/platform/soc_camera/mx3_camera.c:149:2: note: in expansion of 
>> macro 'dev_dbg'
 dev_dbg(chan->device->dev, "callback cookie %d, active DMA 0x%08x\n",
 ^
   drivers/media/platform/soc_camera/mx3_camera.c: In function 
'mx3_videobuf_queue':
   include/linux/dynamic_debug.h:64:16: warning: format '%x' expects argument 
of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
 static struct _ddebug  __aligned(8)   \
   ^
   include/linux/dynamic_debug.h:84:2: note: in expansion of macro 
'DEFINE_DYNAMIC_DEBUG_METADATA'
 DEFINE_DYNAMIC_DEBUG_METADATA(descriptor, fmt);  \
 ^
   include/linux/device.h:1179:2: note: in expansion of macro 'dynamic_dev_dbg'
 dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
 ^
   drivers/media/platform/soc_camera/mx3_camera.c:341:2: note: in expansion of 
macro 'dev_dbg'
 dev_dbg(icd->parent, "Submitted cookie %d DMA 0x%08x\n",
 ^
   drivers/media/platform/soc_camera/mx3_camera.c: In function 
'mx3_

Re: [Xen-devel] [PATCH v2 7/8] xen: arm: context switch vtimer PPI state.

[Stefano Stabellini]

On Tue, 10 Nov 2015, Ian Campbell wrote:
> ... instead of artificially masking the timer interrupt in the timer
> state and relying on the guest to unmask (which it isn't required to
> do per the h/w spec, although Linux does).
> 
> By using the newly added hwppi save/restore functionality we make use
> of the GICD I[SC]ACTIVER registers to save and restore the active
> state of the interrupt, which prevents the nested invocations which
> the current masking works around.
> 
> Signed-off-by: Ian Campbell 
> ---
> v2: Rebased, in particular over Julien's passthrough stuff which
> reworked a bunch of IRQ related stuff.
> Also largely rewritten since precursor patches now lay very
> different groundwork.
> ---
>  xen/arch/arm/time.c  | 26 ++
>  xen/arch/arm/vtimer.c| 41 +
>  xen/include/asm-arm/domain.h |  1 +
>  3 files changed, 40 insertions(+), 28 deletions(-)
> 
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 5ded30c..2a1cdba 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -181,28 +181,6 @@ static void timer_interrupt(int irq, void *dev_id, 
> struct cpu_user_regs *regs)
>  }
>  }
>  
> -static void vtimer_interrupt(int irq, void *dev_id, struct cpu_user_regs 
> *regs)
> -{
> -/*
> - * Edge-triggered interrupts can be used for the virtual timer. Even
> - * if the timer output signal is masked in the context switch, the
> - * GIC will keep track that of any interrupts raised while IRQS are
> - * disabled. As soon as IRQs are re-enabled, the virtual interrupt
> - * will be injected to Xen.
> - *
> - * If an IDLE vCPU was scheduled next then we should ignore the
> - * interrupt.
> - */
> -if ( unlikely(is_idle_vcpu(current)) )
> -return;
> -
> -perfc_incr(virt_timer_irqs);
> -
> -current->arch.virt_timer.ctl = READ_SYSREG32(CNTV_CTL_EL0);
> -WRITE_SYSREG32(current->arch.virt_timer.ctl | CNTx_CTL_MASK, 
> CNTV_CTL_EL0);
> -vgic_vcpu_inject_irq(current, current->arch.virt_timer.irq);
> -}
> -
>  /*
>   * Arch timer interrupt really ought to be level triggered, since the
>   * design of the timer/comparator mechanism is based around that
> @@ -242,8 +220,8 @@ void __cpuinit init_timer_interrupt(void)
>  
>  request_irq(timer_irq[TIMER_HYP_PPI], 0, timer_interrupt,
>  "hyptimer", NULL);
> -request_irq(timer_irq[TIMER_VIRT_PPI], 0, vtimer_interrupt,
> -   "virtimer", NULL);
> +route_hwppi_to_current_vcpu(timer_irq[TIMER_VIRT_PPI], "virtimer");
> +
>  request_irq(timer_irq[TIMER_PHYS_NONSECURE_PPI], 0, timer_interrupt,
>  "phytimer", NULL);
>  
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 1418092..82e2b88 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -55,9 +55,19 @@ static void phys_timer_expired(void *data)
>  static void virt_timer_expired(void *data)
>  {
>  struct vtimer *t = data;
> -t->ctl |= CNTx_CTL_MASK;
> -vgic_vcpu_inject_irq(t->v, t->irq);
> -perfc_incr(vtimer_virt_inject);
> +t->ctl |= CNTx_CTL_PENDING;
> +if ( !(t->ctl & CNTx_CTL_MASK) )
> +{
> +/*
> + * An edge triggered interrupt should now be pending. Since
> + * this timer can never expire while the domain is scheduled
> + * we know that the gic_restore_hwppi in virt_timer_restore
> + * will cause the real hwppi to occur and be routed.
> + */
> +gic_hwppi_set_pending(&t->ppi_state);

I wonder if calling gic_hwppi_set_pending is actually redundant:
virt_timer_restore will write the expired time to cval, causing a new
interrupt to be immediately sent as soon as it's enabled, right?


> +vcpu_unblock(t->v);
> +perfc_incr(vtimer_virt_inject);
> +}
>  }
>  
>  int domain_vtimer_init(struct domain *d, struct xen_arch_domainconfig 
> *config)
> @@ -96,9 +106,12 @@ int domain_vtimer_init(struct domain *d, struct 
> xen_arch_domainconfig *config)
>  
>  int vcpu_vtimer_init(struct vcpu *v)
>  {
> +struct pending_irq *p;
>  struct vtimer *t = &v->arch.phys_timer;
>  bool_t d0 = is_hardware_domain(v->domain);
>  
> +const unsigned host_vtimer_irq_ppi = timer_get_irq(TIMER_VIRT_PPI);
> +
>  /*
>   * Hardware domain uses the hardware interrupts, guests get the virtual
>   * platform.
> @@ -116,10 +129,16 @@ int vcpu_vtimer_init(struct vcpu *v)
>  init_timer(&t->timer, virt_timer_expired, t, v->processor);
>  t->ctl = 0;
>  t->irq = d0
> -? timer_get_irq(TIMER_VIRT_PPI)
> +? host_vtimer_irq_ppi
>  : GUEST_TIMER_VIRT_PPI;
>  t->v = v;
>  
> +p = irq_to_pending(v, t->irq);
> +p->irq = t->irq;
> +
> +gic_hwppi_state_init(&v->arch.virt_timer.ppi_state,
> + host_vtimer_irq_ppi);
> +
>  v->arch.vtimer_initialized = 1;
>  
>  return 0;
> @@ -147,

[Xen-devel] [OSSTEST PATCH] support XSM/FLASK via Kconfig

[Doug Goldstein]

In antcipation of XSM and FLASK migrating to Kconfig add support for
building them via Kconfig or the existing mechanism.

Signed-off-by: Doug Goldstein 
---
I have not tested this because I'm honestly not sure and I'm not sure if
this is correct. I'm just trying to write something to prevent a failure
once XSM/FLASK gets changed to Kconfig and education for myself on how
to do these patches in the future.
---
 ts-xen-build | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-xen-build b/ts-xen-build
index 80b1faa..6616ed3 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -55,6 +55,8 @@ sub checkout () {
echo >>.config KERNELS=''
 END
(nonempty($r{enable_xsm}) ? <>xen/.config CONFIG_XSM='${build_xsm}'
+   echo >>xen/.config CONFIG_FLASK='${build_xsm}'
echo >>.config XSM_ENABLE='${build_xsm}'
 END
(nonempty($r{tree_qemu}) ? 

[Xen-devel] Xen Security Advisory 169 (CVE-2015-8615) - x86: unintentional logging upon guest changing callback method

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Xen Security Advisory CVE-2015-8615 / XSA-169
  version 2

x86: unintentional logging upon guest changing callback method

UPDATES IN VERSION 2


CVE assigned.

ISSUE DESCRIPTION
=

HYPERVISOR_hvm_op sub-op HVMOP_set_param's HVM_PARAM_CALLBACK_IRQ
operation intends to log the new callback method in debug builds only.
The full message, however, is split into two parts, the second one of
which didn't get suppressed on non-debug builds as would have been
intended.

These log messages are not rate-limited and can be triggered by guests.

IMPACT
==

A malicious guest could cause repeated logging to the hypervisor
console, leading to a Denial of Service attack.

VULNERABLE SYSTEMS
==

Xen version 4.6 is affected.  Older Xen versions are unaffected.

ARM systems are not affected.

Only x86 HVM guests can expose this vulnerability.

MITIGATION
==

Running only PV guests will avoid this issue.

The problematic log messages are issued with priority Warning.
Therefore they can be rate limited by adding "loglvl=error/warning" to
the hypervisor command line or suppressed entirely by adding
"loglvl=error".

On systems where the guest kernel is controlled by the host rather
than guest administrator, running only kernels which do not excessively
invoke this operation will also prevent untrusted guest users from
exploiting this issue. However untrusted guest administrators can still
trigger it unless further steps are taken to prevent them from loading
code into the kernel (e.g. by disabling loadable modules etc) or from
using other mechanisms which allow them to run code at kernel privilege.

NOTE REGARDING LACK OF EMBARGO
==

The fix for this bug was publicly posted on xen-devel, before it was
appreciated that there was a security problem.

CREDITS
===

This issue was discovered as a bug by Malcolm Crossley of Citrix; the
security impact was recognised by Jan Beulich of SuSE.

RESOLUTION
==

Applying the attached patch resolves this issue.

xsa169.patchxen-unstable, Xen 4.6.x

$ sha256sum xsa169*
b818922880313cdbc12ea68ae757da5eabed9b3c9e1f8acefe1653683545ccbe  xsa169.patch
$
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJWeZqAAAoJEIP+FMlX6CvZ/HcIAMLIVFDrwUahqNkGIaS0rXrn
LJG6+oMewioAm05NEKI+2wkJn6T4ycJsn+rVWMyOTHpS39vA1kMZK3/Pb/smV3B1
2K+g8avmSjB22VEhjEoKIGniozkPIInB5Pvchf0GY6C30/LJM2ef3hJeQHUA+W9q
68HiXZrwFUUBRcpjoSX3ru954Fcfe0VDpEvIRJRS1O4v/XXJeesavt/0/5PnaP34
sRXr9+l7Ku+Q9z7sh9V87W9Lv98qXnuVns7c3GKIcmDEcvWDihwazCbvuVOZsvQW
UoV4/LTiJ2bTqnGp2woUqlTfe7MIOHPzjmR88Pj+/ibveObkcVMDxyz4r34wyxw=
=D97B
-END PGP SIGNATURE-


xsa169.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 11/28] libxl: emuids: Pass correct emuid to internal functions

[Ian Jackson]

Provide EMUID_PV and use it appropriately.  We split our qemus into
two:

EMUID_DM does actual emulation.  EMUID_PV is for PV backends.  Most
places relate to emulation and can simply pass EMUID_DM.

Creation is a notable exception, where we pass the emuid as a new
parameter to the spawn functions.

There is no overall functional change, because the ultimate consumer,
libxl__device_model_xs_path, does not pay any attention to the
parameter yet, and because we still need to plumb the emuid through to
the qemu argument construction.

Also, domain destruction does not yet pass the right emuid.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson dmss.dm.guest_domid = domid;
-if (libxl_defbool_val(d_config->b_info.device_model_stubdomain))
-libxl__spawn_stub_dm(egc, &dcs->dmss);
-else
-libxl__spawn_local_dm(egc, &dcs->dmss.dm);
+if (libxl_defbool_val(d_config->b_info.device_model_stubdomain)) {
+libxl__spawn_stub_dm(egc, &dcs->dmss, EMUID_DM);
+} else {
+libxl__spawn_local_dm(egc, &dcs->dmss.dm, EMUID_DM);
+}
 
 /*
  * Handle the domain's (and the related stubdomain's) access to
@@ -1348,7 +1349,7 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 
 if (need_qemu) {
 dcs->dmss.dm.guest_domid = domid;
-libxl__spawn_local_dm(egc, &dcs->dmss.dm);
+libxl__spawn_local_dm(egc, &dcs->dmss.dm, EMUID_PV);
 return;
 } else {
 assert(!dcs->dmss.dm.guest_domid);
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 593f3e6..1e1dfa0 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1434,7 +1434,8 @@ char *libxl__stub_dm_name(libxl__gc *gc, const char 
*guest_name)
 return GCSPRINTF("%s-dm", guest_name);
 }
 
-void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss)
+void libxl__spawn_stub_dm(libxl__egc *egc, libxl__stub_dm_spawn_state *sdss,
+  int emuid)
 {
 STATE_AO_GC(sdss->dm.spawn.ao);
 libxl_ctx *ctx = libxl__gc_owner(gc);
@@ -1558,7 +1559,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss)
 retry_transaction:
 t = xs_transaction_start(ctx->xsh);
 const char *dmpath = libxl__device_model_xs_path(gc,
-dm_domid, guest_domid, EMUID_DM, "");
+dm_domid, guest_domid, emuid, "");
 xs_mkdir(ctx->xsh, t, dmpath);
 xs_set_permissions(ctx->xsh, t,
dmpath,
@@ -1668,7 +1669,7 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
 sdss->pvqemu.build_state = &sdss->dm_state;
 sdss->pvqemu.callback = spawn_stubdom_pvqemu_cb;
 
-libxl__spawn_local_dm(egc, &sdss->pvqemu);
+libxl__spawn_local_dm(egc, &sdss->pvqemu, EMUID_PV);
 
 return;
 
@@ -1724,7 +1725,7 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
   dm_domid, sdss->dm.guest_domid);
 sdss->xswait.path =
 libxl__device_model_xs_path(gc, dm_domid, sdss->dm.guest_domid,
-EMUID_DM, "/state");
+EMUID_PV, "/state");
 sdss->xswait.timeout_ms = LIBXL_STUBDOM_START_TIMEOUT * 1000;
 sdss->xswait.callback = stubdom_xswait_cb;
 rc = libxl__xswait_start(gc, &sdss->xswait);
@@ -1771,7 +1772,8 @@ static void device_model_spawn_outcome(libxl__egc *egc,
libxl__dm_spawn_state *dmss,
int rc);
 
-void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss)
+void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state *dmss,
+   int emuid)
 {
 /* convenience aliases */
 const int domid = dmss->guest_domid;
@@ -1832,7 +1834,7 @@ void libxl__spawn_local_dm(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 }
 
 path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
-   domid, EMUID_DM, "");
+   domid, emuid, "");
 xs_mkdir(ctx->xsh, XBT_NULL, path);
 
 if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
@@ -1887,7 +1889,7 @@ retry_transaction:
 
 spawn->what = GCSPRINTF("domain %d device model", domid);
 spawn->xspath = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
-domid, EMUID_DM, "/state");
+domid, emuid, "/state");
 spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
 spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
 spawn->midproc_cb = libxl__spawn_record_pid;
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index ec93797..843fdbf 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -554,8 +554,7 @@ void libxl__update_domain_configuration(libxl__

[Xen-devel] [PATCH 05/28] libxl: libxl__spawn_stub_dm: Introduce `dmpath'

[Ian Jackson]

Combine two identical calls to libxl__device_model_xs_path, for
clarity.

No functional change.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_dm.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 675e859..6f5fe45 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1557,11 +1557,11 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss)
 perm[1].perms = XS_PERM_READ;
 retry_transaction:
 t = xs_transaction_start(ctx->xsh);
-xs_mkdir(ctx->xsh, t,
- libxl__device_model_xs_path(gc, dm_domid, guest_domid, ""));
+const char *dmpath = libxl__device_model_xs_path(gc,
+dm_domid, guest_domid, "");
+xs_mkdir(ctx->xsh, t, dmpath);
 xs_set_permissions(ctx->xsh, t,
-   libxl__device_model_xs_path(gc, dm_domid,
-   guest_domid, ""),
+   dmpath,
perm, ARRAY_SIZE(perm));
 if (!xs_transaction_end(ctx->xsh, t, 0))
 if (errno == EAGAIN)
-- 
1.7.10.4


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

[Xen-devel] [PATCH 10/28] libxl: kill_device_model: Silently tolerate ENOENT on pid xs path

[Ian Jackson]

If the pid is absent in xenstore, this means there is no such DM.  Do
not complain about this, then.  This allows us to simplify call sites.
Do so for libxl__destroy_domid.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl.c|4 +---
 tools/libxl/libxl_dm.c |7 ++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 5414649..2a0c092 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1606,7 +1606,6 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 libxl_ctx *ctx = CTX;
 uint32_t domid = dis->domid;
 char *dom_path;
-char *pid;
 int rc, dm_present;
 
 libxl__ev_child_init(&dis->destroyer);
@@ -1642,8 +1641,7 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 }
 /* fall through */
 case LIBXL_DOMAIN_TYPE_PV:
-pid = libxl__xs_read(gc, XBT_NULL, 
GCSPRINTF("/local/domain/%d/image/device-model-pid", domid));
-dm_present = (pid != NULL);
+dm_present = 1;
 break;
 case LIBXL_DOMAIN_TYPE_INVALID:
 rc = ERROR_FAIL;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index b85b377..593f3e6 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2053,11 +2053,16 @@ static int kill_device_model(libxl__gc *gc, const char 
*xs_path_pid)
 int ret, pid;
 
 ret = libxl__xs_read_checked(gc, XBT_NULL, xs_path_pid, &xs_pid);
-if (ret || !xs_pid) {
+if (ret) {
 LOG(ERROR, "unable to find device model pid in %s", xs_path_pid);
 ret = ret ? : ERROR_FAIL;
 goto out;
 }
+if (!xs_pid) {
+/* Jolly good */
+ret = 0;
+goto out;
+}
 pid = atoi(xs_pid);
 
 ret = kill(pid, SIGHUP);
-- 
1.7.10.4


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

[Xen-devel] [PATCH 26/28] libxl: spawns two QEMUs for HVM guests

[Ian Jackson]

From: Stefano Stabellini 

We actually need to spawn a second QEMU if we want to run qemu as
non-root, because the pv backends ought to run as root (or device
hotplug may not work).

So in this case, start a second QEMU to provide PV backends in
userspace to HVM guests.  Use both dcs->dmss.pvqemu and dcs->dmss.dm
to keep track of the starting QEMUs.

Only proceed when both QEMUs have started.

And, we only default to running QEMU as non-root if we are going to be
able to run split qemus.  In particular, it is not safe to run split
qemus if they don't support the emulator_id option, because we need to
split the xenstore paths too.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Split only if trying to run a qemu as non-root
Reorganise changes to dm callbacks
No more dcs in dmss
Use min() to calculate worst rc
Explicitly set unused fields of dmss.pvqemu to 0
Change error handling

v3: use dcs->dmss.pvqemu to spawn the second QEMU
keep track of the rc of both QEMUs before proceeding
---
 tools/libxl/libxl_create.c |   72 
 1 file changed, 72 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e67e402..59dfcd67 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -431,6 +431,8 @@ static int domcreate_setdefault_dm_user(libxl__gc *gc,
 int rc;
 const char *user;
 
+const char *dm = libxl__domain_device_model(gc, b_info);
+
 if (b_info->device_model_user)
 /* already set, good-oh */
 return 0;
@@ -440,6 +442,15 @@ static int domcreate_setdefault_dm_user(libxl__gc *gc,
 /* we're not going to run it anyway */
 return 0;
 
+if (!libxl__dm_supported(gc, dm, libxl__dm_support_check__emulator_id)) {
+/* we don't want to run the pv backends as non-root because
+ * device hotplug will no longer work. */
+LOG(WARN,
+ "Device model does not support split PV backends, running it as root");
+user = "root";
+goto found;
+}
+
 user = GCSPRINTF("%s%d", LIBXL_QEMU_USER_BASE, domid);
 
 rc = dm_runas_helper(gc, user);
@@ -802,6 +813,14 @@ static void remus_checkpoint_stream_done(
 /* Event callbacks, in this order: */
 static void domcreate_dm_support_checked(libxl__egc *egc,
 libxl__dm_support_check_state *checking, int rc);
+
+static void domcreate_dm_local_split_pv_cb(libxl__egc *egc,
+   libxl__dm_spawn_state *dmss);
+static void domcreate_dm_local_split_dm_cb(libxl__egc *egc,
+   libxl__dm_spawn_state *dmss);
+static void domcreate_dm_local_split_cb(libxl__egc *egc,
+libxl__domain_create_state *dcs);
+
 static void domcreate_devmodel_started(libxl__egc *egc,
libxl__dm_spawn_state *dmss);
 static void domcreate_bootloader_console_available(libxl__egc *egc,
@@ -1044,6 +1063,9 @@ static void domcreate_dm_support_checked(libxl__egc *egc,
 
 /* convenience aliases */
 libxl_domain_config *const d_config = dcs->guest_config;
+const libxl_domain_build_info *b_info = &d_config->b_info;
+libxl__domain_build_state *const b_state = &dcs->build_state;
+const uint32_t domid = dcs->guest_domid;
 const int restore_fd = dcs->restore_fd;
 
 if (rc) goto out;
@@ -1053,6 +1075,15 @@ static void domcreate_dm_support_checked(libxl__egc *egc,
 rc = domcreate_setdefault_dm_user(gc, dcs);
 if (rc) goto out;
 
+/* run two qemus? */
+if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
+!libxl_defbool_val(d_config->b_info.device_model_stubdomain) &&
+b_info->device_model_user &&
+strcmp(b_info->device_model_user, "root")) {
+rc = libxl__dm_emuidmap_add(gc, domid, b_state, EMUID_SPLIT);
+if (rc) goto out;
+}
+
 dcs->bl.ao = ao;
 libxl_device_disk *bootdisk =
 d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
@@ -1130,6 +1161,11 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 dcs->dmss.dm.callback = domcreate_devmodel_started;
 dcs->dmss.callback = domcreate_devmodel_started;
 
+dcs->dmss.pvqemu.spawn.ao = ao;
+dcs->dmss.pvqemu.guest_domid = domid;
+dcs->dmss.pvqemu.guest_config = 0;
+dcs->dmss.pvqemu.build_state = 0;
+
 if (restore_fd < 0 && dcs->domid_soft_reset == INVALID_DOMID) {
 rc = libxl__domain_build(gc, d_config, domid, state);
 domcreate_rebuild_done(egc, dcs, rc);
@@ -1398,6 +1434,16 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 if (libxl_defbool_val(d_config->b_info.device_model_stubdomain)) {
 libxl__spawn_stub_dm(egc, &dcs->dmss, EMUID_DM);
 } else {
+if (state->emuidmap & (1u << EMUID_SPLIT)) {
+dcs->dmss.dm.rc = 1;
+dcs->dmss.dm.callback = domcreate_dm

[Xen-devel] [PATCH 08/28] libxl: libxl__destroy_domid: Bring dm destruction together

[Ian Jackson]

Change the order of operations so that the dm determination and
destruction occur together.

The functional change is that the xenstore reads relating to the dm
determination now occur after the pci devices have been removed and
the domain has been paused.  This should not have any visible effect.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d96189d..1ac5d81 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1621,6 +1621,19 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 goto out;
 }
 
+if (libxl__device_pci_destroy_all(gc, domid) < 0)
+LOG(ERROR, "pci shutdown failed for domid %d", domid);
+rc = xc_domain_pause(ctx->xch, domid);
+if (rc < 0) {
+LOGEV(ERROR, rc, "xc_domain_pause failed for %d", domid);
+}
+
+dom_path = libxl__xs_get_dompath(gc, domid);
+if (!dom_path) {
+rc = ERROR_FAIL;
+goto out;
+}
+
 switch (libxl__domain_type(gc, domid)) {
 case LIBXL_DOMAIN_TYPE_HVM:
 if (libxl_get_stubdom_id(CTX, domid)) {
@@ -1639,18 +1652,6 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 abort();
 }
 
-dom_path = libxl__xs_get_dompath(gc, domid);
-if (!dom_path) {
-rc = ERROR_FAIL;
-goto out;
-}
-
-if (libxl__device_pci_destroy_all(gc, domid) < 0)
-LOG(ERROR, "pci shutdown failed for domid %d", domid);
-rc = xc_domain_pause(ctx->xch, domid);
-if (rc < 0) {
-LOGEV(ERROR, rc, "xc_domain_pause failed for %d", domid);
-}
 if (dm_present) {
 if (libxl__destroy_device_model(gc, domid) < 0)
 LOG(ERROR, "libxl__destroy_device_model failed for %d", domid);
-- 
1.7.10.4


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

[Xen-devel] [PATCH 28/28] libxl: xsrestrict QEMU

[Ian Jackson]

If QEMU supports xsrestrict, pass xsrestrict=on to it (by default).

XXX We need to do this only if xenstored supports it, and AFAICT there
is not a particularly easy way to test this.  Should we open a new
test xenstore connection to query this information ?  We could do this
once per libxl ctx.

Allow the user to specify that xsrestrict should be on, in which case
if it qemu cannot be depriv'd, we fail.

When qemu is depriv'd it still needs write access to the physmap
records in xenstore.  It will be running with the privilege of the
domain, so we need to allow the domain write access to
 /local/domain/$LIBXL_TOOLSTACK_DOMID/device-model/$DOMID/physmap

It doesn't contain any information the guest doesn't already know.
However be aware that it still means relaxing a tools/guest
interface.

The guest physmap contains the memory layout of the guest.  The guest
is already in possession of this information.  A malicious guest could
modify the physmap entries causing QEMU to read wrong information at
restore time. QEMU would populate its XenPhysmap list with wrong
entries that wouldn't match its own device emulation addresses,
leading to a failure in restoring the domain.  But it could not
compromise the security of the system because the addresses are only
used for checks against QEMU's addresses.

Is it dangerous to let the guest write values that later QEMU and
libxl read back?  Let's dig a bit deeper into the code. QEMU and libxl
use very similar functions to parse the physmap entries.

Let's start checking libxl.  The function that reads the physmap is
libxl__toolstack_save.  It calls:

* libxl__xs_directory on /physmap
  This is safe.

* libxl__xs_read
  If the path is wrong (nothing is there), it returns NULL, and it is
  handled correctly.

* strtoll on the values read
  The values are under guest control but strtoll can handle bad
  formats.  strtoll always returns an unsigned long long.  In case of
  errors, it can return LLONG_MIN or LLONG_MAX.  libxl__toolstack_save
  doesn't check for conversion errors, but it never uses the returned
  values anywhere.  That's OK.  libxl__toolstack_restore writes back
  the values to xenstore.

So in case of errors:

1) libxl__toolstack_save could return early with an error, if the
xenstore paths are wrong (nothing is on xenstore)

2) libxl__toolstack_restore could write back to xenstore any unsigned
long long, including LLONG_MIN or LLONG_MAX

Either way libxl is fine.

>From the QEMU side, the code is very similar and uses strtoll to parse
the entries, that can deal with bad input values.  The values are used
to avoid memory allocations at restore time for memory that has
already been allocated (video memory).  If the values are wrong, QEMU
will attempt another memory allocation, failing because the maxmem
limit has been reached.

Either way QEMU is fine.

There are no other out-of-guest consumers of this information.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 

---
v6: Merge the xsrestrict and the permissions update patches, so that
  the permission relaxation is done only when needed.
Rip out qemu feature checking code, now in new (earlier) patch
Rip out emulator_id, now in new (earlier) patch
Provide and document a config option to control restriction.
Make the default depend on specified dm user, and on stubdomness.
Arrange that when we are going to xsrestrict, we will run two qemus,
  as required
Move rwperm initialisaton higher up the relevant function to help
  avoid future changes using it uninitialised.
Grant write access on to the physmap subdirectory, and drop
  discussion of the rest from the commit message, and adjust
  the xenstore doc accordingly.
Move the physmap number of entries limit into its own patch.

v5 (permissions):
improve commit message with security details

v4 (permissions):
add error message in case count > MAX_PHYSMAP_ENTRIES
add a note to xenstore-paths.markdown about the possible change in
 privilege level
only change permissions if xsrestrict is supported

v4 (xsrestrict):
update xenstore-paths.markdown

v3 (xsrestrict):
add emulator_ids
mark as WIP

v3 (permissions):
use LIBXL_TOOLSTACK_DOMID instead of 0 in the commit message
update commit message with more info on why it is safe
add a limit on the number of physmap entries to save and restore

v2 (permissioins):
fix permissions to actually do what intended
use LIBXL_TOOLSTACK_DOMID instead of 0
---
 docs/man/xl.cfg.pod.5 |   14 ++
 docs/misc/xenstore-paths.markdown |7 +
 tools/libxl/libxl_create.c|   51 +++--
 tools/libxl/libxl_dm.c|   30 --
 tools/libxl/libxl_types.idl   |1 +
 tools/libxl/xl_cmdimpl.c  |2 ++
 6 files changed, 101 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index dd93725..7

[Xen-devel] [PATCH 04/28] libxl: Invoke libxl__dm_support_*

[Ian Jackson]

When creating a domain (including when restoring), invoke the
dm_support_check machinery on the principal qemu dm (if applicable).

This involves another introducing function callback boundary in the
domcreate control flow; but this is a straightforward one.

Now, libxl__dm_supported is available (for the principal qemu dm) in
the rest of the creation path.

No callers of libxl__dm_supported yet.  So in this patch we just
pointlessly run qemu, collect and scan its usage message, and cache
what we understand from the results.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_create.c   |   47 ++
 tools/libxl/libxl_internal.h |1 +
 2 files changed, 39 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 261816a..1af7066 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -719,6 +719,8 @@ static void remus_checkpoint_stream_done(
  */
 
 /* Event callbacks, in this order: */
+static void domcreate_dm_support_checked(libxl__egc *egc,
+libxl__dm_support_check_state *checking, int rc);
 static void domcreate_devmodel_started(libxl__egc *egc,
libxl__dm_spawn_state *dmss,
int rc);
@@ -774,7 +776,7 @@ static void initiate_domain_create(libxl__egc *egc,
 /* convenience aliases */
 libxl_domain_config *const d_config = dcs->guest_config;
 libxl__domain_build_state *const state = &dcs->build_state;
-const int restore_fd = dcs->restore_fd;
+const libxl_domain_build_info *b_info = &d_config->b_info;
 
 domid = dcs->domid_soft_reset;
 
@@ -911,10 +913,6 @@ static void initiate_domain_create(libxl__egc *egc,
 }
 }
 
-dcs->bl.ao = ao;
-libxl_device_disk *bootdisk =
-d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
-
 /*
  * The devid has to be set before launching the device model. For the
  * hotplug case this is done in libxl_device_nic_add but on domain
@@ -942,6 +940,41 @@ static void initiate_domain_create(libxl__egc *egc,
 d_config->nics[i].devid = ++last_devid;
 }
 
+if (b_info->type != LIBXL_DOMAIN_TYPE_HVM ||
+libxl_defbool_val(b_info->device_model_stubdomain)) {
+domcreate_dm_support_checked(egc, &dcs->dm_support_check, 0);
+} else {
+dcs->dm_support_check.ao = ao;
+dcs->dm_support_check.dm = libxl__domain_device_model(gc, b_info);
+dcs->dm_support_check.callback = domcreate_dm_support_checked;
+libxl__dm_support_check_start(&dcs->dm_support_check);
+}
+
+error_out:
+assert(ret);
+domcreate_complete(egc, dcs, ret);
+}
+
+static void domcreate_dm_support_checked(libxl__egc *egc,
+libxl__dm_support_check_state *checking, int rc)
+{
+libxl__domain_create_state *dcs =
+CONTAINER_OF(checking, *dcs, dm_support_check);
+STATE_AO_GC(dcs->ao);
+
+/* convenience aliases */
+libxl_domain_config *const d_config = dcs->guest_config;
+const int restore_fd = dcs->restore_fd;
+
+if (rc) {
+domcreate_complete(egc, dcs, rc);
+return;
+}
+
+dcs->bl.ao = ao;
+libxl_device_disk *bootdisk =
+d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
+
 if (restore_fd >= 0 || dcs->domid_soft_reset != INVALID_DOMID) {
 LOG(DEBUG, "restoring, not running bootloader");
 domcreate_bootloader_done(egc, &dcs->bl, 0);
@@ -959,10 +992,6 @@ static void initiate_domain_create(libxl__egc *egc,
 libxl__bootloader_run(egc, &dcs->bl);
 }
 return;
-
-error_out:
-assert(ret);
-domcreate_complete(egc, dcs, ret);
 }
 
 static void domcreate_bootloader_console_available(libxl__egc *egc,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index f963ad6..fd6ef61 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3510,6 +3510,7 @@ struct libxl__domain_create_state {
 /* private to domain_create */
 int guest_domid;
 libxl__domain_build_state build_state;
+libxl__dm_support_check_state dm_support_check;
 libxl__bootloader_state bl;
 libxl__stub_dm_spawn_state dmss;
 /* If we're not doing stubdom, we use only dmss.dm,
-- 
1.7.10.4


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

[Xen-devel] [RFC PATCH v6 00/28] libxl: Deprivilege qemu

[Ian Jackson]

This is a new version of Stefano Stabellini's series
  [PATCH v5 0/6] libxl: xs_restrict QEMU

I took Stefano's code as a spec for how to interact with qemu, and
have reworked the whole series.  In particular, I have
 - rebased onto staging
 - split up some of the larger patches
 - restructured the patches so that every intervening version should work
 - redone the async task handling
 - provided what seem to me to be appropriate configuration options
 - shaved a few yaks (although I tried to limit this!)
 - fixed the cross-version compatibility
 - reduced the new permission grant for the domain to only .../physmap

I have compiled this but I haven't tested it yet.

I think it would be very useful at this stage for others to read the
commit messages, internal docs, and important structural elements.

Detailed code review should probably wait until after testing which in
turn ought to wait unil we decide what (if any) design and interface
changes are needed.

And I don't expect to get any feedback until the new year :-).

Happy holidays all.

Regards,
Ian.

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

[Xen-devel] [PATCH 27/28] libxl: Limit qemu physmap entries

[Ian Jackson]

Add a maximum limit of physmap entries to save, so that when the guest
gets write access to physmap it cannot DOS the toolstack.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Split out of xs permissions relaxation patch.
---
 tools/libxl/libxl_dom.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 6ded9c1..60e8f7f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1431,6 +1431,8 @@ static void append_string(libxl__gc *gc, char **buf, 
uint32_t *len,
 *len += extralen;
 }
 
+#define MAX_PHYSMAP_ENTRIES 12
+
 int libxl__save_emulator_xenstore_data(libxl__domain_suspend_state *dss,
char **callee_buf,
uint32_t *callee_len)
@@ -1450,6 +1452,11 @@ int 
libxl__save_emulator_xenstore_data(libxl__domain_suspend_state *dss,
   &nr_entries);
 if (!entries || nr_entries == 0) { rc = 0; goto out; }
 
+if (nr_entries > MAX_PHYSMAP_ENTRIES) {
+LOG(ERROR, "Max physmap entries reached");
+return ERROR_FAIL;
+}
+
 for (i = 0; i < nr_entries; ++i) {
 static const char *const physmap_subkeys[] = {
 "start_addr", "size", "name"
-- 
1.7.10.4


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

[Xen-devel] [PATCH 17/28] libxl: emuids: Do not open-code device-model/%u in libxl__destroy_qdisk_backend

[Ian Jackson]

This is used in a driver domain context and doesn't get the caller's
domid.  But that's OK, we can now use libxl__dm_xs_path_rel which
returns the same value as previously.

No functional change.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_dm.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5b56047..3bf1317 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2109,7 +2109,7 @@ int libxl__destroy_qdisk_backend(libxl__gc *gc, uint32_t 
domid)
 
 libxl__xs_rm_checked(gc, XBT_NULL, pid_path);
 libxl__xs_rm_checked(gc, XBT_NULL,
- GCSPRINTF("device-model/%u", domid));
+ libxl__dm_xs_path_rel(gc, domid, EMUID_PV));
 
 out:
 return rc;
-- 
1.7.10.4


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

[Xen-devel] [PATCH 03/28] libxl: Provide libxl__dm_support_*

[Ian Jackson]

This allows code elsewhere in libxl to find out what options a device
model executable supports.  This is done by searching the usage
message for fixed strings.

Because this involves calling fork, callers must use the async
machinery.  To make this easier, and to avoid repeatedly invoking the
dm, we provide a cache within the libxl__ctx.

No call site yet.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Completely rewritten.
Cache is now in ctx only, not in xenstore.
We use the proper libxl__ev_child machinery for fork.
---
 tools/libxl/libxl.c  |4 +
 tools/libxl/libxl_dm.c   |  231 ++
 tools/libxl/libxl_internal.h |   76 ++
 3 files changed, 311 insertions(+)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9207621..d96189d 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -87,6 +87,8 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 ctx->sigchld_selfpipe[1] = -1;
 libxl__ev_fd_init(&ctx->sigchld_selfpipe_efd);
 
+LIBXL_LIST_INIT(&ctx->dm_support_cache);
+
 /* The mutex is special because we can't idempotently destroy it */
 
 if (libxl__init_recursive_mutex(ctx, &ctx->lock) < 0) {
@@ -208,6 +210,8 @@ int libxl_ctx_free(libxl_ctx *ctx)
 libxl__sigchld_notneeded(gc);
 libxl__pipe_close(ctx->sigchld_selfpipe);
 
+libxl__dm_support_cache_destroy(gc);
+
 CTX_UNLOCK;
 pthread_mutex_destroy(&ctx->lock);
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0aaefd9..675e859 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2169,6 +2169,237 @@ out:
 return ret;
 }
 
+/*- libxl__dm_support_* -*/
+
+/* cache */
+
+static libxl__dm_support_cached *
+dm_support_cache_lookup(libxl__gc *gc, const char *dm)
+{
+libxl__dm_support_cached *search;
+
+LIBXL_LIST_FOREACH(search, &CTX->dm_support_cache, entry)
+if (!strcmp(search->dm, dm))
+return search;
+
+return 0;
+}
+
+_hidden void libxl__dm_support_cache_destroy(libxl__gc *gc)
+{
+libxl__dm_support_cached *iter, *next;
+
+LIBXL_LIST_FOREACH_SAFE(iter, &CTX->dm_support_cache, entry, next) {
+free(iter->dm);
+free(iter);
+}
+}
+
+_hidden bool libxl__dm_supported(libxl__gc *gc, const char *dm,
+ libxl__dm_support_check__index opt)
+{
+libxl__dm_support_cached *cached = dm_support_cache_lookup(gc, dm);
+assert(cached);
+return !!(cached->bitmap & (1UL << opt));
+}
+
+/* `check', the long-running operation to check for support */
+
+static void dm_support_check_immed_cb(libxl__egc *egc, libxl__ev_time *ev,
+const struct timeval *requested_abs,
+int rc);
+static void dm_support_check_child_cb(libxl__egc *egc, libxl__ev_child*,
+  pid_t pid, int status);
+static void dm_support_check_done(libxl__egc *gc,
+  libxl__dm_support_check_state *ch,
+  int rc);
+
+_hidden void libxl__dm_support_check_init(libxl__dm_support_check_state *ch)
+{
+FILLZERO(*ch);
+libxl__ev_child_init(&ch->child);
+libxl__ev_time_init(&ch->immediate);
+}
+
+static void dm_support_check_free(libxl__gc *gc,
+  libxl__dm_support_check_state *ch)
+{
+if (ch->helpmsg) fclose(ch->helpmsg);
+assert(!libxl__ev_child_inuse(&ch->child));
+libxl__ev_time_deregister(gc, &ch->immediate);
+}
+
+_hidden int libxl__dm_support_check_start(libxl__dm_support_check_state *ch)
+{
+int r, rc;
+
+/* convenience aliases */
+const char *const dm = ch->dm;
+libxl__ao *const ao = ch->ao;
+AO_GC;
+
+libxl__dm_support_check_init(ch);
+
+r = stat(ch->dm, &ch->stab);
+if (r<0) {
+LOGE(ERROR, "device model %s is not accessible", dm);
+rc = ERROR_FAIL;
+goto out;
+}
+
+libxl__dm_support_cached *cached = dm_support_cache_lookup(gc, dm);
+if (cached &&
+(ch->stab.st_mode  == cached->stab.st_mode  &&
+ ch->stab.st_dev   == cached->stab.st_dev   &&
+ ch->stab.st_ino   == cached->stab.st_ino   &&
+ ch->stab.st_mtime == cached->stab.st_mtime &&
+ ch->stab.st_ctime == cached->stab.st_ctime)) {
+
+LOG(DEBUG, "returning cached support options for %s: %"PRIx32"",
+dm, cached->bitmap);
+
+rc = libxl__ev_time_register_rel(ao, &ch->immediate,
+ dm_support_check_immed_cb, 0);
+if (rc) goto out;
+
+/* we have queued a callback, our work in this function is done */
+return 0;
+}
+
+ch->revalidate = cached;
+if (cached) {
+LOG(DEBUG, "revalidating cached support options for %s", dm);
+}
+
+ch->helpmsg = tmpfile();
+if (!ch->helpmsg) {
+LOGE(ERROR, "create tempfile for help 

[Xen-devel] [PATCH 21/28] libxl: dm user: Reject attempts to set user!=root with qemu trad

[Ian Jackson]

Previously this option would be silently ignored, which is a potential
security problem (introduced in 84f2fd1b "run QEMU as non-root" in
xen-unstable only).

Signed-off-by: Ian Jackson 
CC: Stefano Stabellini 
---
v6: New patch.
---
 tools/libxl/libxl_dm.c |8 
 1 file changed, 8 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 886ed9c..8232981 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -415,6 +415,14 @@ static int libxl__build_device_model_args_old(libxl__gc 
*gc,
 dm_args = flexarray_make(gc, 16, 1);
 dm_envs = flexarray_make(gc, 16, 1);
 
+if (b_info->device_model_user && /* default is NULL if stubdom */
+strcmp(b_info->device_model_user,"root")) {
+LOG(ERROR,
+ "device_model_user != root (%s) not supported by qemu-xen-traditional",
+b_info->device_model_user);
+return ERROR_INVAL;
+}
+
 flexarray_vappend(dm_args, dm,
   "-d", GCSPRINTF("%d", domid), NULL);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 14/28] libxl: emuids: Pass emuid to dm destruction

[Ian Jackson]

Rather than recomputing this with a switch() statement, etc., we rely
on the emuidmap to tell us which qemus to destroy.

Signed-off-by: Ian Jackson 
---
v6: New patch.  This is a new approach in v6.

squash! libxl: Pass emuid to dm destruction
---
 tools/libxl/libxl.c  |   31 ---
 tools/libxl/libxl_dm.c   |   13 +
 tools/libxl/libxl_internal.h |3 ++-
 3 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2a0c092..dff4478 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1606,7 +1606,8 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 libxl_ctx *ctx = CTX;
 uint32_t domid = dis->domid;
 char *dom_path;
-int rc, dm_present;
+int rc;
+unsigned emuidmap;
 
 libxl__ev_child_init(&dis->destroyer);
 
@@ -1633,27 +1634,19 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 goto out;
 }
 
-switch (libxl__domain_type(gc, domid)) {
-case LIBXL_DOMAIN_TYPE_HVM:
-if (libxl_get_stubdom_id(CTX, domid)) {
-dm_present = 0;
-break;
-}
-/* fall through */
-case LIBXL_DOMAIN_TYPE_PV:
-dm_present = 1;
-break;
-case LIBXL_DOMAIN_TYPE_INVALID:
-rc = ERROR_FAIL;
-goto out;
-default:
-abort();
-}
+libxl__dm_emuidmap_get_bodgeerrors(gc, domid, &emuidmap);
 
-if (dm_present) {
-libxl__destroy_device_model(gc, domid);
+libxl__destroy_device_model(gc, domid, emuidmap, EMUID_PV);
 
+if (libxl__domain_type(gc, domid) == LIBXL_DOMAIN_TYPE_HVM &&
+libxl_get_stubdom_id(CTX, domid)) {
+/* This is destroyed in libxl__domain_destroy */
+} else {
+libxl__destroy_device_model(gc, domid, emuidmap, EMUID_DM);
 }
+
+libxl__destroy_device_model(gc, domid, emuidmap, EMUID_PV);
+
 dis->drs.ao = ao;
 dis->drs.domid = domid;
 dis->drs.callback = devices_destroy_cb;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 2bd1eb0..bcae664 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2111,20 +2111,25 @@ out:
 return rc;
 }
 
-int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
+int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid,
+unsigned emuidmap, int emuid)
 {
 int rc;
 
+if (!(emuidmap & (1u << emuid)))
+return 0;
+
 char *path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
- domid, EMUID_DM, "");
+ domid, emuid, "");
 if (!xs_rm(CTX->xsh, XBT_NULL, path))
 LOG(ERROR, "xs_rm failed for %s", path);
+
 /* We should try to destroy the device model anyway. */
 rc = kill_device_model(gc,
 GCSPRINTF("/local/domain/%d/image/device-model-pid", domid));
 if (rc)
-LOG(ERROR, "libxl__destroy_device_model failed for %d",
-domid);
+LOG(ERROR, "libxl__destroy_device_model failed for %d (emuid=%d)",
+domid, emuid);
 
 libxl__qmp_cleanup(gc, domid);
 return rc;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 0194823..4a9003d 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1656,7 +1656,8 @@ _hidden int 
libxl__wait_for_device_model_deprecated(libxl__gc *gc,
   void *userdata),
 void *check_callback_userdata);
 
-_hidden int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid);
+_hidden int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid,
+unsigned emuidmap, int emuid);
 
 _hidden const libxl_vnc_info *libxl__dm_vnc(const libxl_domain_config *g_cfg);
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 13/28] libxl: emuids: Record which emuids we have started to create

[Ian Jackson]

Record in xenstore which emulator(s) we have started.  Right now this
information is not used.

The _get_bodgeerrors function is going to be needed in several call
sites where errors are currently not handled well.  I don't want to
try to combine an error handling rework with this series.

Signed-off-by: Ian Jackson 
---
v6: New patch - storing this information here is a new approach in v6.
---
 docs/misc/xenstore-paths.markdown |5 +++
 tools/libxl/libxl_create.c|2 ++
 tools/libxl/libxl_dm.c|   61 +
 tools/libxl/libxl_internal.h  |   14 +
 4 files changed, 82 insertions(+)

diff --git a/docs/misc/xenstore-paths.markdown 
b/docs/misc/xenstore-paths.markdown
index 197bb0f..208b64b 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -505,6 +505,11 @@ The guest's virtual time offset from UTC in seconds.
 
 The device model version for a domain.
 
+ ~/libxl/$DOMID/dm-emuidmap = INTEGER
+
+Which emulator IDs are serving a domain.  This is a bitmask of
+`1upvqemu.guest_domid = 0;
 
 libxl_domain_create_info_init(&dm_config->c_info);
@@ -1801,6 +1804,9 @@ void libxl__spawn_local_dm(libxl__egc *egc, 
libxl__dm_spawn_state *dmss,
 abort();
 }
 
+rc = libxl__dm_emuidmap_add(gc, domid, state, emuid);
+if (rc) goto out;
+
 dm = libxl__domain_device_model(gc, b_info);
 if (!dm) {
 rc = ERROR_FAIL;
@@ -2417,6 +2423,61 @@ static void dm_support_check_done(libxl__egc *egc,
 ch->callback(egc, ch, rc);
 }
 
+/* emuid recording */
+
+static const char *emuidmap_path(libxl__gc *gc, int domid)
+{
+return GCSPRINTF("libxl/%d/dm-emuidmap", domid);
+}
+
+int libxl__dm_emuidmap_add(libxl__gc *gc, int domid,
+   libxl__domain_build_state *bstate, int emuid)
+{
+unsigned newflag = 1u << emuid;
+
+assert(!(bstate->emuidmap & newflag));
+bstate->emuidmap |= newflag;
+return libxl__xs_printf(gc, XBT_NULL, emuidmap_path(gc, domid),
+"%u", bstate->emuidmap);
+}
+
+int libxl__dm_emuidmap_get(libxl__gc *gc, int domid,
+   unsigned *emuidmap_r)
+{
+const char *s;
+int rc;
+
+rc = libxl__xs_read_checked(gc, XBT_NULL, emuidmap_path(gc, domid), &s);
+if (rc) goto out;
+
+if (!s) {
+*emuidmap_r = 0;
+return 0;
+}
+
+*emuidmap_r = atoi(s);
+return 0;
+
+ out:
+return rc;
+}
+
+void libxl__dm_emuidmap_get_bodgeerrors(libxl__gc *gc, int domid,
+unsigned *emuidmap_r)
+{
+int rc;
+
+rc = libxl__dm_emuidmap_get(gc, domid, emuidmap_r);
+if (rc) {
+*emuidmap_r =
+(1u << EMUID_DM) |
+(1u << EMUID_PV);
+LOG(ERROR,
+"Failed libxl_dm_emuidmap_get (rc=%d), using %#x (probably a wrong answer)",
+rc, *emuidmap_r);
+}
+}   
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 71c1e17..0194823 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1097,6 +1097,8 @@ typedef struct {
 
 char *saved_state;
 
+unsigned emuidmap;
+
 libxl__file_reference pv_kernel;
 libxl__file_reference pv_ramdisk;
 const char * pv_cmdline;
@@ -1962,6 +1964,18 @@ enum {
 /* NB stubdom and its PV service domain not recorded here */
 };
 
+_hidden int libxl__dm_emuidmap_add(libxl__gc*, int domid,
+   libxl__domain_build_state*, int emuid);
+
+_hidden int libxl__dm_emuidmap_get(libxl__gc*, int domid,
+   unsigned *emuidmap_r);
+
+_hidden void libxl__dm_emuidmap_get_bodgeerrors(libxl__gc*, int domid,
+ unsigned *emuidmap_r);
+/* *emuidmap_r is set to a default (but unreliable) value even
+ * if we get an error, which is logged.  Try to avoid calling
+ * this if you can! */
+
 _hidden char *libxl__device_model_xs_path(libxl__gc *gc,
 uint32_t dm_domid,
 uint32_t domid, int emuid,
-- 
1.7.10.4


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

[Xen-devel] [PATCH 01/28] libxl: Move FILLZERO up in libxl_internal.h

[Ian Jackson]

This means that callers in libxl_internal.h can use it (eg, inline
functions).  No functional change.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_internal.h |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a556a38..e442996 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -121,6 +121,8 @@
 #define MB(_mb) (_AC(_mb, ULL) << 20)
 #define GB(_gb) (_AC(_gb, ULL) << 30)
 
+#define FILLZERO LIBXL_FILLZERO
+
 #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
 
 #define ROUNDUP(_val, _order)   \
@@ -3545,9 +3547,6 @@ _hidden void libxl__domain_suspend_callback(void *data);
 })
 
 
-#define FILLZERO LIBXL_FILLZERO
-
-
 /*
  * All of these assume (or define)
  *libxl__gc *gc;
-- 
1.7.10.4


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

[Xen-devel] [PATCH 24/28] libxl: dm spawn records rc in state struct rather than passing as argument

[Ian Jackson]

This is going to be much more convenient in a moment, when one of the
call sites is going to want to run two in parallel.

No functional change.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl.c  |4 ++--
 tools/libxl/libxl_create.c   |   14 +++---
 tools/libxl/libxl_dm.c   |   22 +-
 tools/libxl/libxl_internal.h |5 +++--
 4 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index dff4478..3bb6d3b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4345,10 +4345,10 @@ static void device_complete(libxl__egc *egc, 
libxl__ao_device *aodev)
 libxl__nested_ao_free(aodev->ao);
 }
 
-static void qdisk_spawn_outcome(libxl__egc *egc, libxl__dm_spawn_state *dmss,
-int rc)
+static void qdisk_spawn_outcome(libxl__egc *egc, libxl__dm_spawn_state *dmss)
 {
 STATE_AO_GC(dmss->spawn.ao);
+int rc = dmss->rc;
 
 LOG(DEBUG, "qdisk backend spawn for domain %u %s", dmss->guest_domid,
rc ? "failed" : "succeed");
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index be9bb7b..e67e402 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -803,8 +803,7 @@ static void remus_checkpoint_stream_done(
 static void domcreate_dm_support_checked(libxl__egc *egc,
 libxl__dm_support_check_state *checking, int rc);
 static void domcreate_devmodel_started(libxl__egc *egc,
-   libxl__dm_spawn_state *dmss,
-   int rc);
+   libxl__dm_spawn_state *dmss);
 static void domcreate_bootloader_console_available(libxl__egc *egc,
libxl__bootloader_state 
*bl);
 static void domcreate_bootloader_done(libxl__egc *egc,
@@ -1387,8 +1386,8 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 
 if (d_config->b_info.device_model_version ==
 LIBXL_DEVICE_MODEL_VERSION_NONE) {
-domcreate_devmodel_started(egc, &dcs->dmss.dm, 0);
-return;
+dcs->dmss.dm.rc = 0;
+domcreate_devmodel_started(egc, &dcs->dmss.dm);
 }
 
 libxl_device_vkb_init(&vkb);
@@ -1440,7 +1439,8 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 return;
 } else {
 assert(!dcs->dmss.dm.guest_domid);
-domcreate_devmodel_started(egc, &dcs->dmss.dm, 0);
+dcs->dmss.dm.rc = 0;
+domcreate_devmodel_started(egc, &dcs->dmss.dm);
 return;
 }
 }
@@ -1456,11 +1456,11 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 }
 
 static void domcreate_devmodel_started(libxl__egc *egc,
-   libxl__dm_spawn_state *dmss,
-   int ret)
+   libxl__dm_spawn_state *dmss)
 {
 libxl__domain_create_state *dcs = CONTAINER_OF(dmss, *dcs, dmss.dm);
 STATE_AO_GC(dmss->spawn.ao);
+int ret = dmss->rc;
 int domid = dcs->guest_domid;
 
 /* convenience aliases */
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5e1a6cf..58760e7 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1369,8 +1369,7 @@ retry_transaction:
 }
 
 static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
-libxl__dm_spawn_state *stubdom_dmss,
-int rc);
+libxl__dm_spawn_state *stubdom_dmss);
 
 static void spawn_stub_launch_dm(libxl__egc *egc,
  libxl__multidev *aodevs, int ret);
@@ -1534,7 +1533,8 @@ retry_transaction:
 
 out:
 assert(ret);
-spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
+sdss->pvqemu.rc = ret;
+spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu);
 }
 
 static void spawn_stub_launch_dm(libxl__egc *egc,
@@ -1632,16 +1632,17 @@ static void spawn_stub_launch_dm(libxl__egc *egc,
 
 out:
 assert(ret);
-spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu, ret);
+sdss->pvqemu.rc = ret;
+spawn_stubdom_pvqemu_cb(egc, &sdss->pvqemu);
 }
 
 static void spawn_stubdom_pvqemu_cb(libxl__egc *egc,
-libxl__dm_spawn_state *stubdom_dmss,
-int rc)
+libxl__dm_spawn_state *stubdom_dmss)
 {
 libxl__stub_dm_spawn_state *sdss =
 CONTAINER_OF(stubdom_dmss, *sdss, pvqemu);
 STATE_AO_GC(sdss->dm.spawn.ao);
+int rc = stubdom_dmss->rc;
 uint32_t dm_domid = sdss->pvqemu.guest_domid;
 libxl_domain_config *d_config = stubdom_dmss->guest_config;
 
@@ -1712,7 +1713,8 @@ static void stubdom_xswait_cb(libxl__egc *egc, 
libxl__xswait_state *xswait,
 return;
  out:
 libxl__xswait_stop(gc, xswait);
-   

[Xen-devel] [PATCH 02/28] libxl: libxl_types_internal.idl: Add Emacs mode comment

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_types_internal.idl |2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/libxl/libxl_types_internal.idl 
b/tools/libxl/libxl_types_internal.idl
index 5e55685..4397141 100644
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -1,3 +1,5 @@
+# -*- python -*-
+
 namespace("libxl__")
 hidden(True)
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 16/28] libxl: emuids: Provide libxl__dm_xs_path_rel

[Ian Jackson]

This gives a relative path, suitable for driver domains.  It will be
used shortly.

No functional change.

Signed-off-by: Ian Jackson 
---
v6: New patch
---
 tools/libxl/libxl_internal.c |   10 --
 tools/libxl/libxl_internal.h |4 
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 843fdbf..d0c98b0 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -553,6 +553,12 @@ void libxl__update_domain_configuration(libxl__gc *gc,
 dst->b_info.video_memkb = src->b_info.video_memkb;
 }
 
+char *libxl__dm_xs_path_rel(libxl__gc *gc,
+uint32_t domid, int emuid)
+{
+return GCSPRINTF("device-model/%u", domid);
+}
+
 char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t dm_domid,
   uint32_t domid, int emuid,
   const char *format,  ...)
@@ -560,8 +566,8 @@ char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t 
dm_domid,
 char *s, *fmt;
 va_list ap;
 
-fmt = GCSPRINTF("/local/domain/%u/device-model/%u%s", dm_domid,
-domid, format);
+fmt = GCSPRINTF("/local/domain/%u/%s%s", dm_domid,
+libxl__dm_xs_path_rel(gc, domid, emuid), format);
 
 va_start(ap, format);
 s = libxl__vsprintf(gc, fmt, ap);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4a9003d..2248509 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1982,6 +1982,10 @@ _hidden char *libxl__device_model_xs_path(libxl__gc *gc,
 uint32_t domid, int emuid,
 const char *format, ...) PRINTF_ATTRIBUTE(5, 6);
 
+_hidden char *libxl__dm_xs_path_rel(libxl__gc *gc,
+uint32_t domid, int emuid);
+/* returns relative path (ie assuming we are the toolstack) */
+
 /*
  * Calling context and GC for event-generating functions:
  *
-- 
1.7.10.4


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

[Xen-devel] [PATCH 06/28] libxl: qemu_pci_*: Introduce DMPATH local macro, twice

[Ian Jackson]

This condenses a number of repetetive calls to
libxl__device_model_xs_path.  No functional change.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_pci.c |   24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index dc10cb7..2c7a2c6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -966,10 +966,13 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t 
domid,
 char *state, *vdevfn;
 uint32_t dm_domid;
 
+#define DMPATH(suffix) \
+libxl__device_model_xs_path(gc, dm_domid, domid, (suffix))
+
 dm_domid = libxl_get_stubdom_id(CTX, domid);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/state");
+path = DMPATH("/state");
 state = libxl__xs_read(gc, XBT_NULL, path);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/parameter");
+path = DMPATH("/parameter");
 if (pcidev->vdevfn) {
 libxl__xs_printf(gc, XBT_NULL, path, PCI_BDF_VDEVFN","PCI_OPTIONS,
  pcidev->domain, pcidev->bus, pcidev->dev,
@@ -984,9 +987,9 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t 
domid,
 libxl__qemu_traditional_cmd(gc, domid, "pci-ins");
 rc = libxl__wait_for_device_model_deprecated(gc, domid, NULL, NULL,
   pci_ins_check, state);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/parameter");
+path = DMPATH("/parameter");
 vdevfn = libxl__xs_read(gc, XBT_NULL, path);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/state");
+path = DMPATH("/state");
 if ( rc < 0 )
 LOG(ERROR, "qemu refused to add device: %s", vdevfn);
 else if ( sscanf(vdevfn, "0x%x", &pcidev->vdevfn) != 1 ) {
@@ -995,6 +998,8 @@ static int qemu_pci_add_xenstore(libxl__gc *gc, uint32_t 
domid,
 }
 xs_write(ctx->xsh, XBT_NULL, path, state, strlen(state));
 
+#undef DMPATH
+
 return rc;
 }
 
@@ -1307,9 +1312,12 @@ static int qemu_pci_remove_xenstore(libxl__gc *gc, 
uint32_t domid,
 
 dm_domid = libxl_get_stubdom_id(CTX, domid);
 
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/state");
+#define DMPATH(suffix) \
+libxl__device_model_xs_path(gc, dm_domid, domid, suffix)
+
+path = DMPATH("/state");
 state = libxl__xs_read(gc, XBT_NULL, path);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/parameter");
+path = DMPATH("/parameter");
 libxl__xs_printf(gc, XBT_NULL, path, PCI_BDF, pcidev->domain,
  pcidev->bus, pcidev->dev, pcidev->func);
 
@@ -1327,9 +1335,11 @@ static int qemu_pci_remove_xenstore(libxl__gc *gc, 
uint32_t domid,
 return ERROR_FAIL;
 }
 }
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/state");
+path = DMPATH("/state");
 xs_write(ctx->xsh, XBT_NULL, path, state, strlen(state));
 
+#undef DMPATH
+
 return 0;
 }
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 20/28] libxl: domcreate_dm_support_checked: Introduce `goto out'

[Ian Jackson]

We are going to want this shortly.

No functional change.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_create.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 71893c5..b41c6bd 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -968,10 +968,7 @@ static void domcreate_dm_support_checked(libxl__egc *egc,
 libxl_domain_config *const d_config = dcs->guest_config;
 const int restore_fd = dcs->restore_fd;
 
-if (rc) {
-domcreate_complete(egc, dcs, rc);
-return;
-}
+if (rc) goto out;
 
 dcs->bl.ao = ao;
 libxl_device_disk *bootdisk =
@@ -994,6 +991,10 @@ static void domcreate_dm_support_checked(libxl__egc *egc,
 libxl__bootloader_run(egc, &dcs->bl);
 }
 return;
+
+ out:
+domcreate_complete(egc, dcs, rc);
+return;
 }
 
 static void domcreate_bootloader_console_available(libxl__egc *egc,
-- 
1.7.10.4


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

[Xen-devel] [PATCH 15/28] libxl: emuids: Pass emuid to device model argument construction

[Ian Jackson]

No functional change yet.

Signed-off-by: Ian Jackson 
---
 tools/libxl/libxl_dm.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index bcae664..5b56047 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -752,6 +752,7 @@ static int libxl__dm_runas_helper(libxl__gc *gc, const char 
*username)
 
 static int libxl__build_device_model_args_new(libxl__gc *gc,
 const char *dm, int guest_domid,
+int emuid,
 const libxl_domain_config 
*guest_config,
 char ***args, char ***envs,
 const libxl__domain_build_state *state,
@@ -1296,6 +1297,7 @@ end_search:
 
 static int libxl__build_device_model_args(libxl__gc *gc,
 const char *dm, int guest_domid,
+int emuid,
 const libxl_domain_config 
*guest_config,
 char ***args, char ***envs,
 const libxl__domain_build_state *state,
@@ -1313,7 +1315,8 @@ static int libxl__build_device_model_args(libxl__gc *gc,
 assert(dm_state_fd != NULL);
 assert(*dm_state_fd < 0);
 return libxl__build_device_model_args_new(gc, dm,
-  guest_domid, guest_config,
+  guest_domid, emuid,
+  guest_config,
   args, envs,
   state, dm_state_fd);
 default:
@@ -1531,6 +1534,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss,
 goto out;
 
 ret = libxl__build_device_model_args(gc, "stubdom-dm", guest_domid,
+ emuid,
  guest_config, &args, NULL,
  d_state, NULL);
 if (ret) {
@@ -1817,7 +1821,7 @@ void libxl__spawn_local_dm(libxl__egc *egc, 
libxl__dm_spawn_state *dmss,
 rc = ERROR_FAIL;
 goto out;
 }
-rc = libxl__build_device_model_args(gc, dm, domid, guest_config,
+rc = libxl__build_device_model_args(gc, dm, domid, emuid, guest_config,
   &args, &envs, state,
   &dm_state_fd);
 if (rc)
-- 
1.7.10.4


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

[Xen-devel] [PATCH 23/28] libxl: dm user: Move user choice earlier, and fill in config

[Ian Jackson]

Move the dm user defaulting from libxl__build_device_model_args_new
earlier in domain create.  We now do it just after the dm support
check has finished.

Convey the result to the dm args constructor in the b_info, ie in the
supplied config.  So, the application's supplied config is filled in
with the chosen user, as for other defaults.

Also:
 - slightly improve one of the warning messages
 - change the moved code to use `rc' (following CODING_STYLE)
   rather than `ret'
 - change the moved code to use `domid' rather than `guest_domid'
   like most of the rest of domain create
 - change the name of the (static) user selection function.

Signed-off-by: Ian Jackson 
CC: Stefano Stabellini 
---
v6: New patch
---
 tools/libxl/libxl_create.c |   84 
 tools/libxl/libxl_dm.c |   62 ++--
 2 files changed, 86 insertions(+), 60 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index b41c6bd..be9bb7b 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -20,6 +20,8 @@
 #include "libxl_internal.h"
 #include "libxl_arch.h"
 
+#include 
+
 #include 
 #include 
 #include 
@@ -388,6 +390,83 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 return 0;
 }
 
+/* return 1 if the user was found, 0 if it was not, -1 on error */
+static int dm_runas_helper(libxl__gc *gc, const char *username)
+{
+struct passwd pwd, *user = NULL;
+char *buf = NULL;
+long buf_size;
+int ret;
+
+buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
+if (buf_size < 0) {
+LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
+buf_size);
+return ERROR_FAIL;
+}
+
+while (1) {
+buf = libxl__realloc(gc, buf, buf_size);
+ret = getpwnam_r(username, &pwd, buf, buf_size, &user);
+if (ret == ERANGE) {
+buf_size += 128;
+continue;
+}
+if (ret != 0)
+return ERROR_FAIL;
+if (user != NULL)
+return 1;
+return 0;
+}
+}
+
+static int domcreate_setdefault_dm_user(libxl__gc *gc,
+libxl__domain_create_state *dcs)
+{
+/* convenience aliases */
+libxl_domain_config *const d_config = dcs->guest_config;
+libxl_domain_build_info *const b_info = &d_config->b_info;
+const uint32_t domid = dcs->guest_domid;
+
+int rc;
+const char *user;
+
+if (b_info->device_model_user)
+/* already set, good-oh */
+return 0;
+
+if (!(b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
+  !libxl_defbool_val(b_info->device_model_stubdomain)))
+/* we're not going to run it anyway */
+return 0;
+
+user = GCSPRINTF("%s%d", LIBXL_QEMU_USER_BASE, domid);
+
+rc = dm_runas_helper(gc, user);
+if (rc < 0) goto error;
+if (rc > 0) goto found;
+
+user = LIBXL_QEMU_USER_SHARED;
+rc = dm_runas_helper(gc, user);
+if (rc < 0) goto error;
+if (rc > 0) {
+LOG(WARN, "Could not find user %s%d, falling back to %s",
+LIBXL_QEMU_USER_BASE, domid, LIBXL_QEMU_USER_SHARED);
+goto found;
+}
+
+LOG(WARN, "Could not find user %s%d or %s, starting QEMU as root",
+LIBXL_QEMU_USER_BASE, domid, LIBXL_QEMU_USER_SHARED);
+user = "root";
+
+ found:
+b_info->device_model_user = libxl__strdup(NOGC, user);
+return 0;
+
+ error:
+return rc;
+}
+
 static void init_console_info(libxl__gc *gc,
  libxl__device_console *console,
  int dev_num)
@@ -970,6 +1049,11 @@ static void domcreate_dm_support_checked(libxl__egc *egc,
 
 if (rc) goto out;
 
+/* config defaults which depend on dm support etc. */
+
+rc = domcreate_setdefault_dm_user(gc, dcs);
+if (rc) goto out;
+
 dcs->bl.ao = ao;
 libxl_device_disk *bootdisk =
 d_config->num_disks > 0 ? &d_config->disks[0] : NULL;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 8232981..5e1a6cf 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -21,8 +21,6 @@
 
 #include 
 #include 
-#include 
-#include 
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
@@ -728,36 +726,6 @@ libxl__detect_gfx_passthru_kind(libxl__gc *gc,
 return LIBXL_GFX_PASSTHRU_KIND_DEFAULT;
 }
 
-/* return 1 if the user was found, 0 if it was not, -1 on error */
-static int libxl__dm_runas_helper(libxl__gc *gc, const char *username)
-{
-struct passwd pwd, *user = NULL;
-char *buf = NULL;
-long buf_size;
-int ret;
-
-buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
-if (buf_size < 0) {
-LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
-buf_size);
-return ERROR_FAIL;
-}
-
-while (1) {
-buf = libxl__realloc(gc, buf, buf_size);
-ret = getpwnam_r(username, &pwd, buf, buf_size, &user);
-if (ret == ERANGE) {
-

[Xen-devel] [PATCH 25/28] libxl: emuids: Perhaps change dm xs control path

[Ian Jackson]

We are going to want to run two qemus, which will mean them having
different xs control paths.  But sometimes we will run only one qemu
to do both jobs, in which case there has to be one xs control path,
because otherwise the single qemu will only see in xenstore either the
HVM DM work to do, or the PV (eg qdisk) backend work to do.

So we need to record whether any particular domain has been set up
this way.  Use a new emuid flag bit EMUID_SPLIT which just tells us
whether we are running two qemus in this way.

If we do set this flag, we pass the emulator_id to qemu, so that qemu
and libxl agree on the xenstore path.  Obviously this depends on qemu
understanding emulator_id, but we don't check that now, because:

We do not actually ever set EMUID_SPLIT, because when we run split
qemus we also need to actually run two qemus which means a lot of
non-xs-path-related changes which are more readable in a separate
patch.

So right now there is no overall functional change.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Rewritten.
---
 docs/misc/xenstore-paths.markdown |   11 +++
 tools/libxl/libxl_dm.c|   15 +++
 tools/libxl/libxl_internal.c  |   16 +++-
 tools/libxl/libxl_internal.h  |1 +
 4 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/docs/misc/xenstore-paths.markdown 
b/docs/misc/xenstore-paths.markdown
index 3bd31af..1dc54ac 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -339,6 +339,17 @@ A PV console backend. Described in 
[console.txt](console.txt)
 Information relating to device models running in the domain. $DOMID is
 the target domain of the device model.
 
+ ~/device-model/$DOMID[/$EMULATOR_ID]/* [INTERNAL]
+
+Information relating to device models running in the domain. $DOMID is
+the target domain of the device model.
+
+$EMULATOR_ID indentifies a specific device model instance (multiple
+device model instances for the same domain are possible).  This path
+component is present only if there are (going to be) more than one
+device model for the domain.  See `/libxl/$DOMID/dm-emuidmap` and
+`EMUID_SPLIT` in `libxl_internal.h`.
+
  ~/libxl/disable_udev = ("1"|"0") []
 
 Indicates whether device hotplug scripts in this domain should be run
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 58760e7..d805800 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1236,6 +1236,11 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 flexarray_append(dm_args, "-runas");
 flexarray_append(dm_args, user);
 }
+if (state->emuidmap & (1u << EMUID_SPLIT)) {
+flexarray_append(dm_args, "-xenopts");
+flexarray_append(dm_args,
+ GCSPRINTF("emulator_id=%u", emuid));
+}
 }
 flexarray_append(dm_args, NULL);
 *args = (char **) flexarray_contents(dm_args);
@@ -1943,6 +1948,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 const char *dm;
 int logfile_w, null = -1, rc;
 uint32_t domid = dmss->guest_domid;
+unsigned emuidmap;
 
 /* Always use qemu-xen as device model */
 dm = qemu_xen_path(gc);
@@ -1958,6 +1964,15 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 flexarray_vappend(dm_args, "-monitor", "/dev/null", NULL);
 flexarray_vappend(dm_args, "-serial", "/dev/null", NULL);
 flexarray_vappend(dm_args, "-parallel", "/dev/null", NULL);
+
+rc = libxl__dm_emuidmap_get(gc, domid, &emuidmap);
+if (rc) goto error;
+
+if (emuidmap & (1u << EMUID_SPLIT)) {
+flexarray_append(dm_args, "-xenopts");
+flexarray_append(dm_args,
+GCSPRINTF("emulator_id=%u", EMUID_PV));
+}
 flexarray_append(dm_args, NULL);
 args = (char **) flexarray_contents(dm_args);
 
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index 30271c9..8dc34ad 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -556,7 +556,21 @@ void libxl__update_domain_configuration(libxl__gc *gc,
 char *libxl__dm_xs_path_rel(libxl__gc *gc,
 uint32_t domid, int emuid)
 {
-return GCSPRINTF("device-model/%u", domid);
+unsigned emuidmap;
+
+libxl__dm_emuidmap_get_bodgeerrors(gc, domid, &emuidmap);
+
+if (!(emuidmap & (1u << emuid))) {
+LOG(ERROR,
+ "Trying to find path for emulator %d but map is %#x, probable BUG",
+emuid, emuidmap);
+}
+
+if (!(emuidmap & (1u << EMUID_SPLIT))) {
+return GCSPRINTF("device-model/%u", domid);
+} else {
+return GCSPRINTF("device-model/%u/%u", domid, emuid);
+}
 }
 
 char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t dm_domid,
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 82f264a..02c35e0 100644
--- a/tools/libxl/libxl_int

[Xen-devel] [PATCH 07/28] libxl: libxl__device_model_xs_path: Add emulator_id parameter

[Ian Jackson]

We are going to want to talk to two different qemus for some domains.
This will involve a different xenstore path for the two qemus, so
libxl__device_model_xs_path will need to take a parameter to say which.

Most call sites will want to talk to the main (device model, `DM')
emulator.  So introduce that parameter now, currently always passing
EMUID_DM, which is defined in a dummy way that ensures the actual
argument is EMUID_DM.

No functional change.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Largely rewritten, but in some sense (at least conceptually)
based on a similar concept in v5.
---
 tools/libxl/libxl_device.c  |3 ++-
 tools/libxl/libxl_dm.c  |   11 ++-
 tools/libxl/libxl_dom.c |   12 +++-
 tools/libxl/libxl_dom_suspend.c |3 ++-
 tools/libxl/libxl_internal.c|4 +++-
 tools/libxl/libxl_internal.h|9 ++---
 tools/libxl/libxl_pci.c |4 ++--
 7 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 8bb5e93..22665e4 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1183,7 +1183,8 @@ int libxl__wait_for_device_model_deprecated(libxl__gc *gc,
 char *path;
 uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
 
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/state");
+path = libxl__device_model_xs_path(gc, dm_domid, domid,
+   EMUID_DM, "/state");
 return libxl__xenstore_child_wait_deprecated(gc, domid,
  LIBXL_DEVICE_MODEL_START_TIMEOUT,
  "Device Model", path, state, spawning,
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 6f5fe45..ea82e11 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1558,7 +1558,7 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
libxl__stub_dm_spawn_state *sdss)
 retry_transaction:
 t = xs_transaction_start(ctx->xsh);
 const char *dmpath = libxl__device_model_xs_path(gc,
-dm_domid, guest_domid, "");
+dm_domid, guest_domid, EMUID_DM, "");
 xs_mkdir(ctx->xsh, t, dmpath);
 xs_set_permissions(ctx->xsh, t,
dmpath,
@@ -1724,7 +1724,7 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
   dm_domid, sdss->dm.guest_domid);
 sdss->xswait.path =
 libxl__device_model_xs_path(gc, dm_domid, sdss->dm.guest_domid,
-"/state");
+EMUID_DM, "/state");
 sdss->xswait.timeout_ms = LIBXL_STUBDOM_START_TIMEOUT * 1000;
 sdss->xswait.callback = stubdom_xswait_cb;
 rc = libxl__xswait_start(gc, &sdss->xswait);
@@ -1831,7 +1831,8 @@ void libxl__spawn_local_dm(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 free(path);
 }
 
-path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID, domid, "");
+path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
+   domid, EMUID_DM, "");
 xs_mkdir(ctx->xsh, XBT_NULL, path);
 
 if (b_info->type == LIBXL_DOMAIN_TYPE_HVM &&
@@ -1886,7 +1887,7 @@ retry_transaction:
 
 spawn->what = GCSPRINTF("domain %d device model", domid);
 spawn->xspath = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
-domid, "/state");
+domid, EMUID_DM, "/state");
 spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
 spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
 spawn->midproc_cb = libxl__spawn_record_pid;
@@ -2099,7 +2100,7 @@ out:
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
 {
 char *path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
- domid, "");
+ domid, EMUID_DM, "");
 if (!xs_rm(CTX->xsh, XBT_NULL, path))
 LOG(ERROR, "xs_rm failed for %s", path);
 /* We should try to destroy the device model anyway. */
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index 47971a9..6ded9c1 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -1103,7 +1103,8 @@ int libxl__qemu_traditional_cmd(libxl__gc *gc, uint32_t 
domid,
 {
 char *path = NULL;
 uint32_t dm_domid = libxl_get_stubdom_id(CTX, domid);
-path = libxl__device_model_xs_path(gc, dm_domid, domid, "/command");
+path = libxl__device_model_xs_path(gc, dm_domid,
+   domid, EMUID_DM, "/command");
 return libxl__xs_printf(gc, XBT_NULL, path, "%s", cmd);
 }
 
@@ -1134,7 +1135,8 @@ int 
libxl__restore_emulator_xenstore_data(libxl__domain_create_state *dcs,
 
 const uint32_t domid = dcs->guest_domid;
 const uint32_t dm_domid = libxl_get_stubdom_id(CTX, dom

[Xen-devel] [PATCH 18/28] libxl: emuids: Change pid path in xenstore

[Ian Jackson]

Introduce libxl__dm_xs_pid_path and use it everywhere.

There is no overall functional change, although there is a change to
these internal paths.  Also, the paths used are now relative (ie to
/local/domain/) rather than absolute.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Rewritten, actual paths changed, patch title changed
v4: Update xenstore-paths.markdown
---
 docs/misc/xenstore-paths.markdown |   10 +++---
 tools/libxl/libxl_dm.c|   11 +--
 tools/libxl/libxl_internal.c  |6 ++
 tools/libxl/libxl_internal.h  |3 +++
 4 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/docs/misc/xenstore-paths.markdown 
b/docs/misc/xenstore-paths.markdown
index 208b64b..3bd31af 100644
--- a/docs/misc/xenstore-paths.markdown
+++ b/docs/misc/xenstore-paths.markdown
@@ -143,11 +143,6 @@ The guests name.
 
 The domain's own ID.
 
- ~/image/device-model-pid = INTEGER   [INTERNAL]
-
-The process ID of the device model associated with this domain, if it
-has one.
-
  ~/cpu/[0-9]+/availability = ("online"|"offline") [PV]
 
 One node for each virtual CPU up to the guest's configured
@@ -463,9 +458,10 @@ in the value supplied by the guest in this case).
 
 Contains the status of the device models running on the domain.
 
- ~/libxl/$DOMID/qdisk-backend-pid [w]
+ ~/libxl/$DOMID/dm-pid-$EMUID [w] = INTEGER   [INTERNAL]
 
-Contains the PIDs of the device models running on the domain.
+Contains the PIDs of the device models running on this domain, to
+service $DOMID.
 
 ## Virtual Machine Paths
 
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 3bf1317..6b0bbed 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1867,7 +1867,7 @@ void libxl__spawn_local_dm(libxl__egc *egc, 
libxl__dm_spawn_state *dmss,
 }
 
 const char *dom_path = libxl__xs_get_dompath(gc, domid);
-spawn->pidpath = GCSPRINTF("%s/%s", dom_path, "image/device-model-pid");
+spawn->pidpath = libxl__dm_xs_pid_path(gc, domid, emuid);
 
 if (vnc && vnc->passwd) {
 /* This xenstore key will only be used by qemu-xen-traditionnal.
@@ -1901,7 +1901,7 @@ retry_transaction:
 spawn->xspath = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
 domid, emuid, "/state");
 spawn->timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
-spawn->pidpath = GCSPRINTF("%s/image/device-model-pid", dom_path);
+spawn->pidpath = libxl__dm_xs_pid_path(gc, domid, emuid);
 spawn->midproc_cb = libxl__spawn_record_pid;
 spawn->confirm_cb = device_model_confirm;
 spawn->failure_cb = device_model_startup_failed;
@@ -2036,7 +2036,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
  * because we will call this from unprivileged driver domains,
  * so save it in the current domain libxl private dir.
  */
-dmss->spawn.pidpath = GCSPRINTF("libxl/%u/qdisk-backend-pid", domid);
+dmss->spawn.pidpath = libxl__dm_xs_pid_path(gc, domid, EMUID_PV);
 dmss->spawn.midproc_cb = libxl__spawn_record_pid;
 dmss->spawn.confirm_cb = device_model_confirm;
 dmss->spawn.failure_cb = device_model_startup_failed;
@@ -2101,7 +2101,7 @@ int libxl__destroy_qdisk_backend(libxl__gc *gc, uint32_t 
domid)
 char *pid_path;
 int rc;
 
-pid_path = GCSPRINTF("libxl/%u/qdisk-backend-pid", domid);
+pid_path = libxl__dm_xs_pid_path(gc, domid, EMUID_PV);
 
 rc = kill_device_model(gc, pid_path);
 if (rc)
@@ -2129,8 +2129,7 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t 
domid,
 LOG(ERROR, "xs_rm failed for %s", path);
 
 /* We should try to destroy the device model anyway. */
-rc = kill_device_model(gc,
-GCSPRINTF("/local/domain/%d/image/device-model-pid", domid));
+rc = kill_device_model(gc, libxl__dm_xs_pid_path(gc, domid, emuid));
 if (rc)
 LOG(ERROR, "libxl__destroy_device_model failed for %d (emuid=%d)",
 domid, emuid);
diff --git a/tools/libxl/libxl_internal.c b/tools/libxl/libxl_internal.c
index d0c98b0..30271c9 100644
--- a/tools/libxl/libxl_internal.c
+++ b/tools/libxl/libxl_internal.c
@@ -576,6 +576,12 @@ char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t 
dm_domid,
 return s;
 }
 
+char *libxl__dm_xs_pid_path(libxl__gc *gc, int guest_domid, int emuid)
+{
+return GCSPRINTF("libxl/%d/dm-pid-%d", guest_domid, emuid);
+}
+
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2248509..350ec29 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1986,6 +1986,9 @@ _hidden char *libxl__dm_xs_path_rel(libxl__gc *gc,
 uint32_t domid, int emuid);
 /* returns relative path (ie assuming we are the toolstack) */
 
+_hidden char *libxl__dm_xs_pid_path(libxl__gc *gc,
+int gu

[Xen-devel] [PATCH 09/28] libxl: Move some error handling and cleanup into libxl__destroy_device_model

[Ian Jackson]

Move
 - the error log message
 - the call to libxl__qmp_cleanup
into libxl__destroy_device_model from the one call site in
libxl__destroy_domid.

We are going to want to call libxl__destroy_device_model more than
once, and this code would otherwise need to be repeated for the other
call site(s).

The call site now completely ignores the error, sadly.  But I am not
intending in this series to try to undertake destruction
error-handling cleanup as well.

No functional change other than slight change to the error message.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl.c|4 +---
 tools/libxl/libxl_dm.c |   10 +-
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1ac5d81..5414649 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1653,10 +1653,8 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
 }
 
 if (dm_present) {
-if (libxl__destroy_device_model(gc, domid) < 0)
-LOG(ERROR, "libxl__destroy_device_model failed for %d", domid);
+libxl__destroy_device_model(gc, domid);
 
-libxl__qmp_cleanup(gc, domid);
 }
 dis->drs.ao = ao;
 dis->drs.domid = domid;
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index ea82e11..b85b377 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2099,13 +2099,21 @@ out:
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid)
 {
+int rc;
+
 char *path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
  domid, EMUID_DM, "");
 if (!xs_rm(CTX->xsh, XBT_NULL, path))
 LOG(ERROR, "xs_rm failed for %s", path);
 /* We should try to destroy the device model anyway. */
-return kill_device_model(gc,
+rc = kill_device_model(gc,
 GCSPRINTF("/local/domain/%d/image/device-model-pid", domid));
+if (rc)
+LOG(ERROR, "libxl__destroy_device_model failed for %d",
+domid);
+
+libxl__qmp_cleanup(gc, domid);
+return rc;
 }
 
 int libxl__need_xenpv_qemu(libxl__gc *gc,
-- 
1.7.10.4


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

[Xen-devel] [PATCH 19/28] libxl: Improve libxl__destroy_device_model

[Ian Jackson]

Take some improvements from libxl__destroy_qdisk_backend:
* Use libxl__xs_rm_checked rather than xs_rm
* Remove the pid from xenstore

Then libxl__destroy_qdisk_backend can be made into a simple wrapper
around libxl__destroy_device_model.

Signed-off-by: Ian Jackson 
---
v6: New patch.
---
 tools/libxl/libxl_dm.c |   27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 6b0bbed..886ed9c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2098,21 +2098,12 @@ out:
 /* Helper to destroy a Qdisk backend */
 int libxl__destroy_qdisk_backend(libxl__gc *gc, uint32_t domid)
 {
-char *pid_path;
-int rc;
-
-pid_path = libxl__dm_xs_pid_path(gc, domid, EMUID_PV);
+unsigned emuidmap;
 
-rc = kill_device_model(gc, pid_path);
-if (rc)
-goto out;
+libxl__dm_emuidmap_get(gc, domid, &emuidmap);
+/* better to blunder on if this fails */
 
-libxl__xs_rm_checked(gc, XBT_NULL, pid_path);
-libxl__xs_rm_checked(gc, XBT_NULL,
- libxl__dm_xs_path_rel(gc, domid, EMUID_PV));
-
-out:
-return rc;
+return libxl__destroy_device_model(gc, domid, emuidmap, EMUID_PV);
 }
 
 int libxl__destroy_device_model(libxl__gc *gc, uint32_t domid,
@@ -2123,16 +2114,16 @@ int libxl__destroy_device_model(libxl__gc *gc, uint32_t 
domid,
 if (!(emuidmap & (1u << emuid)))
 return 0;
 
-char *path = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
- domid, emuid, "");
-if (!xs_rm(CTX->xsh, XBT_NULL, path))
-LOG(ERROR, "xs_rm failed for %s", path);
+const char *control_path = libxl__dm_xs_path_rel(gc, domid, emuid);
+libxl__xs_rm_checked(gc, XBT_NULL, control_path);
 
 /* We should try to destroy the device model anyway. */
-rc = kill_device_model(gc, libxl__dm_xs_pid_path(gc, domid, emuid));
+const char *pid_path = libxl__dm_xs_pid_path(gc, domid, emuid);
+rc = kill_device_model(gc, pid_path);
 if (rc)
 LOG(ERROR, "libxl__destroy_device_model failed for %d (emuid=%d)",
 domid, emuid);
+libxl__xs_rm_checked(gc, XBT_NULL, pid_path);
 
 libxl__qmp_cleanup(gc, domid);
 return rc;
-- 
1.7.10.4


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

[Xen-devel] [PATCH 22/28] libxl: dm user: Document the default

[Ian Jackson]

Signed-off-by: Ian Jackson 
CC: Stefano Stabellini 
---
v6: New patch
---
 docs/man/xl.cfg.pod.5 |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 8899f75..dd93725 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1839,7 +1839,8 @@ option to the device-model.
 =item B
 
 Run the device model as user "username", instead of
-xen-qemudepriv-domid$domid or xen-qemudepriv-shared or root.
+xen-qemudepriv-domid$domid or xen-qemudepriv-shared or root.  The
+default is to use the first of these users which exists.
 
 =back
 
-- 
1.7.10.4


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

[Xen-devel] [PATCH 12/28] libxl: Use libxl__device_model_xs_path in libxl__spawn_qdisk_backend

[Ian Jackson]

Rather than open-coding the answer.  We are going to change this path.

No functional change (other than to very unlikely error paths).

Signed-off-by: Stefano Stabellini 
Signed-off-by: Ian Jackson 
---
v6: Broken out from a portmanteau patch which was in v5, and fixed.
---
 tools/libxl/libxl_dm.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 1e1dfa0..916d12c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2018,7 +2018,8 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc, 
libxl__dm_spawn_state *dmss)
 dmss->build_state->saved_state = 0;
 
 dmss->spawn.what = GCSPRINTF("domain %u Qdisk backend", domid);
-dmss->spawn.xspath = GCSPRINTF("device-model/%u/state", domid);
+dmss->spawn.xspath = libxl__device_model_xs_path(gc, LIBXL_TOOLSTACK_DOMID,
+ domid, EMUID_PV, 
"/state");
 dmss->spawn.timeout_ms = LIBXL_DEVICE_MODEL_START_TIMEOUT * 1000;
 /*
  * We cannot save Qemu pid anywhere in the xenstore guest dir,
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH v2 4/8] xen: arm: remove vgic_vcpu_inject_spi()

[Stefano Stabellini]

On Tue, 10 Nov 2015, Ian Campbell wrote:
> Currently this has only a single caller, which I intend to teach about
> injecting PPIs shortly. This helper doesn't add much so remove it.
> 
> Drop a stray tab from the comment immediately preceding this change.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  xen/arch/arm/irq.c |  7 +--
>  xen/arch/arm/vgic.c| 11 ---
>  xen/include/asm-arm/vgic.h |  1 -
>  3 files changed, 5 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 6918438..5b073d1 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -214,6 +214,7 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
> int is_fiq)
>  if ( test_bit(_IRQ_GUEST, &desc->status) )
>  {
>  struct irq_guest *info = irq_get_guest_info(desc);
> +struct vcpu *v;
>  
>  perfc_incr(guest_irqs);
>  desc->handler->end(desc);
> @@ -223,8 +224,10 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int 
> irq, int is_fiq)
>  /*
>   * The irq cannot be a PPI, we only support delivery of SPIs to
>   * guests.
> -  */
> -vgic_vcpu_inject_spi(info->d, info->virq);
> + */
> +v = vgic_get_target_vcpu(info->d->vcpu[0], info->virq);
> +vgic_vcpu_inject_irq(v, info->virq);
> +
>  goto out_no_end;
>  }
>  
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 7bb4570..7a76f00 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -477,17 +477,6 @@ out:
>  }
>  }
>  
> -void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq)
> -{
> -struct vcpu *v;
> -
> -/* the IRQ needs to be an SPI */
> -ASSERT(virq >= 32 && virq <= vgic_num_irqs(d));
> -
> -v = vgic_get_target_vcpu(d->vcpu[0], virq);
> -vgic_vcpu_inject_irq(v, virq);
> -}
> -
>  void arch_evtchn_inject(struct vcpu *v)
>  {
>  vgic_vcpu_inject_irq(v, v->domain->arch.evtchn_irq);
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 7d580cc..aa675cb 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -207,7 +207,6 @@ extern void domain_vgic_free(struct domain *d);
>  extern int vcpu_vgic_init(struct vcpu *v);
>  extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, unsigned int irq);
>  extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
> -extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
>  extern void vgic_clear_pending_irqs(struct vcpu *v);
>  extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
>  extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int 
> irq);
> -- 
> 2.1.4
> 

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

[Xen-devel] Lenovo X200 IOMMU support through Xen 4.6 iommu=no-igfx switch

[Thierry Laurion]

Hi all,

iommu=no-igfx is a gamechanger for Qubes support through 3.1 RC1 release,
thanks to Xen 4.6 :)

The Lenovo X200 supports vt-x, vt-d and TPM as reported and required by
Qubes in the HCL attached to this e-mail. The problem is that when Qubes
launches it's netvm which uses IOMMU to talk to it's network card, it
freezes the whole system up. Even when specifying sync_console, I don't get
much more verbosity. I ordered a PCMCIA to serial adapter which will be
shipped to my door late January... Meanwhile, booting with iommu=0 makes
things work, but a potential hardware component being compromised has
chances to compromise the whole system since compartmentalization is not
guaranteed without IOMMU (vt-d).

A little more love is needed from xen to make that laptop line supported by
Qubes and a nice alternative to the costy Librem currently promoted by
Qubes-Purism
partnership
which
suggest that the laptop will be Respect Your Freedom compliant in the
future with Intel participation in removing ME and AMT
, which is not guaranteed at all.

If Xen 4.6 can cooperate with Penryn GM45 chipset, it's all MiniFree laptops
 (and Libreboot support of
those ) that will be potential
candidates!
Please share the love so that the community has a cheap alternative.

Requirements to replicate bug:
Model: X200 745434U with p8700 CPU running 1067a microcode(important),
upgrable to 8go
BIOS: Lenovo 3.22/1.07 (latest from 2013
)
Network card supports FLReset+ as requested here
.
Bios settings: vt-d and vt-x needs to be enforced.
Xen command line option required
 to boot:
iommu=no-igfx

Here is the current debug trace/status on Qubes side of things
.
If you have any hint, please contribute :)

Help me say happy new years to all security conscious people out there :)

Merry Christmas all,
Thierry Laurion





-- 
Thierry Laurion


Qubes-HCL-LENOVO-745434U-20151212-193925.yml
Description: application/yaml


x200_vtd_works_on_latest_bios_with_no-igfx
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.16 test] 66834: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 64969

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   5 xen-installfail in 66479 pass in 66834
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 66479

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 64969
 test-armhf-armhf-libvirt-raw  9 debian-di-install fail in 66479 like 64969
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail in 66479 like 64969
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 66479 like 64969
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10   fail   like 64969
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 64969

Tests which did not succeed, but are not blocking:
 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-xl-multivcpu 17 guest-localmigrate/x10   fail  never pass
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10   fail   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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-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-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail 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-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass

version targeted for testing:
 linux70a95b3e395fa9f5a5cf531c56ae7e5b6ed37e32
baseline version:
 linuxa11efd7b42bf716f528b4f163cd86ba1e499354a

Last test of basis64969  2015-11-20 22:00:18 Z   31 days
Testing same since66400  2015-12-15 18:22:25 Z6 days6 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alexandra Yates 
  Alexandre Belloni 
  Amitkumar Karwar 
  Andrew Morton 
  Andrey Ryabinin 
  Andrzej Hajda 
  Andy Leiserson 
  Andy Shevchenko 
  Ani Sinha 
  Anna Schumaker 
  Arik Nemtsov 
  Arik Nemtsov 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian Norris 
  Catalin Marinas 
  Chen Yu 
  Christian Borntraeger 
  Christoph Hellwig 
  

Re: [Xen-devel] [PATCH RFC 11/31] xen/x86: Calculate Raw featureset

[Andrew Cooper]

On 22/12/15 17:14, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> Calculate and expose the raw featureset to userspace.  This is for
>> informational purposes; the difference between the raw and the host
>> featuresets are the features Xen has specifically chosen not to use.
> And what use is this? Looks like dead code to me...

It is specifically needed by XenServers toolstack to safely import VMs
from older versions.  I expect the same will be true for any other
toolstack which attempted to do multi-host levelling, although libxl
doesn't need it because it doesn't even pretend do to levelling.

It turns out that it is also needed to correct the AMD SEP check in
patch 10.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 10/31] xen/x86: Calculate HVM featureset

[Andrew Cooper]

On 22/12/15 17:11, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> @@ -22,6 +24,27 @@ void __init calculate_featuresets(void)
>>  
>>  /* Unconditionally claim to be able to set the hypervisor bit. */
>>  __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
>> +
>> +/* HVM featureset. */
>> +if ( hvm_enabled )
>> +{
>> +const uint32_t *hvm_featuremask = hvm_funcs.hap_supported
>> +? hvm_hap_featuremask : hvm_shadow_featuremask;
>> +
>> +for ( i = 0; i < ARRAY_SIZE(hvm_featureset); ++i )
>> +hvm_featureset[i] = host_featureset[i] & hvm_featuremask[i];
>> +
>> +/* Unconditionally claim to be able to set the hypervisor bit. */
>> +__set_bit(X86_FEATURE_HYPERVISOR, hvm_featureset);
>> +
>> +/*
>> + * On AMD, PV guests are entirely unable to use 'sysenter' as Xen 
>> runs
>> + * in long mode, but HVM guests are able if running in protected 
>> mode.
>> + */
>> +if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
>> + !test_bit(X86_FEATURE_SEP, boot_cpu_data.x86_capability) )
> Is the ! correct here?

Yes - init_amd() deliberately clobbers the feature.

> And please use cpu_has_sep.

Actually, thinking about it, the check isn't quite correct.  We need to
only advertise the feature if it was available before init_amd()
clobbered it.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 09/31] xen/x86: Calculate PV featureset

[Jan Beulich]

>>> On 22.12.15 at 18:13,  wrote:
> On 22/12/15 17:07, Jan Beulich wrote:
> On 16.12.15 at 22:24,  wrote:
>>> --- a/xen/arch/x86/cpuid/cpuid.c
>>> +++ b/xen/arch/x86/cpuid/cpuid.c
>>> @@ -102,7 +102,11 @@ const uint32_t 
>>> known_features[XEN_NR_FEATURESET_ENTRIES] 
> =
>>>  cpufeat_mask(X86_FEATURE_CAT)  
>>>  
>  |
>>>  
> cpufeat_mask(X86_FEATURE_RDSEED) |
>>>  cpufeat_mask(X86_FEATURE_ADX)  
>>>  
>  |
>>> -
>>> cpufeat_mask(X86_FEATURE_SMAP)),
>>> +cpufeat_mask(X86_FEATURE_SMAP) 
>>>  
>  |
>>> +
> cpufeat_mask(X86_FEATURE_PCOMMIT)|
>>> +
> cpufeat_mask(X86_FEATURE_CLFLUSHOPT) |
>>> +cpufeat_mask(X86_FEATURE_CLWB) 
>>>  
>  |
>>> +cpufeat_mask(X86_FEATURE_SHA)),
>>>  
>>>  [cpufeat_word(X86_FEATURE_PREFETCHWT1)] = 
> (cpufeat_mask(X86_FEATURE_PREFETCHWT1)),
>>>  
>>> @@ -116,6 +120,101 @@ const uint32_t 
> inverted_features[XEN_NR_FEATURESET_ENTRIES] =
>>>  [cpufeat_word(X86_FEATURE_FPU_SEL)] = 
> cpufeat_mask(X86_FEATURE_FPU_SEL),
>>>  };
>>>  
>>> +#define PV_FEATUREMASK_1d   \
>>> +(cpufeat_mask(X86_FEATURE_FPU)| \
>>> + cpufeat_mask(X86_FEATURE_DE) | \
>>> + cpufeat_mask(X86_FEATURE_TSC)| \
>>> + cpufeat_mask(X86_FEATURE_MSR)| \
>>> + cpufeat_mask(X86_FEATURE_PAE)| \
>>> + cpufeat_mask(X86_FEATURE_MCE)| \
>>> + cpufeat_mask(X86_FEATURE_CX8)| \
>>> + cpufeat_mask(X86_FEATURE_APIC)   | \
>>> + cpufeat_mask(X86_FEATURE_SEP)| \
>>> + cpufeat_mask(X86_FEATURE_MCA)| \
>>> + cpufeat_mask(X86_FEATURE_CMOV)   | \
>>> + cpufeat_mask(X86_FEATURE_PAT)| \
>>> + cpufeat_mask(X86_FEATURE_CLFLSH) | \
>>> + cpufeat_mask(X86_FEATURE_ACPI)   | \
>>> + cpufeat_mask(X86_FEATURE_MMX)| \
>>> + cpufeat_mask(X86_FEATURE_FXSR)   | \
>>> + cpufeat_mask(X86_FEATURE_XMM)| \
>>> + cpufeat_mask(X86_FEATURE_XMM2))
>>> +
>>> +#define PV_FEATUREMASK_1c   \
>>> +(cpufeat_mask(X86_FEATURE_XMM3)  |  \
>>> + cpufeat_mask(X86_FEATURE_PCLMULQDQ) |  \
>>> + cpufeat_mask(X86_FEATURE_SSSE3) |  \
>>> + cpufeat_mask(X86_FEATURE_FMA)   |  \
>>> + cpufeat_mask(X86_FEATURE_CX16)  |  \
>>> + cpufeat_mask(X86_FEATURE_SSE4_1)|  \
>>> + cpufeat_mask(X86_FEATURE_SSE4_2)|  \
>>> + cpufeat_mask(X86_FEATURE_X2APIC)|  \
>>> + cpufeat_mask(X86_FEATURE_MOVBE) |  \
>>> + cpufeat_mask(X86_FEATURE_POPCNT)|  \
>>> + cpufeat_mask(X86_FEATURE_AES)   |  \
>>> + cpufeat_mask(X86_FEATURE_XSAVE) |  \
>>> + cpufeat_mask(X86_FEATURE_AVX)   |  \
>>> + cpufeat_mask(X86_FEATURE_F16C)  |  \
>>> + cpufeat_mask(X86_FEATURE_RDRAND)|  \
>>> + cpufeat_mask(X86_FEATURE_HYPERVISOR))
>>> +
>>> +#define PV_FEATUREMASK_e1d  \
>>> +((PV_FEATUREMASK_1d & SHARED_1d)|   \
>>> + cpufeat_mask(X86_FEATURE_SYSCALL)  |   \
>>> + cpufeat_mask(X86_FEATURE_MP)   |   \
>>> + cpufeat_mask(X86_FEATURE_NX)   |   \
>>> + cpufeat_mask(X86_FEATURE_MMXEXT)   |   \
>>> + cpufeat_mask(X86_FEATURE_FFXSR)|   \
>>> + cpufeat_mask(X86_FEATURE_LM)   |   \
>>> + cpufeat_mask(X86_FEATURE_3DNOWEXT) |   \
>>> + cpufeat_mask(X86_FEATURE_3DNOW))
>>> +
>>> +#define PV_FEATUREMASK_e1c  \
>>> +(cpufeat_mask(X86_FEATURE_LAHF_LM)   |  \
>>> + cpufeat_mask(X86_FEATURE_ABM)   |  \
>>> + cpufeat_mask(X86_FEATURE_SSE4A) |  \
>>> + cpufeat_mask(X86_FEATURE_MISALIGNSSE)   |  \
>>> + cpufeat_mask(X86_FEATURE_3DNOWPREFETCH) |  \
>>> + cpufeat_mask(X86_FEATURE_XOP)   |  \
>>> + cpufeat_mask(X86_FEATURE_LWP)   |  \
>>> + cpufeat_mask(X86_FEATURE_FMA4)  |  \
>>> + cpufeat_mask(X86_FEATURE_TBM)   |  \
>>> + cpufeat_mask(X86_FEATURE_DBEXT))
>>> +
>>> +#define PV_FEATUREMASK_Da1  \
>>> +(cpufeat_mask(X86_FEATURE_XSAVEOPT) |   \
>>> + cpufeat_mask(X86_FEATURE_XSAVEC)   |   \
>>> + cpufeat_mask(X86_FEATURE_XGETBV1))
>>> +
>>> +#define PV_FEATUREMASK_7b0  \
>>> +(cpufeat_mask(X86_FEATURE_FSGSBASE)   | \
>>> + cpufeat_mask(X86_FEATURE_BMI1)   | \
>>> + cpufeat_mask(X86_FEATURE_HLE)| \
>>> + cpufeat_mask(X86_FEATURE_AVX2)   |  

Re: [Xen-devel] [PATCH RFC 05/31] xen/x86: Collect more CPUID feature words

[Andrew Cooper]

On 22/12/15 16:46, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -481,7 +481,7 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>>  
>>  if (c->extended_cpuid_level >= 0x8007) {
>>  c->x86_power = cpuid_edx(0x8007);
>> -if (c->x86_power & (1<<8)) {
>> +if (c->x86_power & cpufeat_mask(X86_FEATURE_ITSC)) {
> generic_identify() has already run by the time we get here, so no
> need to re-read cpuid_edx() (interestingly enough you leverage
> this in init_intel()).

I didn't change either in this regard (observe that it is just in
context), although it is now obvious that x86_power can be dropped
completely, given that isn't used anywhere else.

andrewcoop@andrewcoop:/local/xen.git/xen$ git grep x86_power
arch/x86/cpu/amd.c:541: c->x86_power = cpuid_edx(0x8007);
arch/x86/cpu/amd.c:542: if (c->x86_power &
cpufeat_mask(X86_FEATURE_ITSC)) {
include/asm-x86/processor.h:194:int  x86_power;


>
>> --- a/xen/arch/x86/cpuid/cpuid.c
>> +++ b/xen/arch/x86/cpuid/cpuid.c
>> @@ -103,6 +103,12 @@ const uint32_t 
>> known_features[XEN_NR_FEATURESET_ENTRIES] =
>>  
>> cpufeat_mask(X86_FEATURE_RDSEED) |
>>  cpufeat_mask(X86_FEATURE_ADX)   
>>  |
>>  cpufeat_mask(X86_FEATURE_SMAP)),
>> +
>> +[cpufeat_word(X86_FEATURE_PREFETCHWT1)] = 
>> (cpufeat_mask(X86_FEATURE_PREFETCHWT1)),
>> +
>> +[cpufeat_word(X86_FEATURE_ITSC)] = (cpufeat_mask(X86_FEATURE_ITSC)),
>> +
>> +[cpufeat_word(X86_FEATURE_CLZERO)] = (cpufeat_mask(X86_FEATURE_CLZERO)),
>>  };
> Are these indeed the only ones in their groups that can be safely
> marked "known"?

I am going to go out on a limb and say yes here.  The point of "known"
is "someone has actively thought about what the hyperivsor implications
of using this feature is".  These are the only ones which I feel safe
declaring to be such at the time of writing.

Rebasing onto staging has introduced the PKU bits, which are adjacent to
PREFETCHWT1, and altered this patch quite a lot.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 11/31] xen/x86: Calculate Raw featureset

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> Calculate and expose the raw featureset to userspace.  This is for
> informational purposes; the difference between the raw and the host
> featuresets are the features Xen has specifically chosen not to use.

And what use is this? Looks like dead code to me...

Jan


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

Re: [Xen-devel] [PATCH RFC 09/31] xen/x86: Calculate PV featureset

[Andrew Cooper]

On 22/12/15 17:07, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> --- a/xen/arch/x86/cpuid/cpuid.c
>> +++ b/xen/arch/x86/cpuid/cpuid.c
>> @@ -102,7 +102,11 @@ const uint32_t 
>> known_features[XEN_NR_FEATURESET_ENTRIES] =
>>  cpufeat_mask(X86_FEATURE_CAT)   
>>  |
>>  
>> cpufeat_mask(X86_FEATURE_RDSEED) |
>>  cpufeat_mask(X86_FEATURE_ADX)   
>>  |
>> -cpufeat_mask(X86_FEATURE_SMAP)),
>> +cpufeat_mask(X86_FEATURE_SMAP)  
>>  |
>> +
>> cpufeat_mask(X86_FEATURE_PCOMMIT)|
>> +
>> cpufeat_mask(X86_FEATURE_CLFLUSHOPT) |
>> +cpufeat_mask(X86_FEATURE_CLWB)  
>>  |
>> +cpufeat_mask(X86_FEATURE_SHA)),
>>  
>>  [cpufeat_word(X86_FEATURE_PREFETCHWT1)] = 
>> (cpufeat_mask(X86_FEATURE_PREFETCHWT1)),
>>  
>> @@ -116,6 +120,101 @@ const uint32_t 
>> inverted_features[XEN_NR_FEATURESET_ENTRIES] =
>>  [cpufeat_word(X86_FEATURE_FPU_SEL)] = cpufeat_mask(X86_FEATURE_FPU_SEL),
>>  };
>>  
>> +#define PV_FEATUREMASK_1d   \
>> +(cpufeat_mask(X86_FEATURE_FPU)| \
>> + cpufeat_mask(X86_FEATURE_DE) | \
>> + cpufeat_mask(X86_FEATURE_TSC)| \
>> + cpufeat_mask(X86_FEATURE_MSR)| \
>> + cpufeat_mask(X86_FEATURE_PAE)| \
>> + cpufeat_mask(X86_FEATURE_MCE)| \
>> + cpufeat_mask(X86_FEATURE_CX8)| \
>> + cpufeat_mask(X86_FEATURE_APIC)   | \
>> + cpufeat_mask(X86_FEATURE_SEP)| \
>> + cpufeat_mask(X86_FEATURE_MCA)| \
>> + cpufeat_mask(X86_FEATURE_CMOV)   | \
>> + cpufeat_mask(X86_FEATURE_PAT)| \
>> + cpufeat_mask(X86_FEATURE_CLFLSH) | \
>> + cpufeat_mask(X86_FEATURE_ACPI)   | \
>> + cpufeat_mask(X86_FEATURE_MMX)| \
>> + cpufeat_mask(X86_FEATURE_FXSR)   | \
>> + cpufeat_mask(X86_FEATURE_XMM)| \
>> + cpufeat_mask(X86_FEATURE_XMM2))
>> +
>> +#define PV_FEATUREMASK_1c   \
>> +(cpufeat_mask(X86_FEATURE_XMM3)  |  \
>> + cpufeat_mask(X86_FEATURE_PCLMULQDQ) |  \
>> + cpufeat_mask(X86_FEATURE_SSSE3) |  \
>> + cpufeat_mask(X86_FEATURE_FMA)   |  \
>> + cpufeat_mask(X86_FEATURE_CX16)  |  \
>> + cpufeat_mask(X86_FEATURE_SSE4_1)|  \
>> + cpufeat_mask(X86_FEATURE_SSE4_2)|  \
>> + cpufeat_mask(X86_FEATURE_X2APIC)|  \
>> + cpufeat_mask(X86_FEATURE_MOVBE) |  \
>> + cpufeat_mask(X86_FEATURE_POPCNT)|  \
>> + cpufeat_mask(X86_FEATURE_AES)   |  \
>> + cpufeat_mask(X86_FEATURE_XSAVE) |  \
>> + cpufeat_mask(X86_FEATURE_AVX)   |  \
>> + cpufeat_mask(X86_FEATURE_F16C)  |  \
>> + cpufeat_mask(X86_FEATURE_RDRAND)|  \
>> + cpufeat_mask(X86_FEATURE_HYPERVISOR))
>> +
>> +#define PV_FEATUREMASK_e1d  \
>> +((PV_FEATUREMASK_1d & SHARED_1d)|   \
>> + cpufeat_mask(X86_FEATURE_SYSCALL)  |   \
>> + cpufeat_mask(X86_FEATURE_MP)   |   \
>> + cpufeat_mask(X86_FEATURE_NX)   |   \
>> + cpufeat_mask(X86_FEATURE_MMXEXT)   |   \
>> + cpufeat_mask(X86_FEATURE_FFXSR)|   \
>> + cpufeat_mask(X86_FEATURE_LM)   |   \
>> + cpufeat_mask(X86_FEATURE_3DNOWEXT) |   \
>> + cpufeat_mask(X86_FEATURE_3DNOW))
>> +
>> +#define PV_FEATUREMASK_e1c  \
>> +(cpufeat_mask(X86_FEATURE_LAHF_LM)   |  \
>> + cpufeat_mask(X86_FEATURE_ABM)   |  \
>> + cpufeat_mask(X86_FEATURE_SSE4A) |  \
>> + cpufeat_mask(X86_FEATURE_MISALIGNSSE)   |  \
>> + cpufeat_mask(X86_FEATURE_3DNOWPREFETCH) |  \
>> + cpufeat_mask(X86_FEATURE_XOP)   |  \
>> + cpufeat_mask(X86_FEATURE_LWP)   |  \
>> + cpufeat_mask(X86_FEATURE_FMA4)  |  \
>> + cpufeat_mask(X86_FEATURE_TBM)   |  \
>> + cpufeat_mask(X86_FEATURE_DBEXT))
>> +
>> +#define PV_FEATUREMASK_Da1  \
>> +(cpufeat_mask(X86_FEATURE_XSAVEOPT) |   \
>> + cpufeat_mask(X86_FEATURE_XSAVEC)   |   \
>> + cpufeat_mask(X86_FEATURE_XGETBV1))
>> +
>> +#define PV_FEATUREMASK_7b0  \
>> +(cpufeat_mask(X86_FEATURE_FSGSBASE)   | \
>> + cpufeat_mask(X86_FEATURE_BMI1)   | \
>> + cpufeat_mask(X86_FEATURE_HLE)| \
>> + cpufeat_mask(X86_FEATURE_AVX2)   | \
>> + cpufeat_mask(X86_FEATURE_BMI2)   | \
>> + cpufeat_mask(X86_FEATURE_ERMS)   | \
>> + cpufeat_mask(X86_FEATURE_RTM

Re: [Xen-devel] [PATCH RFC 10/31] xen/x86: Calculate HVM featureset

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> @@ -22,6 +24,27 @@ void __init calculate_featuresets(void)
>  
>  /* Unconditionally claim to be able to set the hypervisor bit. */
>  __set_bit(X86_FEATURE_HYPERVISOR, pv_featureset);
> +
> +/* HVM featureset. */
> +if ( hvm_enabled )
> +{
> +const uint32_t *hvm_featuremask = hvm_funcs.hap_supported
> +? hvm_hap_featuremask : hvm_shadow_featuremask;
> +
> +for ( i = 0; i < ARRAY_SIZE(hvm_featureset); ++i )
> +hvm_featureset[i] = host_featureset[i] & hvm_featuremask[i];
> +
> +/* Unconditionally claim to be able to set the hypervisor bit. */
> +__set_bit(X86_FEATURE_HYPERVISOR, hvm_featureset);
> +
> +/*
> + * On AMD, PV guests are entirely unable to use 'sysenter' as Xen 
> runs
> + * in long mode, but HVM guests are able if running in protected 
> mode.
> + */
> +if ( (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
> + !test_bit(X86_FEATURE_SEP, boot_cpu_data.x86_capability) )

Is the ! correct here? And please use cpu_has_sep.

Jan


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

Re: [Xen-devel] [PATCH RFC 09/31] xen/x86: Calculate PV featureset

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/arch/x86/cpuid/cpuid.c
> +++ b/xen/arch/x86/cpuid/cpuid.c
> @@ -102,7 +102,11 @@ const uint32_t known_features[XEN_NR_FEATURESET_ENTRIES] 
> =
>  cpufeat_mask(X86_FEATURE_CAT)
> |
>  cpufeat_mask(X86_FEATURE_RDSEED) 
> |
>  cpufeat_mask(X86_FEATURE_ADX)
> |
> -cpufeat_mask(X86_FEATURE_SMAP)),
> +cpufeat_mask(X86_FEATURE_SMAP)   
> |
> +
> cpufeat_mask(X86_FEATURE_PCOMMIT)|
> +
> cpufeat_mask(X86_FEATURE_CLFLUSHOPT) |
> +cpufeat_mask(X86_FEATURE_CLWB)   
> |
> +cpufeat_mask(X86_FEATURE_SHA)),
>  
>  [cpufeat_word(X86_FEATURE_PREFETCHWT1)] = 
> (cpufeat_mask(X86_FEATURE_PREFETCHWT1)),
>  
> @@ -116,6 +120,101 @@ const uint32_t 
> inverted_features[XEN_NR_FEATURESET_ENTRIES] =
>  [cpufeat_word(X86_FEATURE_FPU_SEL)] = cpufeat_mask(X86_FEATURE_FPU_SEL),
>  };
>  
> +#define PV_FEATUREMASK_1d   \
> +(cpufeat_mask(X86_FEATURE_FPU)| \
> + cpufeat_mask(X86_FEATURE_DE) | \
> + cpufeat_mask(X86_FEATURE_TSC)| \
> + cpufeat_mask(X86_FEATURE_MSR)| \
> + cpufeat_mask(X86_FEATURE_PAE)| \
> + cpufeat_mask(X86_FEATURE_MCE)| \
> + cpufeat_mask(X86_FEATURE_CX8)| \
> + cpufeat_mask(X86_FEATURE_APIC)   | \
> + cpufeat_mask(X86_FEATURE_SEP)| \
> + cpufeat_mask(X86_FEATURE_MCA)| \
> + cpufeat_mask(X86_FEATURE_CMOV)   | \
> + cpufeat_mask(X86_FEATURE_PAT)| \
> + cpufeat_mask(X86_FEATURE_CLFLSH) | \
> + cpufeat_mask(X86_FEATURE_ACPI)   | \
> + cpufeat_mask(X86_FEATURE_MMX)| \
> + cpufeat_mask(X86_FEATURE_FXSR)   | \
> + cpufeat_mask(X86_FEATURE_XMM)| \
> + cpufeat_mask(X86_FEATURE_XMM2))
> +
> +#define PV_FEATUREMASK_1c   \
> +(cpufeat_mask(X86_FEATURE_XMM3)  |  \
> + cpufeat_mask(X86_FEATURE_PCLMULQDQ) |  \
> + cpufeat_mask(X86_FEATURE_SSSE3) |  \
> + cpufeat_mask(X86_FEATURE_FMA)   |  \
> + cpufeat_mask(X86_FEATURE_CX16)  |  \
> + cpufeat_mask(X86_FEATURE_SSE4_1)|  \
> + cpufeat_mask(X86_FEATURE_SSE4_2)|  \
> + cpufeat_mask(X86_FEATURE_X2APIC)|  \
> + cpufeat_mask(X86_FEATURE_MOVBE) |  \
> + cpufeat_mask(X86_FEATURE_POPCNT)|  \
> + cpufeat_mask(X86_FEATURE_AES)   |  \
> + cpufeat_mask(X86_FEATURE_XSAVE) |  \
> + cpufeat_mask(X86_FEATURE_AVX)   |  \
> + cpufeat_mask(X86_FEATURE_F16C)  |  \
> + cpufeat_mask(X86_FEATURE_RDRAND)|  \
> + cpufeat_mask(X86_FEATURE_HYPERVISOR))
> +
> +#define PV_FEATUREMASK_e1d  \
> +((PV_FEATUREMASK_1d & SHARED_1d)|   \
> + cpufeat_mask(X86_FEATURE_SYSCALL)  |   \
> + cpufeat_mask(X86_FEATURE_MP)   |   \
> + cpufeat_mask(X86_FEATURE_NX)   |   \
> + cpufeat_mask(X86_FEATURE_MMXEXT)   |   \
> + cpufeat_mask(X86_FEATURE_FFXSR)|   \
> + cpufeat_mask(X86_FEATURE_LM)   |   \
> + cpufeat_mask(X86_FEATURE_3DNOWEXT) |   \
> + cpufeat_mask(X86_FEATURE_3DNOW))
> +
> +#define PV_FEATUREMASK_e1c  \
> +(cpufeat_mask(X86_FEATURE_LAHF_LM)   |  \
> + cpufeat_mask(X86_FEATURE_ABM)   |  \
> + cpufeat_mask(X86_FEATURE_SSE4A) |  \
> + cpufeat_mask(X86_FEATURE_MISALIGNSSE)   |  \
> + cpufeat_mask(X86_FEATURE_3DNOWPREFETCH) |  \
> + cpufeat_mask(X86_FEATURE_XOP)   |  \
> + cpufeat_mask(X86_FEATURE_LWP)   |  \
> + cpufeat_mask(X86_FEATURE_FMA4)  |  \
> + cpufeat_mask(X86_FEATURE_TBM)   |  \
> + cpufeat_mask(X86_FEATURE_DBEXT))
> +
> +#define PV_FEATUREMASK_Da1  \
> +(cpufeat_mask(X86_FEATURE_XSAVEOPT) |   \
> + cpufeat_mask(X86_FEATURE_XSAVEC)   |   \
> + cpufeat_mask(X86_FEATURE_XGETBV1))
> +
> +#define PV_FEATUREMASK_7b0  \
> +(cpufeat_mask(X86_FEATURE_FSGSBASE)   | \
> + cpufeat_mask(X86_FEATURE_BMI1)   | \
> + cpufeat_mask(X86_FEATURE_HLE)| \
> + cpufeat_mask(X86_FEATURE_AVX2)   | \
> + cpufeat_mask(X86_FEATURE_BMI2)   | \
> + cpufeat_mask(X86_FEATURE_ERMS)   | \
> + cpufeat_mask(X86_FEATURE_RTM)| \
> + cpufeat_mask(X86_FEATURE_RDSEED) | \
> + cpufeat_mask(X86_FEATURE_ADX)| \
> + cpufeat_mas

Re: [Xen-devel] [PATCH RFC 03/31] xen/x86: Store antifeatures inverted in a featureset

[Andrew Cooper]

On 22/12/15 16:32, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/cpuid/cpuid-private.h
>> @@ -0,0 +1,27 @@
>> +#ifdef __XEN__
>> +
>> +#include 
>> +
>> +#include 
>> +
>> +#else
>> +
>> +# error TODO for userspace
> I suppose your intentions with this will become apparent in later
> patches?

Everything in xen/arch/x86/cpuid/ is shared code between Xen and libxc,
to avoid having different algorithms/structures between the hypervisor
and toolstack.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 04/31] xen/x86: Mask out unknown features from Xen's capabilities

[Andrew Cooper]

On 22/12/15 16:42, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -324,6 +324,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
>>   * we do "generic changes."
>>   */
>>  for (i = 0; i < XEN_NR_FEATURESET_ENTRIES; ++i) {
>> +c->x86_capability[i] &= known_features[i];
>>  c->x86_capability[i] ^= inverted_features[i];
>>  }
> Assert that no unknown features slipped into the inverted ones?

For v2, I will have a small program which makes these assertions, and
interrupts the build if they fail.

Most of the required assertions are on automatically generated values,
or automatically derived values.

> But see also below.
>
>> --- a/xen/arch/x86/cpuid/cpuid-private.h
>> +++ b/xen/arch/x86/cpuid/cpuid-private.h
>> @@ -10,6 +10,32 @@
>>  
>>  #endif
>>  
>> +/* Mask of bits which are shared between 1d and e1d. */
>> +#define SHARED_1d   \
>> +(cpufeat_mask(X86_FEATURE_FPU)   |  \
>> + cpufeat_mask(X86_FEATURE_VME)   |  \
>> + cpufeat_mask(X86_FEATURE_DE)|  \
>> + cpufeat_mask(X86_FEATURE_PSE)   |  \
>> + cpufeat_mask(X86_FEATURE_TSC)   |  \
>> + cpufeat_mask(X86_FEATURE_MSR)   |  \
>> + cpufeat_mask(X86_FEATURE_PAE)   |  \
>> + cpufeat_mask(X86_FEATURE_MCE)   |  \
>> + cpufeat_mask(X86_FEATURE_CX8)   |  \
>> + cpufeat_mask(X86_FEATURE_APIC)  |  \
>> + cpufeat_mask(X86_FEATURE_MTRR)  |  \
>> + cpufeat_mask(X86_FEATURE_PGE)   |  \
>> + cpufeat_mask(X86_FEATURE_MCA)   |  \
>> + cpufeat_mask(X86_FEATURE_CMOV)  |  \
>> + cpufeat_mask(X86_FEATURE_PAT)   |  \
>> + cpufeat_mask(X86_FEATURE_PSE36) |  \
>> + cpufeat_mask(X86_FEATURE_MMX)   |  \
>> + cpufeat_mask(X86_FEATURE_FXSR))
> These are shared for AMD, but zero in the extended leaf for Intel.

Indeed.  They make handling of feature dependences rather tricky.

>
>> --- a/xen/arch/x86/cpuid/cpuid.c
>> +++ b/xen/arch/x86/cpuid/cpuid.c
>> @@ -1,5 +1,110 @@
>>  #include "cpuid-private.h"
>>  
>> +const uint32_t known_features[XEN_NR_FEATURESET_ENTRIES] =
>> +{
>> +[cpufeat_word(X86_FEATURE_FPU)] = (SHARED_1d   |
>> +   cpufeat_mask(X86_FEATURE_SEP)   |
> I can see how you try to remove fixed relationship, but using
> FPU in the array index when no FPU appear in the list is at
> least confusing.
>
> Looking at the rest, adding a new feature will become quite a bit
> more involved. I think we need some better abstraction here, e.g.
> a mechanism similar to the one I used in public/errno.h or the one
> Linux uses to populate its syscall tables or /proc/cpuinfo's feature
> list to allow multiple inclusion of a single list of definitions where all
> properties of each individual feature are maintained on one line.
>
> The tables in this file would then be derived from this (perhaps
> via further steps of machine processing).

Actually, patch  16 "x86: Automatically generate known_features" moves
this into the python script which flattens dependencies.

That patch also has a TODO to reorder the series, which would drop most
of this patch.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 01/31] xen/public: Export featureset information in the public API

[Jan Beulich]

>>> On 22.12.15 at 17:42,  wrote:
> On 22/12/15 16:28, Jan Beulich wrote:
> On 16.12.15 at 22:24,  wrote:
>>> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2 
>>> */
>>> +#define X86_FEATURE_XSTORE ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore 
>>> insn) */
>>> +#define X86_FEATURE_XSTORE_EN  ((FSMAX+1)*32+ 3) /* on-CPU RNG enabled 
>>> */
>>> +#define X86_FEATURE_XCRYPT ((FSMAX+1)*32+ 6) /* on-CPU crypto (xcrypt 
>>> insn) */
>>> +#define X86_FEATURE_XCRYPT_EN  ((FSMAX+1)*32+ 7) /* on-CPU crypto 
>>> enabled */
>>> +#define X86_FEATURE_ACE2   ((FSMAX+1)*32+ 8) /* Advanced Cryptography 
>>> Engine v2 */
>>> +#define X86_FEATURE_ACE2_EN((FSMAX+1)*32+ 9) /* ACE v2 enabled */
>>> +#define X86_FEATURE_PHE((FSMAX+1)*32+10) /* PadLock Hash 
>>> Engine */
>>> +#define X86_FEATURE_PHE_EN ((FSMAX+1)*32+11) /* PHE enabled */
>>> +#define X86_FEATURE_PMM((FSMAX+1)*32+12) /* PadLock Montgomery 
>>> Multiplier */
>>> +#define X86_FEATURE_PMM_EN ((FSMAX+1)*32+13) /* PMM enabled */
>> None of these get consumed anywhere - if you already touch this
>> code, just drop all of them.
> 
> X86_FEATURE_XSTORE gets used in xen/arch/x86/cpu/centaur.c to stash word
> 0xC001, but nothing actually reads the stashed values.
> 
> I could do a precursor patch which drops the stashing of this
> information, which will result in NCAPINTS getting shorter by the end of
> the series.

Yes, that's what I meant to imply.

>>> +/*
>>> + * CPUID leaf shorthand:
>>> + * - optional 'e', Extended (0x8xxx)
>>> + * - leaf, uppercase hex
>>> + * - register, lowercase
>>> + * - optional subleaf, uppercase hex
>>> + */
>>> +#define XEN_FEATURESET_1d 0 /* 0x0001.edx  */
>>> +#define XEN_FEATURESET_1c 1 /* 0x0001.ecx  */
>>> +#define XEN_FEATURESET_e1d2 /* 0x8001.edx  */
>>> +#define XEN_FEATURESET_e1c3 /* 0x8001.ecx  */
>>> +#define XEN_FEATURESET_Da14 /* 0x000d:1.eax*/
>>> +#define XEN_FEATURESET_7b05 /* 0x0007:0.ebx*/
>> This ends up being pretty cryptic.
> 
> Perhaps at a first glance, but there are so many uses that a shorthand
> really is needed.  See especially the MSR masking patches towards the
> end of the series.

I understand that something short is needed. But as the main
identifier in the ABI?

>>> +#define XEN_NR_FEATURESET_ENTRIES (XEN_FEATURESET_7b0 + 1)
>> This shouldn't be exposed, as it will necessarily change sooner or later.
> 
> Hmm yes - I think I can alter where this lives, although libxc does need
> to be able to get this value.

Perhaps keep it where it is, but put it inside #ifdef __XEN__?

Jan


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

Re: [Xen-devel] [PATCH RFC 07/31] xen/x86: Export host featureset via SYSCTL

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> @@ -190,6 +191,56 @@ long arch_do_sysctl(
>  }
>  break;
>  
> +case XEN_SYSCTL_get_featureset:
> +{
> +uint32_t *featureset;

const

> +unsigned int nr;
> +
> +/* Request for maximum number of features? */
> +if ( guest_handle_is_null(sysctl->u.featureset.features) )
> +{
> +sysctl->u.featureset.nr_features = XEN_NR_FEATURESET_ENTRIES;
> +if ( __copy_to_guest(u_sysctl, sysctl, 1) )

__copy_field_to_guest()?

> +ret = -EFAULT;
> +break;
> +}
> +
> +/* Clip the number of entries. */
> +nr = min_t(unsigned int, sysctl->u.featureset.nr_features,
> +   XEN_NR_FEATURESET_ENTRIES);

Let's try to avoid min_t() wherever possible.

> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -764,6 +764,24 @@ struct xen_sysctl_tmem_op {
>  typedef struct xen_sysctl_tmem_op xen_sysctl_tmem_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_sysctl_tmem_op_t);
>  
> +/*
> + * XEN_SYSCTL_get_featureset (x86 specific)

Depending on your further intention this and/or ...

> + *
> + * Return information about the maximum sets of features which can be offered
> + * to different types of guests.  This is all strictly information as found 
> in
> + * `cpuid` feature leaves with no synthetic alterations.
> + */
> +struct xen_sysctl_featureset {
> +#define XEN_SYSCTL_featureset_host  0

... this need to carry "CPU" in their names.

Jan


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

Re: [Xen-devel] [PATCH v2 2/8] xen: arm: fix typo in the description of struct pending_irq->desc

[Stefano Stabellini]

On Tue, 10 Nov 2015, Ian Campbell wrote:
> s/it/if/ makes more sense.
> 
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  xen/include/asm-arm/vgic.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index cb51a9e..7d580cc 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -66,7 +66,7 @@ struct pending_irq
>  #define GIC_IRQ_GUEST_ENABLED  3
>  #define GIC_IRQ_GUEST_MIGRATING   4
>  unsigned long status;
> -struct irq_desc *desc; /* only set it the irq corresponds to a physical 
> irq */
> +struct irq_desc *desc; /* only set if the irq corresponds to a physical 
> irq */
>  unsigned int irq;
>  #define GIC_INVALID_LR ~(uint8_t)0
>  uint8_t lr;
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v2 1/8] xen: arm: fix indendation of struct vtimer

[Stefano Stabellini]

On Tue, 10 Nov 2015, Ian Campbell wrote:
> Signed-off-by: Ian Campbell 

Acked-by: Stefano Stabellini 


>  xen/include/asm-arm/domain.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
> index e7e40da..c56f06e 100644
> --- a/xen/include/asm-arm/domain.h
> +++ b/xen/include/asm-arm/domain.h
> @@ -35,11 +35,11 @@ extern int dom0_11_mapping;
>  #define is_domain_direct_mapped(d) ((d) == hardware_domain && 
> dom0_11_mapping)
>  
>  struct vtimer {
> -struct vcpu *v;
> -int irq;
> -struct timer timer;
> -uint32_t ctl;
> -uint64_t cval;
> +struct vcpu *v;
> +int irq;
> +struct timer timer;
> +uint32_t ctl;
> +uint64_t cval;
>  };
>  
>  struct arch_domain
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH RFC 06/31] xen/x86: Infrastructure to calculate guest featuresets

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
>  xen/arch/x86/Makefile   |  1 +
>  xen/arch/x86/cpuid.c| 23 +++
>  xen/arch/x86/setup.c|  3 +++
>  xen/include/asm-x86/cpuid.h | 22 ++
>  4 files changed, 49 insertions(+)
>  create mode 100644 xen/arch/x86/cpuid.c

You already introduced xen/arch/x86/cpuid/ in patch 3 - why don't
you put this file there, as e.g. guest.c?

Jan


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

Re: [Xen-devel] [PATCH RFC 05/31] xen/x86: Collect more CPUID feature words

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -481,7 +481,7 @@ static void __devinit init_amd(struct cpuinfo_x86 *c)
>  
>   if (c->extended_cpuid_level >= 0x8007) {
>   c->x86_power = cpuid_edx(0x8007);
> - if (c->x86_power & (1<<8)) {
> + if (c->x86_power & cpufeat_mask(X86_FEATURE_ITSC)) {

generic_identify() has already run by the time we get here, so no
need to re-read cpuid_edx() (interestingly enough you leverage
this in init_intel()).

> --- a/xen/arch/x86/cpuid/cpuid.c
> +++ b/xen/arch/x86/cpuid/cpuid.c
> @@ -103,6 +103,12 @@ const uint32_t known_features[XEN_NR_FEATURESET_ENTRIES] 
> =
>  cpufeat_mask(X86_FEATURE_RDSEED) 
> |
>  cpufeat_mask(X86_FEATURE_ADX)
> |
>  cpufeat_mask(X86_FEATURE_SMAP)),
> +
> +[cpufeat_word(X86_FEATURE_PREFETCHWT1)] = 
> (cpufeat_mask(X86_FEATURE_PREFETCHWT1)),
> +
> +[cpufeat_word(X86_FEATURE_ITSC)] = (cpufeat_mask(X86_FEATURE_ITSC)),
> +
> +[cpufeat_word(X86_FEATURE_CLZERO)] = (cpufeat_mask(X86_FEATURE_CLZERO)),
>  };

Are these indeed the only ones in their groups that can be safely
marked "known"?

Jan


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

Re: [Xen-devel] [PATCH RFC XEN v1 09/14] xen: arm: Save and restore GIC state.

[Stefano Stabellini]

On Thu, 17 Dec 2015, Ian Campbell wrote:
> > > +/* Save PPI and SGI states (per-CPU) */
> > > +spin_lock(&v->arch.vgic.lock);
> >
> > vgic_lock
>
> Ah, yes, this function was originally in save.c so didn't have access, but
> now it is in the right place I should use all the correct functions.
>
> > Is the domain already paused at this point? If so, maybe we could get
> > away without locking?
>
> Maybe we could think about it hard enough to rationalise that, but it seems
> safer and easier to just follow the locking rules regardless.
>
> > > +int vgic_irq_save_core(struct vcpu *v, unsigned irq, struct hvm_hw_irq
> > > *s)
> > > +{
> > > +struct pending_irq *p = irq_to_pending(v, irq);
> > > +struct vgic_irq_rank *rank = vgic_rank_irq(v, p->irq);
> > > +
> > > +const bool enabled = test_bit(GIC_IRQ_GUEST_ENABLED, &p->status);
> > > +const bool queued = test_bit(GIC_IRQ_GUEST_QUEUED, &p->status);
> > > +const bool visible = test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status);
> > > +
> > > +spin_lock(&rank->lock);
> >
> > vgic_rank_lock. Maybe we need to take the vgic lock because there might
> > be incoming hardware interrupts for the domain but I don't think we need
> > the rank lock, do we?
>
> As above I think it is simpler and safer to just follow the usual rules
> rather than to special case things.

I don't think we take the rank lock with the vgic lock held anywhere in
the code though. It would be good to avoid nested locking unless
necessary.


> > +{
> > > +/*
> > > + * This uses the current IPRIORITYR, which may differ from
> > > + * when the IRQ was actually made pending. h/w spec probably
> > > + * allows this,  check
> > > + */
> >
> > From this VM point of view the IPRIORITYR is s->priority. I would remove
> > the comment.
>
> If you have an IRQ with priority 55 which fires and then while it is
> pending the priority is changed to 75 then I'm not sure what impact that
> has on the priority which the hardware considers the already pending
> interrupt to have.
>
> To make it more complex consider if there was a second interrupt IRQ
> with priority 65, if the handler for that was the one changed IRQ's
> priority should it expect to get immediately preempted by IRQ
>
> The comment is there because I'm not sure what behaviour the spec requires.

The spec says:

It is IMPLEMENTATION DEFINED whether changing the value of a priority
field changes the priority of an active interrupt.

We could infer that changing the priority of pending interrupts is
supposed to be supported.

I would only write:

   * This uses the current IPRIORITYR, which may differ from
   * when the IRQ was actually made pending.


> In terms of our code without the save restore I think the pending IRQ
> would remain at priority 55 and the guest would get IRQ when IRQ
> EOIs. Whereas upon restore we would reraise it with priority 75 and IRQ
> would appear to preempt IRQ, which would be an interesting difference in
> behaviour from the PoV of the guest.

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

Re: [Xen-devel] [PATCH RFC 01/31] xen/public: Export featureset information in the public API

[Andrew Cooper]

On 22/12/15 16:28, Jan Beulich wrote:
 On 16.12.15 at 22:24,  wrote:
>> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2 
>> */
>> +#define X86_FEATURE_XSTORE  ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore 
>> insn) */
>> +#define X86_FEATURE_XSTORE_EN   ((FSMAX+1)*32+ 3) /* on-CPU RNG enabled 
>> */
>> +#define X86_FEATURE_XCRYPT  ((FSMAX+1)*32+ 6) /* on-CPU crypto (xcrypt 
>> insn) */
>> +#define X86_FEATURE_XCRYPT_EN   ((FSMAX+1)*32+ 7) /* on-CPU crypto 
>> enabled */
>> +#define X86_FEATURE_ACE2((FSMAX+1)*32+ 8) /* Advanced Cryptography 
>> Engine v2 */
>> +#define X86_FEATURE_ACE2_EN ((FSMAX+1)*32+ 9) /* ACE v2 enabled */
>> +#define X86_FEATURE_PHE ((FSMAX+1)*32+10) /* PadLock Hash 
>> Engine */
>> +#define X86_FEATURE_PHE_EN  ((FSMAX+1)*32+11) /* PHE enabled */
>> +#define X86_FEATURE_PMM ((FSMAX+1)*32+12) /* PadLock Montgomery 
>> Multiplier */
>> +#define X86_FEATURE_PMM_EN  ((FSMAX+1)*32+13) /* PMM enabled */
> None of these get consumed anywhere - if you already touch this
> code, just drop all of them.

X86_FEATURE_XSTORE gets used in xen/arch/x86/cpu/centaur.c to stash word
0xC001, but nothing actually reads the stashed values.

I could do a precursor patch which drops the stashing of this
information, which will result in NCAPINTS getting shorter by the end of
the series.

>
>> +/*
>> + * CPUID leaf shorthand:
>> + * - optional 'e', Extended (0x8xxx)
>> + * - leaf, uppercase hex
>> + * - register, lowercase
>> + * - optional subleaf, uppercase hex
>> + */
>> +#define XEN_FEATURESET_1d 0 /* 0x0001.edx  */
>> +#define XEN_FEATURESET_1c 1 /* 0x0001.ecx  */
>> +#define XEN_FEATURESET_e1d2 /* 0x8001.edx  */
>> +#define XEN_FEATURESET_e1c3 /* 0x8001.ecx  */
>> +#define XEN_FEATURESET_Da14 /* 0x000d:1.eax*/
>> +#define XEN_FEATURESET_7b05 /* 0x0007:0.ebx*/
> This ends up being pretty cryptic.

Perhaps at a first glance, but there are so many uses that a shorthand
really is needed.  See especially the MSR masking patches towards the
end of the series.

>
>> +#define XEN_NR_FEATURESET_ENTRIES (XEN_FEATURESET_7b0 + 1)
> This shouldn't be exposed, as it will necessarily change sooner or later.

Hmm yes - I think I can alter where this lives, although libxc does need
to be able to get this value.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 04/31] xen/x86: Mask out unknown features from Xen's capabilities

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -324,6 +324,7 @@ void __cpuinit identify_cpu(struct cpuinfo_x86 *c)
>* we do "generic changes."
>*/
>   for (i = 0; i < XEN_NR_FEATURESET_ENTRIES; ++i) {
> + c->x86_capability[i] &= known_features[i];
>   c->x86_capability[i] ^= inverted_features[i];
>   }

Assert that no unknown features slipped into the inverted ones?
But see also below.

> --- a/xen/arch/x86/cpuid/cpuid-private.h
> +++ b/xen/arch/x86/cpuid/cpuid-private.h
> @@ -10,6 +10,32 @@
>  
>  #endif
>  
> +/* Mask of bits which are shared between 1d and e1d. */
> +#define SHARED_1d   \
> +(cpufeat_mask(X86_FEATURE_FPU)   |  \
> + cpufeat_mask(X86_FEATURE_VME)   |  \
> + cpufeat_mask(X86_FEATURE_DE)|  \
> + cpufeat_mask(X86_FEATURE_PSE)   |  \
> + cpufeat_mask(X86_FEATURE_TSC)   |  \
> + cpufeat_mask(X86_FEATURE_MSR)   |  \
> + cpufeat_mask(X86_FEATURE_PAE)   |  \
> + cpufeat_mask(X86_FEATURE_MCE)   |  \
> + cpufeat_mask(X86_FEATURE_CX8)   |  \
> + cpufeat_mask(X86_FEATURE_APIC)  |  \
> + cpufeat_mask(X86_FEATURE_MTRR)  |  \
> + cpufeat_mask(X86_FEATURE_PGE)   |  \
> + cpufeat_mask(X86_FEATURE_MCA)   |  \
> + cpufeat_mask(X86_FEATURE_CMOV)  |  \
> + cpufeat_mask(X86_FEATURE_PAT)   |  \
> + cpufeat_mask(X86_FEATURE_PSE36) |  \
> + cpufeat_mask(X86_FEATURE_MMX)   |  \
> + cpufeat_mask(X86_FEATURE_FXSR))

These are shared for AMD, but zero in the extended leaf for Intel.

> --- a/xen/arch/x86/cpuid/cpuid.c
> +++ b/xen/arch/x86/cpuid/cpuid.c
> @@ -1,5 +1,110 @@
>  #include "cpuid-private.h"
>  
> +const uint32_t known_features[XEN_NR_FEATURESET_ENTRIES] =
> +{
> +[cpufeat_word(X86_FEATURE_FPU)] = (SHARED_1d   |
> +   cpufeat_mask(X86_FEATURE_SEP)   |

I can see how you try to remove fixed relationship, but using
FPU in the array index when no FPU appear in the list is at
least confusing.

Looking at the rest, adding a new feature will become quite a bit
more involved. I think we need some better abstraction here, e.g.
a mechanism similar to the one I used in public/errno.h or the one
Linux uses to populate its syscall tables or /proc/cpuinfo's feature
list to allow multiple inclusion of a single list of definitions where all
properties of each individual feature are maintained on one line.

The tables in this file would then be derived from this (perhaps
via further steps of machine processing).

Jan


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

Re: [Xen-devel] [PATCH V5 4/6] x86/hvm: pkeys, add pkeys support for guest_walk_tables

[George Dunlap]

On 22/12/15 10:30, Huaitong Han wrote:
> Protection keys define a new 4-bit protection key field(PKEY) in bits 62:59 of
> leaf entries of the page tables.
>
> PKRU register defines 32 bits, there are 16 domains and 2 attribute bits per
> domain in pkru, for each i (0 ≤ i ≤ 15), PKRU[2i] is the access-disable bit 
> for
> protection key i (ADi); PKRU[2i+1] is the write-disable bit for protection key
> i (WDi). PKEY is index to a defined domain.
>
> A fault is considered as a PKU violation if all of the following conditions 
> are
> ture:
> 1.CR4_PKE=1.
> 2.EFER_LMA=1.
> 3.Page is present with no reserved bit violations.
> 4.The access is not an instruction fetch.
> 5.The access is to a user page.
> 6.PKRU.AD=1
> or The access is a data write and PKRU.WD=1
> and either CR0.WP=1 or it is a user access.

One comment you didn't address from v3, however:

"At the moment PFEC_insn_fetch is only set in
hvm_fetch_from_guest_virt() if hvm_nx_enabled() or hvm_smep_enabled()
are true.  Which means that if you *don't* have nx or smep enabled, then
the patch series as is will fault on instruction fetches when it
shouldn't.  (I don't remember anyone mentioning nx or smep being enabled
as a prerequisite for pkeys.)"

I think realistically the only way to address this is to start making
the clean separation between "pfec in" and "pfec out" I mentioned in the
previous discussion.

I've coded up the attached patch, but only compile-tested it.  Can you
give it a look to see if you think it is correct, test it, include it in
your next patch series?

Thanks,
 -George

From b8ec8e14c670215587a4e74c3aaec8dab6f26a8c Mon Sep 17 00:00:00 2001
From: George Dunlap 
Date: Tue, 22 Dec 2015 16:17:22 +
Subject: [PATCH] xen/mm: Clean up pfec handling in gva_to_gfn

At the moment, the pfec argument to gva_to_gfn has two functions:

* To inform guest_walk what kind of access is happenind

* As a value to pass back into the guest in the event of a fault.

Unfortunately this is not quite treated consistently: the hvm_fetch_*
function will "pre-clear" the PFEC_insn_fetch flag before calling
gva_to_gfn; meaning guest_walk doesn't actually know whether a given
access is an instruction fetch or not.  This works now, but will cause
issues when pkeys are introduced, since guest_walk will need to know
whether an access is an instruction fetch even if it doesn't return
PFEC_insn_fetch.

Fix this by making a clean separation for in and out functionalities
of the pfec argument:

1. Always pass in the access type to gva_to_gfn

2. Filter out inappropriate access flags before returning from gva_to_gfn.

(The PFEC_insn_fetch flag should only be passed to the guest if either NX or
SMEP is enabled.  See Intel 64 Developer's Manual, Volume 3, Section 4.7.)

Signed-off-by: George Dunlap 
---
 xen/arch/x86/hvm/hvm.c   |  8 ++--
 xen/arch/x86/mm/hap/guest_walk.c | 10 +-
 xen/arch/x86/mm/shadow/multi.c   |  6 ++
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 08cef1f..aa1f64f 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4423,11 +4423,9 @@ enum hvm_copy_result hvm_copy_from_guest_virt(
 enum hvm_copy_result hvm_fetch_from_guest_virt(
 void *buf, unsigned long vaddr, int size, uint32_t pfec)
 {
-if ( hvm_nx_enabled(current) || hvm_smep_enabled(current) )
-pfec |= PFEC_insn_fetch;
 return __hvm_copy(buf, vaddr, size,
   HVMCOPY_from_guest | HVMCOPY_fault | HVMCOPY_virt,
-  PFEC_page_present | pfec);
+  PFEC_page_present | PFEC_insn_fetch | pfec);
 }
 
 enum hvm_copy_result hvm_copy_to_guest_virt_nofault(
@@ -4449,11 +4447,9 @@ enum hvm_copy_result hvm_copy_from_guest_virt_nofault(
 enum hvm_copy_result hvm_fetch_from_guest_virt_nofault(
 void *buf, unsigned long vaddr, int size, uint32_t pfec)
 {
-if ( hvm_nx_enabled(current) || hvm_smep_enabled(current) )
-pfec |= PFEC_insn_fetch;
 return __hvm_copy(buf, vaddr, size,
   HVMCOPY_from_guest | HVMCOPY_no_fault | HVMCOPY_virt,
-  PFEC_page_present | pfec);
+  PFEC_page_present | PFEC_insn_fetch | pfec);
 }
 
 unsigned long copy_to_user_hvm(void *to, const void *from, unsigned int len)
diff --git a/xen/arch/x86/mm/hap/guest_walk.c b/xen/arch/x86/mm/hap/guest_walk.c
index 11c1b35..2dce111 100644
--- a/xen/arch/x86/mm/hap/guest_walk.c
+++ b/xen/arch/x86/mm/hap/guest_walk.c
@@ -82,7 +82,7 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 if ( !top_page )
 {
 pfec[0] &= ~PFEC_page_present;
-return INVALID_GFN;
+goto out_tweak_pfec;
 }
 top_mfn = _mfn(page_to_mfn(top_page));
 
@@ -136,6 +136,14 @@ unsigned long hap_p2m_ga_to_gfn(GUEST_PAGING_LEVELS)(
 if ( missing & _PAGE_SHARED )
 pfec[0] = PFEC_page_shared;
 
+out_tweak_pfec:
+/* 
+ * Intel 64 Volume 3, Section 4.7: 

Re: [Xen-devel] [PATCH RFC 03/31] xen/x86: Store antifeatures inverted in a featureset

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- /dev/null
> +++ b/xen/arch/x86/cpuid/cpuid-private.h
> @@ -0,0 +1,27 @@
> +#ifdef __XEN__
> +
> +#include 
> +
> +#include 
> +
> +#else
> +
> +# error TODO for userspace

I suppose your intentions with this will become apparent in later
patches?

Jan


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

[Xen-devel] [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory

[Vitaly Kuznetsov]

Currently, all newly added memory blocks remain in 'offline' state unless
someone onlines them, some linux distributions carry special udev rules
like:

SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"

to make this happen automatically. This is not a great solution for virtual
machines where memory hotplug is being used to address high memory pressure
situations as such onlining is slow and a userspace process doing this
(udev) has a chance of being killed by the OOM killer as it will probably
require to allocate some memory.

Introduce default policy for the newly added memory blocks in
/sys/devices/system/memory/hotplug_autoonline file with two possible
values: "offline" which preserves the current behavior and "online" which
causes all newly added memory blocks to go online as soon as they're added.
The default is "online" when MEMORY_HOTPLUG_AUTOONLINE kernel config option
is selected.

Cc: Jonathan Corbet 
Cc: Greg Kroah-Hartman 
Cc: Daniel Kiper 
Cc: Dan Williams 
Cc: Tang Chen 
Cc: David Vrabel 
Cc: David Rientjes 
Cc: Andrew Morton 
Cc: Naoya Horiguchi 
Cc: Xishi Qiu 
Cc: Mel Gorman 
Cc: "K. Y. Srinivasan" 
Cc: Igor Mammedov 
Cc: Kay Sievers 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Signed-off-by: Vitaly Kuznetsov 
---
- Changes since 'v1':
  Add 'online' parameter to add_memory_resource() as it is being used by
  xen ballon driver and it adds "empty" memory pages [David Vrabel].
  (I don't completely understand what prevents manual onlining in this
   case as we still have all newly added blocks in sysfs ... this is the
   discussion point.)

- Changes since 'RFC':
  It seems nobody is strongly opposed to the idea, thus non-RFC.
  Change memhp_autoonline to bool, we support only MMOP_ONLINE_KEEP
  and MMOP_OFFLINE for the auto-onlining policy, eliminate 'unknown'
  from show_memhp_autoonline(). [Daniel Kiper]
  Put everything under CONFIG_MEMORY_HOTPLUG_AUTOONLINE, enable the
  feature by default (when the config option is selected) and add
  kernel parameter (nomemhp_autoonline) to disable the functionality
  upon boot when needed.

- RFC:
  I was able to find previous attempts to fix the issue, e.g.:
  http://marc.info/?l=linux-kernel&m=137425951924598&w=2
  http://marc.info/?l=linux-acpi&m=127186488905382
  but I'm not completely sure why it didn't work out and the solution
  I suggest is not 'smart enough', thus 'RFC'.
---
 Documentation/kernel-parameters.txt |  2 ++
 Documentation/memory-hotplug.txt| 26 --
 drivers/base/memory.c   | 36 
 drivers/xen/balloon.c   |  2 +-
 include/linux/memory_hotplug.h  |  6 +-
 mm/Kconfig  |  9 +
 mm/memory_hotplug.c | 25 +++--
 7 files changed, 96 insertions(+), 10 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 742f69d..652efe1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2537,6 +2537,8 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
shutdown the other cpus.  Instead use the REBOOT_VECTOR
irq.
 
+   nomemhp_autoonline  Don't automatically online newly added memory.
+
nomoduleDisable module load
 
nopat   [X86] Disable PAT (page attribute table extension of
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index ce2cfcf..041efac 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -111,8 +111,9 @@ To use memory hotplug feature, kernel must be compiled with 
following
 config options.
 
 - For all memory hotplug
-Memory model -> Sparse Memory  (CONFIG_SPARSEMEM)
-Allow for memory hot-add   (CONFIG_MEMORY_HOTPLUG)
+Memory model -> Sparse Memory (CONFIG_SPARSEMEM)
+Allow for memory hot-add  (CONFIG_MEMORY_HOTPLUG)
+Automatically online hot-added memory (CONFIG_MEMORY_HOTPLUG_AUTOONLINE)
 
 - To enable memory removal, the followings are also necessary
 Allow for memory hot remove(CONFIG_MEMORY_HOTREMOVE)
@@ -254,12 +255,25 @@ If the memory block is online, you'll read "online".
 If the memory block is offline, you'll read "offline".
 
 
-5.2. How to online memory
+5.2. Memory onlining
 
-Even if the memory is hot-added, it is not at ready-to-use state.
-For using newly added memory, you have to "online" the memory block.
+When the memory is hot-added, the kernel decides whether or not to "online"
+it according to the policy which can be read from "hotplug_autoonline" file
+(requires CONFIG_MEMORY_HOTPLUG_AUTOONLINE):
 
-For onlining, you have to write "online" to the memory block's state file as:
+% cat /sys/devices/system/memory/hotplug_autoonline
+
+The default is "online" which means the newly added memory will 

Re: [Xen-devel] [PATCH RFC 02/31] tools/libxc: Use public/featureset.h for cpuid policy generation

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> --- a/xen/include/public/arch-x86/featureset.h
> +++ b/xen/include/public/arch-x86/featureset.h
> @@ -163,6 +163,7 @@
>  
>  /* Intel-defined CPU features, CPUID level 0x0007:0.ebx, word 5 */
>  #define X86_FEATURE_FSGSBASE  ( 5*32+ 0) /* {RD,WR}{FS,GS}BASE 
> instructions */
> +#define X86_FEATURE_TSC_ADJUST( 5*32+ 1) /* TSC_ADJUST MSR available */

This would probably better go into patch 1.

Jan


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

Re: [Xen-devel] [PATCH RFC 01/31] xen/public: Export featureset information in the public API

[Jan Beulich]

>>> On 16.12.15 at 22:24,  wrote:
> +/* VIA/Cyrix/Centaur-defined CPU features, CPUID level 0xC001, FSMAX+2 */
> +#define X86_FEATURE_XSTORE   ((FSMAX+1)*32+ 2) /* on-CPU RNG present (xstore 
> insn) */
> +#define X86_FEATURE_XSTORE_EN((FSMAX+1)*32+ 3) /* on-CPU RNG enabled 
> */
> +#define X86_FEATURE_XCRYPT   ((FSMAX+1)*32+ 6) /* on-CPU crypto (xcrypt 
> insn) */
> +#define X86_FEATURE_XCRYPT_EN((FSMAX+1)*32+ 7) /* on-CPU crypto 
> enabled */
> +#define X86_FEATURE_ACE2 ((FSMAX+1)*32+ 8) /* Advanced Cryptography 
> Engine v2 */
> +#define X86_FEATURE_ACE2_EN  ((FSMAX+1)*32+ 9) /* ACE v2 enabled */
> +#define X86_FEATURE_PHE  ((FSMAX+1)*32+10) /* PadLock Hash 
> Engine */
> +#define X86_FEATURE_PHE_EN   ((FSMAX+1)*32+11) /* PHE enabled */
> +#define X86_FEATURE_PMM  ((FSMAX+1)*32+12) /* PadLock Montgomery 
> Multiplier */
> +#define X86_FEATURE_PMM_EN   ((FSMAX+1)*32+13) /* PMM enabled */

None of these get consumed anywhere - if you already touch this
code, just drop all of them.

> +/*
> + * CPUID leaf shorthand:
> + * - optional 'e', Extended (0x8xxx)
> + * - leaf, uppercase hex
> + * - register, lowercase
> + * - optional subleaf, uppercase hex
> + */
> +#define XEN_FEATURESET_1d 0 /* 0x0001.edx  */
> +#define XEN_FEATURESET_1c 1 /* 0x0001.ecx  */
> +#define XEN_FEATURESET_e1d2 /* 0x8001.edx  */
> +#define XEN_FEATURESET_e1c3 /* 0x8001.ecx  */
> +#define XEN_FEATURESET_Da14 /* 0x000d:1.eax*/
> +#define XEN_FEATURESET_7b05 /* 0x0007:0.ebx*/

This ends up being pretty cryptic.

> +#define XEN_NR_FEATURESET_ENTRIES (XEN_FEATURESET_7b0 + 1)

This shouldn't be exposed, as it will necessarily change sooner or later.

Jan


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

[Xen-devel] [PATCH] x86/VPMU: Check more carefully which bits are allowed to be written to MSRs

[Boris Ostrovsky]

Current Intel VPMU emulation needs to perform more checks when writing
PMU MSRs on guest's behalf:
* MSR_CORE_PERF_GLOBAL_CTRL is not checked at all
* MSR_CORE_PERF_FIXED_CTR_CTRL has more reserved bits in PMU version 2
* MSR_CORE_PERF_GLOBAL_OVF_CTRL's bit 61 is allowed on versions greater
* than 2.

We can also use precomputed mask in core2_vpmu_do_interrupt().

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/cpu/vpmu_intel.c |   18 --
 1 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/vpmu_intel.c b/xen/arch/x86/cpu/vpmu_intel.c
index 3eff1ae..8dc0b48 100644
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -87,7 +87,7 @@ static unsigned int __read_mostly arch_pmc_cnt, fixed_pmc_cnt;
 /* Masks used for testing whether and MSR is valid */
 #define ARCH_CTRL_MASK  (~((1ull << 32) - 1) | (1ull << 21))
 static uint64_t __read_mostly fixed_ctrl_mask, fixed_counters_mask;
-static uint64_t __read_mostly global_ovf_ctrl_mask;
+static uint64_t __read_mostly global_ovf_ctrl_mask, global_ctrl_mask;
 
 /* Total size of PMU registers block (copied to/from PV(H) guest) */
 static unsigned int __read_mostly regs_sz;
@@ -392,6 +392,8 @@ static int core2_vpmu_verify(struct vcpu *v)
 
 if ( core2_vpmu_cxt->global_ovf_ctrl & global_ovf_ctrl_mask )
 return -EINVAL;
+if ( core2_vpmu_cxt->global_ctrl & global_ctrl_mask )
+return -EINVAL;
 
 fixed_ctrl = core2_vpmu_cxt->fixed_ctrl;
 if ( fixed_ctrl & fixed_ctrl_mask )
@@ -627,6 +629,8 @@ static int core2_vpmu_do_wrmsr(unsigned int msr, uint64_t 
msr_content,
 gdprintk(XENLOG_WARNING, "Guest setting of DTS is ignored.\n");
 return 0;
 case MSR_CORE_PERF_GLOBAL_CTRL:
+if ( msr_content & global_ctrl_mask )
+return -EINVAL;
 core2_vpmu_cxt->global_ctrl = msr_content;
 break;
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
@@ -820,7 +824,7 @@ static int core2_vpmu_do_interrupt(struct cpu_user_regs 
*regs)
 if ( is_pmc_quirk )
 handle_pmc_quirk(msr_content);
 core2_vpmu_cxt->global_status |= msr_content;
-msr_content = 0xC007 | ((1 << arch_pmc_cnt) - 1);
+msr_content = ~global_ovf_ctrl_mask;
 wrmsrl(MSR_CORE_PERF_GLOBAL_OVF_CTRL, msr_content);
 }
 else
@@ -1001,10 +1005,20 @@ int __init core2_vpmu_init(void)
 full_width_write = (caps >> 13) & 1;
 
 fixed_ctrl_mask = ~((1ull << (fixed_pmc_cnt * FIXED_CTR_CTRL_BITS)) - 1);
+if ( version == 2 )
+fixed_ctrl_mask |= 0x444;
 fixed_counters_mask = ~((1ull << core2_get_bitwidth_fix_count()) - 1);
+global_ctrl_mask = ~1ULL << fixed_pmc_cnt) - 1) << 32) |
+ ((1ULL << arch_pmc_cnt) - 1));
 global_ovf_ctrl_mask = ~(0xC000 |
  (((1ULL << fixed_pmc_cnt) - 1) << 32) |
  ((1ULL << arch_pmc_cnt) - 1));
+if ( version > 2)
+/*
+ * Even though we don't support Uncore counters guests should be
+ * able to clear all available overflows.
+ */
+global_ovf_ctrl_mask &= ~(1ULL << 61);
 
 regs_sz = (sizeof(struct xen_pmu_intel_ctxt) - regs_off) +
   sizeof(uint64_t) * fixed_pmc_cnt +
-- 
1.7.1


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

[Xen-devel] [PULL 4/4] xen_disk: treat "vhd" as "vpc"

[Stefano Stabellini]

The Xen toolstack uses "vhd" to specify a disk in VHD format, however
the name of the driver in QEMU is "vpc". Replace "vhd" with "vpc", so
that QEMU can find the right driver to use for it.

Signed-off-by: Stefano Stabellini 
---
 hw/block/xen_disk.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 8146650..a48e726 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -825,6 +825,9 @@ static int blk_init(struct XenDevice *xendev)
 if (!strcmp("aio", blkdev->fileproto)) {
 blkdev->fileproto = "raw";
 }
+if (!strcmp("vhd", blkdev->fileproto)) {
+blkdev->fileproto = "vpc";
+}
 if (blkdev->mode == NULL) {
 blkdev->mode = xenstore_read_be_str(&blkdev->xendev, "mode");
 }
-- 
1.7.10.4


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

[Xen-devel] [PULL 3/4] xen/pass-through: correctly deal with RW1C bits

[Stefano Stabellini]

From: Jan Beulich 

Introduce yet another mask for them, so that the generic routine can
handle them, at once rendering xen_pt_pmcsr_reg_write() superfluous.

Signed-off-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
---
 hw/xen/xen_pt.h |2 ++
 hw/xen/xen_pt_config_init.c |   38 --
 2 files changed, 14 insertions(+), 26 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index 4f922f4..3749711 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -113,6 +113,8 @@ struct XenPTRegInfo {
 uint32_t res_mask;
 /* reg read only field mask (ON:RO/ROS, OFF:other) */
 uint32_t ro_mask;
+/* reg read/write-1-clear field mask (ON:RW1C/RW1CS, OFF:other) */
+uint32_t rw1c_mask;
 /* reg emulate field mask (ON:emu, OFF:passthrough) */
 uint32_t emu_mask;
 xen_pt_conf_reg_init init;
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 4fd7206..185a698 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -179,7 +179,8 @@ static int xen_pt_byte_reg_write(XenPCIPassthroughState *s, 
XenPTReg *cfg_entry,
 *data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
 
 /* create value for writing to I/O device register */
-*val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+*val = XEN_PT_MERGE_VALUE(*val, dev_value & ~reg->rw1c_mask,
+  throughable_mask);
 
 return 0;
 }
@@ -197,7 +198,8 @@ static int xen_pt_word_reg_write(XenPCIPassthroughState *s, 
XenPTReg *cfg_entry,
 *data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
 
 /* create value for writing to I/O device register */
-*val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+*val = XEN_PT_MERGE_VALUE(*val, dev_value & ~reg->rw1c_mask,
+  throughable_mask);
 
 return 0;
 }
@@ -215,7 +217,8 @@ static int xen_pt_long_reg_write(XenPCIPassthroughState *s, 
XenPTReg *cfg_entry,
 *data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
 
 /* create value for writing to I/O device register */
-*val = XEN_PT_MERGE_VALUE(*val, dev_value, throughable_mask);
+*val = XEN_PT_MERGE_VALUE(*val, dev_value & ~reg->rw1c_mask,
+  throughable_mask);
 
 return 0;
 }
@@ -633,6 +636,7 @@ static XenPTRegInfo xen_pt_emu_reg_header0[] = {
 .init_val   = 0x,
 .res_mask   = 0x0007,
 .ro_mask= 0x06F8,
+.rw1c_mask  = 0xF900,
 .emu_mask   = 0x0010,
 .init   = xen_pt_status_reg_init,
 .u.w.read   = xen_pt_word_reg_read,
@@ -944,6 +948,7 @@ static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
 .size   = 2,
 .res_mask   = 0xFFC0,
 .ro_mask= 0x0030,
+.rw1c_mask  = 0x000F,
 .init   = xen_pt_common_reg_init,
 .u.w.read   = xen_pt_word_reg_read,
 .u.w.write  = xen_pt_word_reg_write,
@@ -964,6 +969,7 @@ static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
 .offset = PCI_EXP_LNKSTA,
 .size   = 2,
 .ro_mask= 0x3FFF,
+.rw1c_mask  = 0xC000,
 .init   = xen_pt_common_reg_init,
 .u.w.read   = xen_pt_word_reg_read,
 .u.w.write  = xen_pt_word_reg_write,
@@ -1000,27 +1006,6 @@ static XenPTRegInfo xen_pt_emu_reg_pcie[] = {
  * Power Management Capability
  */
 
-/* write Power Management Control/Status register */
-static int xen_pt_pmcsr_reg_write(XenPCIPassthroughState *s,
-  XenPTReg *cfg_entry, uint16_t *val,
-  uint16_t dev_value, uint16_t valid_mask)
-{
-XenPTRegInfo *reg = cfg_entry->reg;
-uint16_t writable_mask = 0;
-uint16_t throughable_mask = get_throughable_mask(s, reg, valid_mask);
-uint16_t *data = cfg_entry->ptr.half_word;
-
-/* modify emulate register */
-writable_mask = reg->emu_mask & ~reg->ro_mask & valid_mask;
-*data = XEN_PT_MERGE_VALUE(*val, *data, writable_mask);
-
-/* create value for writing to I/O device register */
-*val = XEN_PT_MERGE_VALUE(*val, dev_value & ~PCI_PM_CTRL_PME_STATUS,
-  throughable_mask);
-
-return 0;
-}
-
 /* Power Management Capability reg static information table */
 static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 /* Next Pointer reg */
@@ -1051,11 +1036,12 @@ static XenPTRegInfo xen_pt_emu_reg_pm[] = {
 .size   = 2,
 .init_val   = 0x0008,
 .res_mask   = 0x00F0,
-.ro_mask= 0xE10C,
+.ro_mask= 0x610C,
+.rw1c_mask  = 0x8000,
 .emu_mask   = 0x810B,
 .init   = xen_pt_common_reg_init,
 .u.w.read   = xen_pt_word_reg_read,
-.u.w.write  = xen_pt_pmcsr_reg_write,
+.u.w.write  = xen_pt_word_reg_write,
 },
 {
 .size = 0,
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-dev

[Xen-devel] [PULL 2/4] xen/MSI-X: really enforce alignment

[Stefano Stabellini]

From: Jan Beulich 

The way the generic infrastructure works the intention of not allowing
unaligned accesses can't be achieved by simply setting .unaligned to
false. The benefit is that we can now replace the conditionals in
{get,set}_entry_value() by assert()-s.

Signed-off-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
---
 hw/xen/xen_pt_msi.c |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index e10cd2a..302a310 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -421,16 +421,14 @@ int xen_pt_msix_update_remap(XenPCIPassthroughState *s, 
int bar_index)
 
 static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
 {
-return !(offset % sizeof(*e->latch))
-   ? e->latch[offset / sizeof(*e->latch)] : 0;
+assert(!(offset % sizeof(*e->latch)));
+return e->latch[offset / sizeof(*e->latch)];
 }
 
 static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
 {
-if (!(offset % sizeof(*e->latch)))
-{
-e->latch[offset / sizeof(*e->latch)] = val;
-}
+assert(!(offset % sizeof(*e->latch)));
+e->latch[offset / sizeof(*e->latch)] = val;
 }
 
 static void pci_msix_write(void *opaque, hwaddr addr,
@@ -494,6 +492,12 @@ static uint64_t pci_msix_read(void *opaque, hwaddr addr,
 }
 }
 
+static bool pci_msix_accepts(void *opaque, hwaddr addr,
+ unsigned size, bool is_write)
+{
+return !(addr & (size - 1));
+}
+
 static const MemoryRegionOps pci_msix_ops = {
 .read = pci_msix_read,
 .write = pci_msix_write,
@@ -502,7 +506,13 @@ static const MemoryRegionOps pci_msix_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 .unaligned = false,
+.accepts = pci_msix_accepts
 },
+.impl = {
+.min_access_size = 4,
+.max_access_size = 4,
+.unaligned = false
+}
 };
 
 int xen_pt_msix_init(XenPCIPassthroughState *s, uint32_t base)
-- 
1.7.10.4


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

[Xen-devel] [PULL 1/4] xen/MSI-X: latch MSI-X table writes

[Stefano Stabellini]

From: Jan Beulich 

The remaining log message in pci_msix_write() is wrong, as there guest
behavior may only appear to be wrong: For one, the old logic didn't
take the mask-all bit into account. And then this shouldn't depend on
host device state (i.e. the host may have masked the entry without the
guest having done so). Plus these writes shouldn't be dropped even when
an entry gets unmasked. Instead, if they can't be made take effect
right away, they should take effect on the next unmasking or enabling
operation - the specification explicitly describes such caching
behavior.

Signed-off-by: Jan Beulich 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
---
 hw/xen/xen_pt.h |4 +--
 hw/xen/xen_pt_config_init.c |2 ++
 hw/xen/xen_pt_msi.c |   74 ---
 3 files changed, 32 insertions(+), 48 deletions(-)

diff --git a/hw/xen/xen_pt.h b/hw/xen/xen_pt.h
index c545280..4f922f4 100644
--- a/hw/xen/xen_pt.h
+++ b/hw/xen/xen_pt.h
@@ -187,13 +187,13 @@ typedef struct XenPTMSIXEntry {
 int pirq;
 uint64_t addr;
 uint32_t data;
-uint32_t vector_ctrl;
+uint32_t latch[4];
 bool updated; /* indicate whether MSI ADDR or DATA is updated */
-bool warned;  /* avoid issuing (bogus) warning more than once */
 } XenPTMSIXEntry;
 typedef struct XenPTMSIX {
 uint32_t ctrl_offset;
 bool enabled;
+bool maskall;
 int total_entries;
 int bar_index;
 uint64_t table_base;
diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 3d8686d..4fd7206 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -1499,6 +1499,8 @@ static int 
xen_pt_msixctrl_reg_write(XenPCIPassthroughState *s,
 xen_pt_msix_disable(s);
 }
 
+s->msix->maskall = *val & PCI_MSIX_FLAGS_MASKALL;
+
 debug_msix_enabled_old = s->msix->enabled;
 s->msix->enabled = !!(*val & PCI_MSIX_FLAGS_ENABLE);
 if (s->msix->enabled != debug_msix_enabled_old) {
diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
index 82de2bc..e10cd2a 100644
--- a/hw/xen/xen_pt_msi.c
+++ b/hw/xen/xen_pt_msi.c
@@ -25,6 +25,7 @@
 #define XEN_PT_GFLAGSSHIFT_DELIV_MODE 12
 #define XEN_PT_GFLAGSSHIFT_TRG_MODE   15
 
+#define latch(fld) latch[PCI_MSIX_ENTRY_##fld / sizeof(uint32_t)]
 
 /*
  * Helpers
@@ -314,7 +315,8 @@ static int msix_set_enable(XenPCIPassthroughState *s, bool 
enabled)
enabled);
 }
 
-static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr)
+static int xen_pt_msix_update_one(XenPCIPassthroughState *s, int entry_nr,
+  uint32_t vec_ctrl)
 {
 XenPTMSIXEntry *entry = NULL;
 int pirq;
@@ -332,6 +334,19 @@ static int xen_pt_msix_update_one(XenPCIPassthroughState 
*s, int entry_nr)
 
 pirq = entry->pirq;
 
+/*
+ * Update the entry addr and data to the latest values only when the
+ * entry is masked or they are all masked, as required by the spec.
+ * Addr and data changes while the MSI-X entry is unmasked get deferred
+ * until the next masked -> unmasked transition.
+ */
+if (pirq == XEN_PT_UNASSIGNED_PIRQ || s->msix->maskall ||
+(vec_ctrl & PCI_MSIX_ENTRY_CTRL_MASKBIT)) {
+entry->addr = entry->latch(LOWER_ADDR) |
+  ((uint64_t)entry->latch(UPPER_ADDR) << 32);
+entry->data = entry->latch(DATA);
+}
+
 rc = msi_msix_setup(s, entry->addr, entry->data, &pirq, true, entry_nr,
 entry->pirq == XEN_PT_UNASSIGNED_PIRQ);
 if (rc) {
@@ -357,7 +372,7 @@ int xen_pt_msix_update(XenPCIPassthroughState *s)
 int i;
 
 for (i = 0; i < msix->total_entries; i++) {
-xen_pt_msix_update_one(s, i);
+xen_pt_msix_update_one(s, i, msix->msix_entry[i].latch(VECTOR_CTRL));
 }
 
 return 0;
@@ -406,35 +421,15 @@ int xen_pt_msix_update_remap(XenPCIPassthroughState *s, 
int bar_index)
 
 static uint32_t get_entry_value(XenPTMSIXEntry *e, int offset)
 {
-switch (offset) {
-case PCI_MSIX_ENTRY_LOWER_ADDR:
-return e->addr & UINT32_MAX;
-case PCI_MSIX_ENTRY_UPPER_ADDR:
-return e->addr >> 32;
-case PCI_MSIX_ENTRY_DATA:
-return e->data;
-case PCI_MSIX_ENTRY_VECTOR_CTRL:
-return e->vector_ctrl;
-default:
-return 0;
-}
+return !(offset % sizeof(*e->latch))
+   ? e->latch[offset / sizeof(*e->latch)] : 0;
 }
 
 static void set_entry_value(XenPTMSIXEntry *e, int offset, uint32_t val)
 {
-switch (offset) {
-case PCI_MSIX_ENTRY_LOWER_ADDR:
-e->addr = (e->addr & ((uint64_t)UINT32_MAX << 32)) | val;
-break;
-case PCI_MSIX_ENTRY_UPPER_ADDR:
-e->addr = (uint64_t)val << 32 | (e->addr & UINT32_MAX);
-break;
-case PCI_MSIX_ENTRY_DATA:
-e->data = val;
-break;
-case PCI_MSIX_ENTRY_VECTOR_CTRL:
-e->vector_ctrl = val;
-break;
+if (!(offset % sizeof(*e

[Xen-devel] [PULL 0/4] xen-2015-12-22

[Stefano Stabellini]

The following changes since commit c3626ca7df027dabf0568284360a23faf18f0884:

  Update version for v2.5.0-rc3 release (2015-12-07 17:47:40 +)

are available in the git repository at:

  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-2015-12-22

for you to fetch changes up to fc3e493bc8e96ef4bf7ae4f035f43cb39382c936:

  xen_disk: treat "vhd" as "vpc" (2015-12-11 17:02:37 +)


Xen 2015/12/22


Jan Beulich (3):
  xen/MSI-X: latch MSI-X table writes
  xen/MSI-X: really enforce alignment
  xen/pass-through: correctly deal with RW1C bits

Stefano Stabellini (1):
  xen_disk: treat "vhd" as "vpc"

 hw/block/xen_disk.c |3 ++
 hw/xen/xen_pt.h |6 ++-
 hw/xen/xen_pt_config_init.c |   40 +++-
 hw/xen/xen_pt_msi.c |   86 ---
 4 files changed, 60 insertions(+), 75 deletions(-)

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

Re: [Xen-devel] [RFC 3/3] xen/common: memory: Move steal_page in common code

[Jan Beulich]

>>> On 17.12.15 at 17:31,  wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1786,6 +1786,57 @@ int assign_pages(
>  return -1;
>  }
>  
> +int steal_page(
> +struct domain *d, struct page_info *page, unsigned int memflags)
> +{

I think it would better go into common/memory.c - there's no
allocation involved here.

Jan


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

Re: [Xen-devel] [RFC 2/3] xen/common: memory: Add support for direct mapped domain in XEMEM_exchange

[Jan Beulich]

>>> On 17.12.15 at 17:31,  wrote:
> Direct mapped domain needs to retrieve the exact same underlying
> physical page when the region is re-populated.

In which case - what sense does it make for such a domain to
exchange memory (the primary purpose of which is to get
_different_ memory populated at the given GFN (range))?

Jan


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

Re: [Xen-devel] [RFC 0/3] xen/arm: Support XENMEM_exchange

[Jan Beulich]

>>> On 17.12.15 at 17:31,  wrote:
> I've looked at reworking XENMEM_exchange to avoid mfn_to_gmfn. My idea would
> be to allocate a temporary array to store the GFN between the two loops.
> However, the array would be quite large (the max default is 18 on ARM),
> so I don't know if it's acceptable.

This would quite clearly not be acceptable, yet I don't have an
alternative suggestion other then implementing M2P on ARM, which
you have already named as not an option.

Otoh I'm not sure what two loops you talk about - I find exactly
one use of mfn_to_gmfn() in memory_exchange(), and latching
the GFN earlier would be wrong (as it might change in parallel to
your processing).

Jan


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

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Jan Beulich]

>>> On 22.12.15 at 17:02,  wrote:
> How does it not make sense in this case? That's what Andrew and I are
> asking you to explain.

But I already explained it: The file isn't needed for booting.

Jan


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

Re: [Xen-devel] [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

[Stefano Stabellini]

On Tue, 22 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote:
> > The code builds, but of course it could not actually run on CPU_V6. But
> > the use case for me is building drivers/xen/grant-table.c, which can
> > only run on CPU_V7 anyway, so it is not a problem.
> 
> What I'm concerned about in this case is if you try to use instructions
> which are not supported by the CPU, even in assembly, the assembler
> will barf.
> 
> So, if we're building an ARMv6 + ARMv7 kernel, and you try to use
> LDREXB in generic code, even though you may intend it to only be
> executed on ARMv7, the assembler will error out.
> 
> We used to be able to work around that by passing -Wa,-march=armv7
> to the compiler for specific files, which would then tell the assembler
> to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops
> which override the command line.  So now the only way to do it is to
> override the assemblers selected archtecture using .arch pseudo-ops
> in the assembly code.
> 
> So, what I'm saying is that dropping the !ARMv6 dependency is not as
> simple as it would seem, and I'm nervous about including any such
> patches this close to Christmas and the merge window.
 
Sure, that's understandable.

Merge window aside, do you think that for the future it might be better
to change approach and write a Xen specific implementation of
sync_cmpxchg?  Like this older patch tried to do

http://marc.info/?l=linux-arm-kernel&m=138436406724990&w=2

?

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

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Doug Goldstein]

On 12/22/15 9:59 AM, Jan Beulich wrote:
 On 22.12.15 at 15:46,  wrote:
>> On 22/12/15 12:52, Jan Beulich wrote:
>> On 22.12.15 at 13:45,  wrote:
 On 12/21/15 9:35 AM, Jan Beulich wrote:
 On 21.12.15 at 16:20,  wrote:
>> On 12/21/15 8:51 AM, Jan Beulich wrote:
>> On 21.12.15 at 15:35,  wrote:
 On 12/21/15 6:11 AM, Jan Beulich wrote:
 On 18.12.15 at 22:35,  wrote:
>> Since we now support changing Xen options with Kconfig, we should 
>> save
>> the configuration that was used to build up Xen. This will save it in
>> /boot alongside the installed xen.gz and call it
>> xen-$(FULLVERSION).config
>>
>> Suggested-by: Ian Campbell 
>> Signed-off-by: Doug Goldstein 
>> ---
>>  xen/Makefile | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/xen/Makefile b/xen/Makefile
>> index 9023863..460b977 100644
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -58,6 +58,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>>  ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) $(D)$(BOOT_DIR)/$(T)$(Z)
>>  [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR)
>>  $(INSTALL_DATA) $(TARGET)-syms 
>> $(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
>> +$(INSTALL_DATA) $(KCONFIG_CONFIG) 
 $(D)$(BOOT_DIR)/$(T)-$(XEN_FULLVERSION).config
> Was it really suggested to put this into /boot? It has no business
> being there...
 Yes. By multiple people. Ian Campbell was the first person to suggest 
 it
 in that location.
>>> Okay, so I've looked it up, and no, he didn't. He just gave this as one
>>> possibility:
>>>
>>> "It occurred to me this morning that we probably ought to stash the 
>>> .config
>>>  somewhere on install in such a way that it can be associated with the 
>>> Xen
>>>  binary (i.e. with the same full suffix as the binary itself, not the
>>>  abridged symlink names), maybe as $(BOOT_DIR)/$(T)-
>>>  $(XEN_FULLVERSION).config?"
>>>
>>> But yes, I'm sorry for not noticing this as an undesirable place right
>>> away.
>> Ok well I'm at a loss here because the quote clearly shows him
>> suggesting that location. Do you have a suggested location because so
>> far I've just got a no from you on the only suggested location.
> Match the xen-syms location?
 I guess I fail to grasp the rationale behind not putting it in /boot.
>>> It's the other way around really - you'd have to provide a reason
>>> (other than "Linux does so too") for putting it in /boot.
>>
>> I disagree.
>>
>> Xen being consistent with Linux in this regard is in the best interest
>> of the users of Xen, as they end up finding similar information in
>> similar places.
>>
>> The onus is on you to provide a reason why we should deliberately do
>> something different.
> 
> I'm sorry, but no - why would we slavishly follow what Linux does, no
> matter whether it makes sense?
> 
> Jan
> 

How does it not make sense in this case? That's what Andrew and I are
asking you to explain.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] build: save generated config in /boot

[Jan Beulich]

>>> On 22.12.15 at 15:46,  wrote:
> On 22/12/15 12:52, Jan Beulich wrote:
> On 22.12.15 at 13:45,  wrote:
>>> On 12/21/15 9:35 AM, Jan Beulich wrote:
>>> On 21.12.15 at 16:20,  wrote:
> On 12/21/15 8:51 AM, Jan Beulich wrote:
> On 21.12.15 at 15:35,  wrote:
>>> On 12/21/15 6:11 AM, Jan Beulich wrote:
>>> On 18.12.15 at 22:35,  wrote:
> Since we now support changing Xen options with Kconfig, we should save
> the configuration that was used to build up Xen. This will save it in
> /boot alongside the installed xen.gz and call it
> xen-$(FULLVERSION).config
>
> Suggested-by: Ian Campbell 
> Signed-off-by: Doug Goldstein 
> ---
>  xen/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/Makefile b/xen/Makefile
> index 9023863..460b977 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -58,6 +58,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
>   ln -f -s $(T)-$(XEN_FULLVERSION)$(Z) $(D)$(BOOT_DIR)/$(T)$(Z)
>   [ -d "$(D)$(DEBUG_DIR)" ] || $(INSTALL_DIR) $(D)$(DEBUG_DIR)
>   $(INSTALL_DATA) $(TARGET)-syms 
> $(D)$(DEBUG_DIR)/$(T)-syms-$(XEN_FULLVERSION)
> + $(INSTALL_DATA) $(KCONFIG_CONFIG) 
>>> $(D)$(BOOT_DIR)/$(T)-$(XEN_FULLVERSION).config
 Was it really suggested to put this into /boot? It has no business
 being there...
>>> Yes. By multiple people. Ian Campbell was the first person to suggest it
>>> in that location.
>> Okay, so I've looked it up, and no, he didn't. He just gave this as one
>> possibility:
>>
>> "It occurred to me this morning that we probably ought to stash the 
>> .config
>>  somewhere on install in such a way that it can be associated with the 
>> Xen
>>  binary (i.e. with the same full suffix as the binary itself, not the
>>  abridged symlink names), maybe as $(BOOT_DIR)/$(T)-
>>  $(XEN_FULLVERSION).config?"
>>
>> But yes, I'm sorry for not noticing this as an undesirable place right
>> away.
> Ok well I'm at a loss here because the quote clearly shows him
> suggesting that location. Do you have a suggested location because so
> far I've just got a no from you on the only suggested location.
 Match the xen-syms location?
>>> I guess I fail to grasp the rationale behind not putting it in /boot.
>> It's the other way around really - you'd have to provide a reason
>> (other than "Linux does so too") for putting it in /boot.
> 
> I disagree.
> 
> Xen being consistent with Linux in this regard is in the best interest
> of the users of Xen, as they end up finding similar information in
> similar places.
> 
> The onus is on you to provide a reason why we should deliberately do
> something different.

I'm sorry, but no - why would we slavishly follow what Linux does, no
matter whether it makes sense?

Jan


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

Re: [Xen-devel] [PATCH RESEND v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN

[Russell King - ARM Linux]

On Tue, Dec 22, 2015 at 03:45:19PM +, Stefano Stabellini wrote:
> The code builds, but of course it could not actually run on CPU_V6. But
> the use case for me is building drivers/xen/grant-table.c, which can
> only run on CPU_V7 anyway, so it is not a problem.

What I'm concerned about in this case is if you try to use instructions
which are not supported by the CPU, even in assembly, the assembler
will barf.

So, if we're building an ARMv6 + ARMv7 kernel, and you try to use
LDREXB in generic code, even though you may intend it to only be
executed on ARMv7, the assembler will error out.

We used to be able to work around that by passing -Wa,-march=armv7
to the compiler for specific files, which would then tell the assembler
to accept ARMv7 instructions, but modern GCC output .arch pseudo-ops
which override the command line.  So now the only way to do it is to
override the assemblers selected archtecture using .arch pseudo-ops
in the assembly code.

So, what I'm saying is that dropping the !ARMv6 dependency is not as
simple as it would seem, and I'm nervous about including any such
patches this close to Christmas and the merge window.

I've recently been through a run of "apply this patch, no it's wrong,
drop it, apply the next version, no it's still wrong, drop it again."
So, today is the last day I'm accepting _known_ good patches into my
tree for the 4.5 merge window.  This is not yet a known good patch
because it hasn't been through several iterations of testing - and I
don't want to be adding and removing patches from my tree over
Christmas.

I'd rather leave my tree in a known good state before Christmas so
that those who want to fiddle with the kernel over the holiday break
can do so without having the hassle of trees containing partially
tested patches.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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