Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Thu, Feb 09, 2017 at 12:42:09PM -0700, Tamas K Lengyel wrote:
> On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall  wrote:
> > Hi Tamas,
> >
> > On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
> >>
> >> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
> >>>
> >>> On 08/02/2017 23:28, Tamas K Lengyel wrote:
> 
>  On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
>  wrote:
> >>>
> >>> You haven't understood my point. Xen is currently emulating PSCI call for
> >>> the guest to allow powering up and down the CPUs and other stuff. If you
> >>> decide to trap all the SMCs, you would have to handle them.
> >>
> >>
> >> Sure, it's more work on the monitor side, but other then that, what's
> >> the problem?
> >
> >
> > Because you will have to introduce hypercalls to get all the necessary
> > information from Xen that will not be available from outside.
>
> > Given that SMC has been designed to target different services (PSCI, Trusted
> > OS...) it would be normal to have monitor app only monitoring a certain set
> > of SMC call. You cannot deny a such use case as it would avoid an monitor
> > app to handle every single call that would be consumed by XEN but not
> > forwarded to the secure firmware.
> >
> 
> I have nothing against introducing a fine-tune option to the SMC
> monitoring system so the monitor app can determine if it wants all
> SMCs or only a subset. At the moment I don't know of any usecase that
> would require this option. I certainly don't need it. If this option
> gets implemented by someone, I would be happy to take it.

Well, the reason it would be useful is the other way around.
On for example ZynqMP, enabling the monitor is useless since it will
turn off the ability to use the vital FW APIs needed for device
passthrough.

So the monitor only works for PV guests that call SMC APIs to some
imaginary Firmware.

While a monitor that didn't insist in consuming all SMC calls,
could very well be useful for monitoring/tracing purposes or
other stuff even with guests that actually use a "real" FW API.

I don't think we need to implement support for the latter right away,
we can incrementally add support for these things (I hope).

Cheers,
Edgar





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

Re: [Xen-devel] [PATCH v3] xen-netfront: Improve error handling during initialization

[David Miller]

From: Ross Lagerwall 
Date: Wed, 8 Feb 2017 10:57:37 +

> This fixes a crash when running out of grant refs when creating many
> queues across many netdevs.
> 
> * If creating queues fails (i.e. there are no grant refs available),
> call xenbus_dev_fatal() to ensure that the xenbus device is set to the
> closed state.
> * If no queues are created, don't call xennet_disconnect_backend as
> netdev->real_num_tx_queues will not have been set correctly.
> * If setup_netfront() fails, ensure that all the queues created are
> cleaned up, not just those that have been set up.
> * If any queues were set up and an error occurs, call
> xennet_destroy_queues() to clean up the napi context.
> * If any fatal error occurs, unregister and destroy the netdev to avoid
> leaving around a half setup network device.
> 
> Signed-off-by: Ross Lagerwall 

Applied.

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

[Xen-devel] [linux-linus test] 105663: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-i386-xl   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-amd64-amd64-pair  21 guest-migrate/src_host/dst_host fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-raw3 host-install(3)   broken baseline untested
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  4 host-ping-check-native  fail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linuxd966564fcdc19e13eb6ba1fbe6b8101070339c3d
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  581 days
Failing since 59348  2015-07-10 04:24:05 Z  580 days  261 attempts
Testing same since   105663  2017-02-09 10:04:29 Z0 days1 attempts


7569 people touched revisions under test,
not listing them all

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

[Xen-devel] [xen-4.6-testing test] 105664: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104585

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
REGR. vs. 104585
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 104585
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104585
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104585
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104585
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104585
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104585
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104585
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104585

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  576f319a804bce8c9a7fb70a042f873f5eaf0151
baseline version:
 xen  09f521a077024d5955d766eef7a040d2af928ec2

Last test of basis   104585  2017-01-22 08:19:51 Z   18 days
Testing same since   105664  2017-02-09 10:14:26 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Joao Martins 

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 11:43 AM, Stefano Stabellini
 wrote:
> On Thu, 9 Feb 2017, Tamas K Lengyel wrote:
>> On Thu, Feb 9, 2017 at 11:22 AM, Stefano Stabellini
>>  wrote:
>> > On Thu, 9 Feb 2017, Edgar E. Iglesias wrote:
>> >> On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
>> >> > On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
>> >> > > On Thu, 9 Feb 2017, Julien Grall wrote:
>> >> > > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
>> >> > > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
>> >> > > > >  wrote:
>> >> > > > > > Hi Tamas,
>> >> > > > > >
>> >> > > > > > Can you please try to configure your e-mail client to use '>' 
>> >> > > > > > rather than
>> >> > > > > > '
>> >> > > > > > '? It makes quite hard to read the e-mail.
>> >> > > > >
>> >> > > > > Hm, not sure why it switched but should be fine now.
>> >> > > > >
>> >> > > > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
>> >> > > > > > > > 
>> >> > > > > > > wrote:
>> >> > > > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. 
>> >> > > > > > > Iglesias wrote:
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > > If platform_hvc() consumes an SMC, it's considered part 
>> >> > > > > > > of the Xen
>> >> > > > > > > API.
>> >> > > > > > > Visible but not filterable by a monitor.
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > Platforms can then dictate which SMC calls are better 
>> >> > > > > > > handled within
>> >> > > > > > > Xen and
>> >> > > > > > > which ones can be exposed to dom0 user-space.
>> >> > > > > > >
>> >> > > > > > > In addition, there could be a hypercall to disable 
>> >> > > > > > > platform specific
>> >> > > > > > > handling
>> >> > > > > > > in Xen alltogether for a given guest. Then everything 
>> >> > > > > > > goes to dom0
>> >> > > > > > > user-space.
>> >> > > > > > >
>> >> > > > > > > It's a little messy...
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > That is messy and I would not want any SMCs reaching the 
>> >> > > > > > > firmware when
>> >> > > > > > > the monitor application is in use. The monitor interface is 
>> >> > > > > > > disabled by
>> >> > > > > > > default and there aren't any known usecases where the SMC has 
>> >> > > > > > > to reach
>> >> > > > > > > both the firmware and the monitor application as well. So I 
>> >> > > > > > > think it is
>> >> > > > > > > safe to just make the two things mutually exclusive.
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > If you look at the SMC Calling Convention [1] both HVC and SMC 
>> >> > > > > > are
>> >> > > > > > considered a conduit for service call to the secure firmware or
>> >> > > > > > hypervisor.
>> >> > > > > > It would be up to the hypervisor deciding what to do.
>> >> > > > > >
>> >> > > > > > Lets imagine the guest is deciding to use HVC to access the 
>> >> > > > > > secure
>> >> > > > > > firmware
>> >> > > > > > (AFAIU this patch series is adding that), are you going to 
>> >> > > > > > monitor all the
>> >> > > > > > HVCs (including hypercall)?
>> >> > > > >
>> >> > > > > There are some fundamental differences between HVC and SMC calls
>> >> > > > > though. An HVC can only land in the hypervisor, so as a 
>> >> > > > > hypercall, I
>> >> > > > > would expect it to be something I can deny via XSM. That is a
>> >> > > > > sufficient option for now to block the path to the firmware. If 
>> >> > > > > we end
>> >> > > > > up needing to support an application that uses that hypercall for
>> >> > > > > something critical, then yes, it would also need to be hooked 
>> >> > > > > into the
>> >> > > > > monitor system. At the moment this is not necessary.
>> >> > > >
>> >> > > > My point is not about what is necessary at the moment. But what is 
>> >> > > > right
>> >> > > > things to do. If you look at the spec, HVC are not only for 
>> >> > > > hypercall, but any
>> >> > > > other kind of services. Why would you deny something that is valid 
>> >> > > > from the
>> >> > > > specification (see 5.2.1)?
>> >> > > >
>> >> > > > "The SMC calling convention, however, does not specify which 
>> >> > > > instruction
>> >> > > > (either SMC or HVC) to use to invoke a
>> >> > > > particular service."
>> >> > >
>> >> > > To have a generic solution, we need a way to specify a set of HVC/SMC
>> >> > > calls that get monitored and a set that get handled in Xen (platform
>> >> > > specific or otherwise). I think it is OK not to do both, at least at 
>> >> > > the
>> >> > > beginning, but we might want to add that feature in the future.
>> >> > >
>> >> > > As much as I would like to see that, in respect to this series, I 
>> >> > > don't
>> >> > > think we should ask Edgar to introduce such a 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

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

Re: [Xen-devel] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

[Håkon Alstadheim]

Den 2017-02-09 18:30, skrev Roger Pau Monné:

On Mon, Feb 06, 2017 at 12:31:20AM +0100, Håkon Alstadheim wrote:
I get the BUG below in dom0 when trying to start a windows 10 domu 
(hvm,
with some pv-drivers installed ) . Below is "xl info", then comes 
dmesg

output, and finally domu config attached at end.

This domain is started very rarely, so may have been broken for some
time. All my other domains ar linux. This message is just a data-point
for whoever is interested, with possibly more data if anybody wants to
ask me anything. NOT expecting quick resolution of this :-/ .

The domain boots part of the way, screen resolution gets changed and
then it keeps spinning for ~ 5 seconds before stopping.

[...]

[339809.663061] br0: port 12(vif7.0) entered blocking state
[339809.663063] br0: port 12(vif7.0) entered disabled state
[339809.663123] device vif7.0 entered promiscuous mode
[339809.664885] IPv6: ADDRCONF(NETDEV_UP): vif7.0: link is not ready
[339809.742522] br0: port 13(vif7.0-emu) entered blocking state
[339809.742523] br0: port 13(vif7.0-emu) entered disabled state
[339809.742573] device vif7.0-emu entered promiscuous mode
[339809.744386] br0: port 13(vif7.0-emu) entered blocking state
[339809.744388] br0: port 13(vif7.0-emu) entered forwarding state
[339864.059095] xen-blkback: backend/vbd/7/768: prepare for reconnect
[339864.138002] xen-blkback: backend/vbd/7/768: using 1 queues, 
protocol

1 (x86_64-abi)
[339864.241039] xen-blkback: backend/vbd/7/832: prepare for reconnect
[339864.337997] xen-blkback: backend/vbd/7/832: using 1 queues, 
protocol

1 (x86_64-abi)
[339875.245306] vif vif-7-0 vif7.0: Guest Rx ready
[339875.245345] IPv6: ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes 
ready

[339875.245391] br0: port 12(vif7.0) entered blocking state
[339875.245395] br0: port 12(vif7.0) entered forwarding state
[339894.122151] [ cut here ]
[339894.122169] kernel BUG at block/bio.c:1786!
[339894.122173] invalid opcode:  [#1] SMP
[339894.122176] Modules linked in: xt_physdev iptable_filter ip_tables
x_tables nfsd auth_rpcgss oid_registry nfsv4 dns_resolver nfsv3 
nfs_acl

binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
crc32c_intel pcspkr serio_raw i2c_i801 i2c_smbus iTCO_wdt
iTCO_vendor_support amdgpu drm_kms_helper syscopyarea bcache 
input_leds
sysfillrect sysimgblt fb_sys_fops ttm drm uas shpchp ipmi_ssif 
rtc_cmos

acpi_power_meter wmi tun snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer 
snd

usbip_host usbip_core pktcdvd tmem lpc_ich xen_wdt nct6775 hwmon_vid
dm_zero dm_thin_pool dm_persistent_data dm_bio_prison dm_service_time
dm_round_robin dm_queue_length dm_multipath dm_log_userspace cn
virtio_pci virtio_scsi virtio_blk virtio_console virtio_balloon
[339894.122233]  xts gf128mul aes_x86_64 cbc sha512_generic
sha256_generic sha1_generic libiscsi scsi_transport_iscsi virtio_net
virtio_ring virtio tg3 libphy e1000 fuse overlay nfs lockd grace 
sunrpc

jfs multipath linear raid10 raid1 raid0 dm_raid raid456
async_raid6_recov async_memcpy async_pq async_xor xor async_tx 
raid6_pq

dm_snapshot dm_bufio dm_crypt dm_mirror dm_region_hash dm_log dm_mod
hid_sunplus hid_sony hid_samsung hid_pl hid_petalynx hid_monterey
hid_microsoft hid_logitech ff_memless hid_gyration hid_ezkey 
hid_cypress

hid_chicony hid_cherry hid_a4tech sl811_hcd xhci_plat_hcd ohci_pci
ohci_hcd uhci_hcd aic94xx lpfc qla2xxx aacraid sx8 DAC960 hpsa cciss
3w_9xxx 3w_ mptsas mptfc scsi_transport_fc mptspi mptscsih mptbase
atp870u dc395x qla1280 imm parport dmx3191d sym53c8xx gdth initio 
BusLogic

[339894.122325]  arcmsr aic7xxx aic79xx sg pdc_adma sata_inic162x
sata_mv sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv 
sata_via
sata_svw sata_sil24 sata_sil sata_promise pata_sis usbhid led_class 
igb

ptp dca i2c_algo_bit ehci_pci ehci_hcd xhci_pci megaraid_sas xhci_hcd
[339894.122350] CPU: 3 PID: 23514 Comm: 7.hda-0 Tainted: GW
 4.9.8-gentoo #1
[339894.122353] Hardware name: ASUSTeK COMPUTER INC. Z10PE-D8
WS/Z10PE-D8 WS, BIOS 3304 06/22/2016
[339894.122358] task: 880244b55b00 task.stack: c90042fcc000
[339894.122361] RIP: e030:[]  []
bio_split+0x9/0x89
[339894.122370] RSP: e02b:c90042fcfb18  EFLAGS: 00010246
[339894.122373] RAX: 00a8 RBX: 8802433ee900 RCX:
88023f537080
[339894.122377] RDX: 0240 RSI:  RDI:
8801fc8b7890
[339894.122380] RBP: c90042fcfba8 R08:  R09:
52da
[339894.122383] R10: 0002 R11: 0005803f R12:
8801fc8b7890
[339894.122387] R13: 00a8 R14: c90042fcfbb8 R15:

[339894.122394] FS:  () GS:8802498c()
knlGS:8802498c
[339894.122398] CS:  e033 DS:  ES:  CR0: 80050033
[339894.122401] CR2: 7f99b78e3349 CR3: 000216d43000 CR4:
00042660
[339894.122405] Stack:
[339894.122407]  

Re: [Xen-devel] [PATCH] xen-netfront: Rework the fix for Rx stall during OOM and network stress

[David Miller]

From: Vineeth Remanan Pillai 
Date: Tue, 7 Feb 2017 18:59:01 +

> The commit 90c311b0eeea ("xen-netfront: Fix Rx stall during network
> stress and OOM") caused the refill timer to be triggerred almost on
> all invocations of xennet_alloc_rx_buffers for certain workloads.
> This reworks the fix by reverting to the old behaviour and taking into
> consideration the skb allocation failure. Refill timer is now triggered
> on insufficient requests or skb allocation failure.
> 
> Signed-off-by: Vineeth Remanan Pillai 
> Fixes: 90c311b0eeea (xen-netfront: Fix Rx stall during network stress and OOM)
> Reported-by: Boris Ostrovsky 

Applied.

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 1:01 PM, Edgar E. Iglesias
 wrote:
> On Thu, Feb 09, 2017 at 12:42:09PM -0700, Tamas K Lengyel wrote:
>> On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall  wrote:
>> > Hi Tamas,
>> >
>> > On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
>> >>
>> >> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
>> >>>
>> >>> On 08/02/2017 23:28, Tamas K Lengyel wrote:
>> 
>>  On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
>>  wrote:
>> >>>
>> >>> You haven't understood my point. Xen is currently emulating PSCI call for
>> >>> the guest to allow powering up and down the CPUs and other stuff. If you
>> >>> decide to trap all the SMCs, you would have to handle them.
>> >>
>> >>
>> >> Sure, it's more work on the monitor side, but other then that, what's
>> >> the problem?
>> >
>> >
>> > Because you will have to introduce hypercalls to get all the necessary
>> > information from Xen that will not be available from outside.
>>
>> > Given that SMC has been designed to target different services (PSCI, 
>> > Trusted
>> > OS...) it would be normal to have monitor app only monitoring a certain set
>> > of SMC call. You cannot deny a such use case as it would avoid an monitor
>> > app to handle every single call that would be consumed by XEN but not
>> > forwarded to the secure firmware.
>> >
>>
>> I have nothing against introducing a fine-tune option to the SMC
>> monitoring system so the monitor app can determine if it wants all
>> SMCs or only a subset. At the moment I don't know of any usecase that
>> would require this option. I certainly don't need it. If this option
>> gets implemented by someone, I would be happy to take it.
>
> Well, the reason it would be useful is the other way around.
> On for example ZynqMP, enabling the monitor is useless since it will
> turn off the ability to use the vital FW APIs needed for device
> passthrough.
>
> So the monitor only works for PV guests that call SMC APIs to some
> imaginary Firmware.
>
> While a monitor that didn't insist in consuming all SMC calls,
> could very well be useful for monitoring/tracing purposes or
> other stuff even with guests that actually use a "real" FW API.
>
> I don't think we need to implement support for the latter right away,
> we can incrementally add support for these things (I hope).
>

Certainly, as I said I have nothing against adding such a feature. All
I'm saying is that I don't know of any usecase that requires that
option at the moment, so I would be OK with just making the two
exclusive. If someone finds the time to implement such fine-tuning,
I'm all for it.

Tamas

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Tamas K Lengyel]

On Thu, Feb 9, 2017 at 11:39 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 02/09/2017 06:11 PM, Tamas K Lengyel wrote:
>>
>> On Wed, Feb 8, 2017 at 5:08 PM, Julien Grall  wrote:
>>>
>>> On 08/02/2017 23:28, Tamas K Lengyel wrote:

 On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall 
 wrote:
>>>
>>> You haven't understood my point. Xen is currently emulating PSCI call for
>>> the guest to allow powering up and down the CPUs and other stuff. If you
>>> decide to trap all the SMCs, you would have to handle them.
>>
>>
>> Sure, it's more work on the monitor side, but other then that, what's
>> the problem?
>
>
> Because you will have to introduce hypercalls to get all the necessary
> information from Xen that will not be available from outside.
>
> Given that SMC has been designed to target different services (PSCI, Trusted
> OS...) it would be normal to have monitor app only monitoring a certain set
> of SMC call. You cannot deny a such use case as it would avoid an monitor
> app to handle every single call that would be consumed by XEN but not
> forwarded to the secure firmware.
>

I have nothing against introducing a fine-tune option to the SMC
monitoring system so the monitor app can determine if it wants all
SMCs or only a subset. At the moment I don't know of any usecase that
would require this option. I certainly don't need it. If this option
gets implemented by someone, I would be happy to take it.

Tamas

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-i386-xl   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
baseline untested
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 14 guest-saverestorefail blocked in 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linux507053d23b886fdedc8336ca2233883fe4c82aa2
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  581 days
Failing since 59348  2015-07-10 04:24:05 Z  580 days  260 attempts
Testing same since   105655  2017-02-09 02:00:55 Z0 days1 attempts


7569 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] 4.7.2 / 4.6.5 preparations

[Wei Liu]

On Thu, Feb 09, 2017 at 02:52:49AM -0700, Jan Beulich wrote:
> All,
> 
> these stable releases are due in about 3 weeks time. Please indicate
> backports you consider necessary but find still missing. Commits
> already marked for backporting:
> 
> e719192026 xen: credit2: never consider CPUs outside of our cpupool.
> (for 4.7.5 only, unless anyone cares to also provide 4.6 backports of
> not just this, but also 548db87428 and 7478ebe160+ad5808d905, if
> applicable in the first place)
> 
> 30921dc2df x86/ept: allow write-combining on !mfn_valid() MMIO mappings again
> 

Nothing for mini-os.

> Jan
> 

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

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

[Chao Gao]

On Thu, Feb 09, 2017 at 08:51:46AM +, Xuquan (Quan Xu) wrote:
>On February 08, 2017 4:22 PM, Chao Gao wrote:
>>On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote:
>>>On February 08, 2017 4:52 PM, Jan Beulich wrote:
>>> On 08.02.17 at 09:27,  wrote:
> Assumed vCPU is in guest_mode..
> When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(),
> then
> __vmx_deliver_posted_interrupt() to deliver interrupt, but no vmexit
> (also no
> vcpu_kick() )..
> In __vmx_deliver_posted_interrupt(), it is __conditional__ to
> deliver posted interrupt. if posted interrupt is not delivered, the
> posted interrupt is pending until next VM entry -- by PIR to vIRR..
>
> one condition is :
> In __vmx_deliver_posted_interrupt(),  ' if (
> !test_and_set_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))' ..
>
> Specifically, we did verify it by RES interrupt, which is used for
> smp_reschedule_interrupt..
> We even cost more time to deliver RES interrupt than no-apicv in
average..
>
> If RES interrupt (no. 1) is delivered by posted way (the vcpu is
> still guest_mode).. when tries to deliver next-coming RES interrupt
> (no. 2) by posted way, The next-coming RES interrupt (no. 2) is not
> delivered, as we set the VCPU_KICK_SOFTIRQ bit when we deliver RES
>>interrupt (no.
> 1)..
>
> Then the next-coming RES interrupt (no. 2) is pending until next VM
> entry -- by PIR to vIRR..
>
>
> We can fix it as below(I don't think this is a best one, it is
> better to set the VCPU_KICK_SOFTIRQ bit, but not test it):
>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1846,7 +1846,7 @@ static void
__vmx_deliver_posted_interrupt(struct vcpu *v)
>  {
>  unsigned int cpu = v->processor;
>
> -if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ,
_pending(cpu))
> +if ( !test_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
>   && (cpu != smp_processor_id()) )
>  send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
>  }

While I don't think I fully understand your description,
>>>
>>>Sorry!!
>>>
the line you change
here has always been puzzling me: If we were to raise a softirq here,
we ought to call cpu_raise_softirq() instead of partly open coding what it
>>does.
So I think not marking that softirq pending (but doing this
incompletely) is a valid change in any case.
>>>
>>>As comments in pi_notification_interrupt()  --
>>>xen/arch/x86/hvm/vmx/vmx.c 
>>> *
>>> * we need to set VCPU_KICK_SOFTIRQ for the current cpu, just like
>>> * __vmx_deliver_posted_interrupt(). So the pending interrupt in
>>PIRR will
>>> * be synced to vIRR before VM-Exit in time.
>>> *
>>>
>>>
>>>I think setting VCPU_KICK_SOFTIRQ bit -- the pending interrupt in PIRR will
>>be synced to vIRR before VM-Exit in time.
>>>That's also why i said it is better to set the VCPU_KICK_SOFTIRQ bit, but
>>not test it..
>>>
>>
>>I think there is a typo. It should be "before VM-Entry in time". It set
>>VCPU_KICK_SOFTIRQ bit only to jump to vmx_do_vmentry again instead of
>>entering guest directly. Jumping to vmx_do_vmentry again can re-sync the
>>PIR to vIRR in vmx_intr_assist(). 
>
>impressive analysis..
>chao, could you show the related code?
>

In xen/arch/x86/vmx/entry.S, 
.Lvmx_do_vmentry:
call vmx_intr_assist
... 
cli
cmp %ecx,(%rdx,%rax,1)
jnz .Lvmx_process_softirqs
and 
.Lvmx_process_softirqs:
sti
call do_softirq
jmp .Lvmx_do_vmentry

In vmx_intr_assist(), PIR is synced to vIRR. After vmx_intr_assist(), 
if some interrupts are posted in PIR, VCPU_KICK_SOFTIRQ is set 
in pi_nofitication_interrupt() and it will jump to vmx_process_softirqs
and jump to vmx_do_vmentry again.

Thanks
Chao

>Quan
>
>
>>In root-mode, cpu treat the pi notification
>>interrupt as normal interrupt, so cpu will run the interrupt handler
>>pi_notification_interrupt() instead of syncing PIR to vIRR automatically.
>>Receiving a pi notificatio interrupt means some interrupts have been
>>posted in PIR. Setting that bit is to deliver these new arrival interrupts
>>before this VM-entry.
>>
>

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

Re: [Xen-devel] [PATCH v6 04/24] x86: refactor psr: implement CPU init and free flow.

[Yi Sun]

On 17-02-08 11:34:16, Konrad Rzeszutek Wilk wrote:
> > +/* No valid value so do not enable feature. */
> > +if ( !regs.a || !regs.b )
> 
> You use regs.d below. Would it make sense to check for that value as
> well?
> 
> Or is a value of 0 for cox_max OK? I would think so, but not exactly
> sure.
> 
Sorry, this is a typo.

> > +{
> > +free_feature(socket_info + socket);
> > +}
> > +}
> > +
> > +static void __init init_psr(void)
> 
> Why don't we make this return an value? And then the init
> code(psr_presmp_init) can just return an error?

Because we need init CMT related things besides CAT in psr_presmp_init. So no
matter init_psr return value, we need call psr_cpu_init to call psr_assoc_init.
We will check if socket_info in following functions called to avoid error.

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

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[Dario Faggioli]

On Thu, 2017-02-09 at 02:17 -0700, Jan Beulich wrote:
> > > > On 08.02.17 at 19:55,  wrote:
> > I've only quickly tested it so far, and I have to leave now. I'll
> > play
> > with it a bit more tomorrow morning and let you know how it goes.
> 
> Well, looking at the topmost commit, you've clearly missed the
> follow-up fix (ad5808d905), which I did fold into that backport
> right away. 
>
Yes, in fact, I've just added it now (will re-push to the branch after
testing).

> I'm going to commit what I have later today, and
> I'll pull in the one extra backport next time round.
> 
Ok, sure.

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

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

[Xen-devel] [PATCH v2 08/12] libxl: carve out memory specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the memory
related functions to libxl_mem.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile|   2 +-
 tools/libxl/libxl.c | 577 --
 tools/libxl/libxl_mem.c | 601 
 3 files changed, 602 insertions(+), 578 deletions(-)
 create mode 100644 tools/libxl/libxl_mem.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index dd7aa41..4b05e34 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -137,7 +137,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
-   libxl_cpupool.o libxl_sched.o \
+   libxl_cpupool.o libxl_mem.o libxl_sched.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 20ae61a..f9aad9b 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -15,7 +15,6 @@
 #include "libxl_osdeps.h"
 
 #include "libxl_internal.h"
-#include "libxl_arch.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
 
@@ -1952,582 +1951,6 @@ out:
 }
 
 
/**/
-
-/*
- * Set the maximum memory size of the domain in the hypervisor. There is no
- * change of the current memory size involved. The specified memory size can
- * even be above the configured maxmem size of the domain, but the related
- * Xenstore entry memory/static-max isn't modified!
- */
-int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t domid, uint64_t max_memkb)
-{
-GC_INIT(ctx);
-char *mem, *endptr;
-uint64_t memorykb, size;
-char *dompath = libxl__xs_get_dompath(gc, domid);
-int rc = 1;
-libxl__domain_userdata_lock *lock = NULL;
-libxl_domain_config d_config;
-
-libxl_domain_config_init(_config);
-
-CTX_LOCK;
-
-lock = libxl__lock_domain_userdata(gc, domid);
-if (!lock) {
-rc = ERROR_LOCK_FAIL;
-goto out;
-}
-
-mem = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/memory/target", dompath));
-if (!mem) {
-LOGED(ERROR, domid, "Cannot get memory info from %s/memory/target",
-  dompath);
-goto out;
-}
-memorykb = strtoull(mem, , 10);
-if (*endptr != '\0') {
-LOGED(ERROR, domid, "Invalid memory %s from %s/memory/target\n",
-  mem, dompath);
-goto out;
-}
-
-if (max_memkb < memorykb) {
-LOGED(ERROR, domid,
-  "memory_static_max must be greater than or or equal to 
memory_dynamic_max");
-goto out;
-}
-
-rc = libxl__get_domain_configuration(gc, domid, _config);
-if (rc < 0) {
-LOGE(ERROR, "unable to retrieve domain configuration");
-goto out;
-}
-
-rc = libxl__arch_extra_memory(gc, _config.b_info, );
-if (rc < 0) {
-LOGE(ERROR, "Couldn't get arch extra constant memory size");
-goto out;
-}
-
-rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + size);
-if (rc != 0) {
-LOGED(ERROR, domid,
-  "xc_domain_setmaxmem domid=%d memkb=%"PRIu64" failed ""rc=%d\n",
-  domid, max_memkb + size, rc);
-goto out;
-}
-
-rc = 0;
-out:
-libxl_domain_config_dispose(_config);
-if (lock) libxl__unlock_domain_userdata(lock);
-CTX_UNLOCK;
-GC_FREE;
-return rc;
-}
-
-static int libxl__fill_dom0_memory_info(libxl__gc *gc, uint64_t *target_memkb,
-uint64_t *max_memkb)
-{
-int rc;
-libxl_dominfo info;
-libxl_physinfo physinfo;
-char *target = NULL, *staticmax = NULL, *endptr = NULL;
-char *target_path = "/local/domain/0/memory/target";
-char *max_path = "/local/domain/0/memory/static-max";
-xs_transaction_t t;
-libxl_ctx *ctx = libxl__gc_owner(gc);
-
-libxl_dominfo_init();
-
-retry_transaction:
-t = xs_transaction_start(ctx->xsh);
-
-target = libxl__xs_read(gc, t, target_path);
-staticmax = libxl__xs_read(gc, t, max_path);
-if (target && staticmax) {
-rc = 0;
-goto out;
-}
-
-if (target) {
-*target_memkb = strtoull(target, , 10);
-if (*endptr != '\0') {
-LOGED(ERROR, 0, "Invalid memory target %s from %s\n", target,
- target_path);
-rc = ERROR_FAIL;
-goto out;
-}
-}
-
-if (staticmax) {
-*max_memkb = strtoull(staticmax, , 10);
-if (*endptr != '\0') {
-LOGED(ERROR, 0, "Invalid memory static-max %s from %s\n",
- staticmax,
- max_path);
-

Re: [Xen-devel] [PATCH v2 01/12] libxl: adjust copyright comment of libxl.c

[Wei Liu]

On Thu, Feb 09, 2017 at 10:30:14AM +0100, Juergen Gross wrote:
> The copyright of libxl.c is a little bit outdated.
> 
> Adjust it to reality.
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[Dario Faggioli]

On Thu, 2017-02-09 at 02:17 -0700, Jan Beulich wrote:
> > > > On 08.02.17 at 19:55,  wrote:
>  I'm going to commit what I have later today, and
> I'll pull in the one extra backport next time round.
> 
Ok, patch attached.

I've tested it on top of current tip of staging-4.7.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)commit 09725f8af37415c30a1a53d4a34e67fabcba105d
Author: Dario Faggioli 
Date:   Wed Feb 8 19:01:53 2017 +0100

xen: credit2: never consider CPUs outside of our cpupool.

In fact, relying on the mask of what pCPUs belong to
which Credit2 runqueue is not enough. If we only do that,
when Credit2 is the boot scheduler, we may ASSERT() or
panic when moving a pCPU from Pool-0 to another cpupool.

This is because pCPUs outside of any pool are considered
part of cpupool0. This puts us at risk of crash when those
same pCPUs are added to another pool and something
different than the idle domain is found to be running
on them.

Note that, even if we prevent the above to happen (which
is the purpose of this patch), this is still pretty bad,
in fact, when we remove a pCPU from Pool-0:
- in Credit1, as we do *not* update prv->ncpus and
  prv->credit, which means we're considering the wrong
  total credits when doing accounting;
- in Credit2, the pCPU remains part of one runqueue,
  and is hence at least considered during load balancing,
  even if no vCPU should really run there.

In Credit1, this "only" causes skewed accounting and
no crashes because there is a lot of `cpumask_and`ing
going on with the cpumask of the domains' cpupool
(which, BTW, comes at a price).

A quick and not to involved (and easily backportable)
solution for Credit2, is to do exactly the same.

Signed-off-by: Dario Faggioli 
Cc: Jan Beulich 

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 25b4c91..35dad15 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -331,19 +331,22 @@ static int csched2_cpu_pick(const struct scheduler *ops, struct vcpu *vc);
  */
 static int get_fallback_cpu(struct csched2_vcpu *svc)
 {
-int fallback_cpu, cpu = svc->vcpu->processor;
+struct vcpu *v = svc->vcpu;
+int cpu = v->processor;
 
-if ( likely(cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity)) )
-return cpu;
+cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+cpupool_domain_cpumask(v->domain));
 
-cpumask_and(cpumask_scratch_cpu(cpu), svc->vcpu->cpu_hard_affinity,
->rqd->active);
-fallback_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
-if ( likely(fallback_cpu < nr_cpu_ids) )
-return fallback_cpu;
+if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
+return cpu;
 
-cpumask_and(cpumask_scratch, svc->vcpu->cpu_hard_affinity,
-cpupool_domain_cpumask(svc->vcpu->domain));
+if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
+   >rqd->active)) )
+{
+cpumask_and(cpumask_scratch_cpu(cpu), >rqd->active,
+cpumask_scratch_cpu(cpu));
+return cpumask_first(cpumask_scratch_cpu(cpu));
+}
 
 ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
 
@@ -582,9 +585,12 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
 goto tickle;
 }
 
+cpumask_and(cpumask_scratch_cpu(cpu), new->vcpu->cpu_hard_affinity,
+cpupool_domain_cpumask(new->vcpu->domain));
+
 /* Get a mask of idle, but not tickled, that new is allowed to run on. */
 cpumask_andnot(, >idle, >tickled);
-cpumask_and(, , new->vcpu->cpu_hard_affinity);
+cpumask_and(, , cpumask_scratch_cpu(cpu));
 
 /* If it's not empty, choose one */
 i = cpumask_cycle(cpu, );
@@ -599,7 +605,7 @@ runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu *
  * that new is allowed to run on. */
 cpumask_andnot(, >active, >idle);
 cpumask_andnot(, , >tickled);
-cpumask_and(, , new->vcpu->cpu_hard_affinity);
+cpumask_and(, , cpumask_scratch_cpu(cpu));
 
 for_each_cpu(i, )
 {
@@ -1160,6 +1166,9 @@ choose_cpu(const struct scheduler *ops, struct vcpu *vc)
 return get_fallback_cpu(svc);
 }
 
+cpumask_and(cpumask_scratch_cpu(cpu), vc->cpu_hard_affinity,
+cpupool_domain_cpumask(vc->domain));
+
 /* First check to see if we're here because someone else suggested a place
  * for us to move. */
 if ( 

Re: [Xen-devel] [PATCH v6] x86/hvm: add vcpu parameter to guest memory copy function

[Jan Beulich]

>>> On 07.02.17 at 18:35,  wrote:
> @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy(
>  {
>  static unsigned long lastpage;
>  if ( xchg(, gfn) != gfn )
> -gdprintk(XENLOG_DEBUG, "guest attempted write to 
> read-only"
> +printk(XENLOG_DEBUG, "%pv guest attempted write to 
> read-only"

This broke the build, and I can't see how it would have built for you.
I've converted it to dprintk(XENLOG_G_DEBUG, ...) to retain as many
of the original properties as possible.

Jan


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

[Xen-devel] [ovmf baseline-only test] 68542: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 68542 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68542/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 68540

version targeted for testing:
 ovmf 41ccec58e07376fe3086d3fb4cf6290c53ca2303
baseline version:
 ovmf ad1cd1aa09c0a8660c857de916105b1fd566ca8c

Last test of basis68540  2017-02-09 02:46:33 Z0 days
Testing same since68542  2017-02-09 08:16:39 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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



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

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

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


Push not applicable.


commit 41ccec58e07376fe3086d3fb4cf6290c53ca2303
Author: Jiewen Yao 
Date:   Mon Feb 6 22:32:49 2017 -0800

SignedCapsulePkg/EdkiiSystemCapsuleLib: Fix logic error.

This patch fixes https://bugzilla.tianocore.org/show_bug.cgi?id=367

Cc: Wang Cloud 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Wang Cloud 

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

Re: [Xen-devel] [PATCH v6 07/24] x86: refactor psr: implement get value flow.

[Wei Liu]

On Wed, Feb 08, 2017 at 04:15:59PM +0800, Yi Sun wrote:
>  static void __init parse_psr_bool(char *s, char *value, char *feature,
> @@ -479,12 +495,14 @@ static struct psr_socket_info *get_socket_info(unsigned 
> int socket)
>  return socket_info + socket;
>  }
>  
> -int psr_get_info(unsigned int socket, enum cbm_type type,
> - uint32_t data[], unsigned int array_len)
> +static int __psr_get(unsigned int socket, enum cbm_type type,
> + uint32_t data[], unsigned int array_len,
> + struct domain *d, uint64_t *val)

Double underscore is part of the reserved namespace. Calling this
function psr_get should be fine.

Wei.

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

Re: [Xen-devel] [PATCH v6 03/24] x86: refactor psr: implement main data structures.

[Wei Liu]

On Wed, Feb 08, 2017 at 04:15:55PM +0800, Yi Sun wrote:
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index 96a8589..4656936 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -17,12 +17,118 @@
>  #include 
>  #include 
>  #include 
> +#include 

Please move the inclusion before sched.h -- they should be sorted
alphabetically.

Wei.

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

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

[Chao Gao]

On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote:
 On 08.02.17 at 08:31,  wrote:
>>>  From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Monday, February 06, 2017 11:38 PM
>>> 
>>> >>> On 06.02.17 at 15:48,  wrote:
>>> > On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
>>> >> >
>>> >> > >
>>> >> > > >
>>> >> > > > On 06.02.17 at 14:55,  wrote:
>>> >> > Switch its return type to bool to match its use, and simplify the
>>> >> > ARM
>>> >> > implementation slightly.
>>> >> >
>>> >> > No functional change.
>>> >> >
>>> >> > Signed-off-by: Andrew Cooper 
>>> >> Reviewed-by: Jan Beulich 
>>> >>
>>> >> And perhaps that's what should be used in epte_get_entry_emt()
>>> >> instead of !mfn_valid() in David's patch. David, would you be okay
>>> >> with your patch changed to that effect upon commit?
>>> >
>>> > I don't think that works, at least not literally
>>> > s/!mfn_valid()/is_iomem_page()/
>>> >
>>> > In my patch, mfn_valid() is checked *after* we've processed the
>>> > 'direct_mmio' case that all MMIO should hit. In a sane world I think
>>> > it's *only* actually catching INVALID_MFN, and probably should never
>>> > match on any other value of mfn.
>>> >
>>> > I don't quite understand why we pass 'direct_mmio' in as a separate
>>> > argument. Perhaps there's scope for doing a sanity check that
>>> > 'direct_mmio == is_iomem_page(mfn)' — because when would that *not* be
>>> > true?
>>> 
>>> Likely never. The reasons for why this was done the way it is
>>> escape me. Adding VMX maintainers once again.
>> 
>> I'm not the original author of that code. Here is what I found from the 
>> code:
>> 
>> There are two places caring direct_mmio: resolve_misconfig and ept_
>> set_entry. It's decided upon p2m type:
>> 
>>   int emt = epte_get_entry_emt(p2m->domain, gfn, _mfn(e.mfn),
>> level * EPT_TABLE_ORDER, ,
>> e.sa_p2mt == p2m_mmio_direct);
>> 
>> I'm not sure whether p2m_mmio_direct always makes is_iomem_page
>> true. If true then yes we may not require this parameter at all.
>
>From an abstract perspective the two should always correlate. We
>may want to take an intermediate step though and first only add
>checking, and perhaps a release later remove the extra parameter
>if the check never triggered for anyone.
>

I add one assertion to the original code, like below.

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 86c71be..3d9386a 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d, unsigned long gfn, 
 
 if ( direct_mmio )
 {
+ASSERT(direct_mmio == is_iomem_page(mfn)); 
+
 if ( (mfn_x(mfn) ^ d->arch.hvm_domain.vmx.apic_access_mfn) >> order )
 return MTRR_TYPE_UNCACHABLE;
 if ( order )

But when I try to create a hvm domain, it failed. logs are below.

(XEN) Assertion 'direct_mmio == is_iomem_page(mfn)' failed at mtrr.c:787
(XEN) [ Xen-4.9-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:44
(XEN) RIP:e008:[] epte_get_entry_emt+0xbc/0x24e 
[EPTE_EMT_v2]
(XEN) RFLAGS: 00010297   CONTEXT: hypervisor (d0v39)
(XEN) rax: 832077d7e000   rbx: 010107ba   rcx: 8300
(XEN) rdx: 02077d7e   rsi: 010107ba   rdi: 010107ba
(XEN) rbp: 832076857a68   rsp: 832076857a18   r8:  832076857af7
(XEN) r9:  0001   r10:    r11: 
(XEN) r12: 832077d7e000   r13:    r14: 
(XEN) r15: 832076857af7   cr0: 80050033   cr4: 001526e0
(XEN) cr3: 00089998   cr2: 7f35eb86d8d1
(XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around  (epte_get_entry_emt+0xbc/0x24e 
[EPTE_EMT_v2]):
(XEN)  37 4d d7 ff 3c 01 74 02 <0f> 0b 49 33 9c 24 40 06 00 00 44 89 e9 48 d3 eb
(XEN) Xen stack trace from rsp=832076857a18:
(XEN)832076857b00 000fee00 010107ba 0001
(XEN)832076857a68 832077da8b90  832076857b00
(XEN)8200403c8000  832076857b38 82d0802101b5
(XEN)8325 0206  832076857aa8
(XEN)82d08013452b 8310 0001 00070206
(XEN)832077d7e000 000fee00 010107ba 0005
(XEN)832077da8b90  8000 00ff832077da8b90
(XEN) 8200403c8000 0001 010107ba
(XEN) 0001 000fee00 832077da8b90
(XEN)832076857b98 82d080204d62  000776857b68
(XEN)832077d7e000 0005 832076857b98 832077d7e000
(XEN)010107ba 

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[Jan Beulich]

>>> On 08.02.17 at 19:55,  wrote:
> As per 4.7, I've prepared a branch for you:

Thanks.

>  git://xenbits.xen.org/people/dariof/xen.git 
> for-jan/staging-4.7/credit2-cpupool-fixes
>  
> http://xenbits.xen.org/gitweb/?p=people/dariof/xen.git;a=shortlog;h=refs/head 
> s/for-jan/staging-4.7/credit2-cpupool-fixes
>  https://travis-ci.org/fdario/xen/builds/199709757 
> 
> I've only quickly tested it so far, and I have to leave now. I'll play
> with it a bit more tomorrow morning and let you know how it goes.

Well, looking at the topmost commit, you've clearly missed the
follow-up fix (ad5808d905), which I did fold into that backport
right away. I'm going to commit what I have later today, and
I'll pull in the one extra backport next time round.

Jan


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

[Xen-devel] [PATCH v2 07/12] libxl: carve out console specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the console
related functions (including channels, keyboard and frame buffer)
to libxl_console.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile|   2 +-
 tools/libxl/libxl.c | 846 ---
 tools/libxl/libxl_console.c | 862 
 3 files changed, 863 insertions(+), 847 deletions(-)
 create mode 100644 tools/libxl/libxl_console.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index baf591d..dd7aa41 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -136,7 +136,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
-   libxl_vtpm.o libxl_nic.o libxl_disk.o \
+   libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_sched.o \
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3f8f16e..20ae61a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1507,239 +1507,6 @@ static void domain_destroy_domid_cb(libxl__egc *egc,
 dis->callback(egc, dis, rc);
 }
 
-static int libxl__console_tty_path(libxl__gc *gc, uint32_t domid, int cons_num,
-   libxl_console_type type, char **tty_path)
-{
-int rc;
-char *dom_path;
-
-dom_path = libxl__xs_get_dompath(gc, domid);
-if (!dom_path) {
-rc = ERROR_FAIL;
-goto out;
-}
-
-switch (type) {
-case LIBXL_CONSOLE_TYPE_SERIAL:
-*tty_path = GCSPRINTF("%s/serial/%d/tty", dom_path, cons_num);
-rc = 0;
-break;
-case LIBXL_CONSOLE_TYPE_PV:
-if (cons_num == 0)
-*tty_path = GCSPRINTF("%s/console/tty", dom_path);
-else
-*tty_path = GCSPRINTF("%s/device/console/%d/tty", dom_path,
-  cons_num);
-rc = 0;
-break;
-default:
-rc = ERROR_INVAL;
-goto out;
-}
-
-out:
-return rc;
-}
-
-int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
-   libxl_console_type type, int notify_fd)
-{
-GC_INIT(ctx);
-char *p = GCSPRINTF("%s/xenconsole", libxl__private_bindir_path());
-char *domid_s = GCSPRINTF("%d", domid);
-char *cons_num_s = GCSPRINTF("%d", cons_num);
-char *notify_fd_s;
-char *cons_type_s;
-
-switch (type) {
-case LIBXL_CONSOLE_TYPE_PV:
-cons_type_s = "pv";
-break;
-case LIBXL_CONSOLE_TYPE_SERIAL:
-cons_type_s = "serial";
-break;
-default:
-goto out;
-}
-
-if (notify_fd != -1) {
-notify_fd_s = GCSPRINTF("%d", notify_fd);
-execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s,
-  "--start-notify-fd", notify_fd_s, (void *)NULL);
-} else {
-execl(p, p, domid_s, "--num", cons_num_s, "--type", cons_type_s,
-  (void *)NULL);
-}
-
-out:
-GC_FREE;
-return ERROR_FAIL;
-}
-
-int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num,
-  libxl_console_type type, char **path)
-{
-GC_INIT(ctx);
-char *tty_path;
-char *tty;
-int rc;
-
-rc = libxl__console_tty_path(gc, domid, cons_num, type, _path);
-if (rc) {
-LOGD(ERROR, domid, "Failed to get tty path\n");
-goto out;
-}
-
-tty = libxl__xs_read(gc, XBT_NULL, tty_path);
-if (!tty || tty[0] == '\0') {
-   LOGED(ERROR, domid, "Unable to read console tty path `%s'",
- tty_path);
-   rc = ERROR_FAIL;
-   goto out;
-}
-
-*path = libxl__strdup(NOGC, tty);
-rc = 0;
-out:
-GC_FREE;
-return rc;
-}
-
-static int libxl__primary_console_find(libxl_ctx *ctx, uint32_t domid_vm,
-   uint32_t *domid, int *cons_num,
-   libxl_console_type *type)
-{
-GC_INIT(ctx);
-uint32_t stubdomid = libxl_get_stubdom_id(ctx, domid_vm);
-int rc;
-
-if (stubdomid) {
-*domid = stubdomid;
-*cons_num = STUBDOM_CONSOLE_SERIAL;
-*type = LIBXL_CONSOLE_TYPE_PV;
-} else {
-switch (libxl__domain_type(gc, domid_vm)) {
-case LIBXL_DOMAIN_TYPE_HVM:
-*domid = domid_vm;
-*cons_num = 0;
-*type = LIBXL_CONSOLE_TYPE_SERIAL;
-break;
-case LIBXL_DOMAIN_TYPE_PV:
-*domid = domid_vm;
-*cons_num = 0;
-*type = LIBXL_CONSOLE_TYPE_PV;
-break;
-case LIBXL_DOMAIN_TYPE_INVALID:
-rc = ERROR_INVAL;
-goto out;
-

[Xen-devel] [PATCH v2 06/12] libxl: carve out disk specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the disk
related functions to libxl_disk.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile |2 +-
 tools/libxl/libxl.c  | 1233 -
 tools/libxl/libxl_disk.c | 1258 ++
 3 files changed, 1259 insertions(+), 1234 deletions(-)
 create mode 100644 tools/libxl/libxl_disk.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 7514cc2..baf591d 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -136,7 +136,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
-   libxl_vtpm.o libxl_nic.o \
+   libxl_vtpm.o libxl_nic.o libxl_disk.o \
libxl_cpupool.o libxl_sched.o \
 $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ae6c7d4..3f8f16e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -18,7 +18,6 @@
 #include "libxl_arch.h"
 
 #define PAGE_TO_MEMKB(pages) ((pages) * 4)
-#define BACKEND_STRING_SIZE 5
 
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 unsigned flags, xentoollog_logger * lg)
@@ -1197,140 +1196,6 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx,
 GC_FREE;
 }
 
-static void disk_eject_xswatch_callback(libxl__egc *egc, libxl__ev_xswatch *w,
-const char *wpath, const char *epath) {
-EGC_GC;
-libxl_evgen_disk_eject *evg = (void*)w;
-const char *backend;
-char *value;
-char backend_type[BACKEND_STRING_SIZE+1];
-int rc;
-
-value = libxl__xs_read(gc, XBT_NULL, wpath);
-
-if (!value || strcmp(value,  "eject"))
-return;
-
-if (libxl__xs_printf(gc, XBT_NULL, wpath, "")) {
-LIBXL__EVENT_DISASTER(egc, "xs_write failed acknowledging eject",
-  errno, LIBXL_EVENT_TYPE_DISK_EJECT);
-return;
-}
-
-libxl_event *ev = NEW_EVENT(egc, DISK_EJECT, evg->domid, evg->user);
-libxl_device_disk *disk = >u.disk_eject.disk;
-
-rc = libxl__xs_read_checked(gc, XBT_NULL, evg->be_ptr_path, );
-if (rc) {
-LIBXL__EVENT_DISASTER(egc, "xs_read failed reading be_ptr_path",
-  errno, LIBXL_EVENT_TYPE_DISK_EJECT);
-return;
-}
-if (!backend) {
-/* device has been removed, not simply ejected */
-return;
-}
-
-sscanf(backend,
-"/local/domain/%d/backend/%" TOSTRING(BACKEND_STRING_SIZE)
-   "[a-z]/%*d/%*d",
-   >backend_domid, backend_type);
-if (!strcmp(backend_type, "tap") || !strcmp(backend_type, "vbd")) {
-disk->backend = LIBXL_DISK_BACKEND_TAP;
-} else if (!strcmp(backend_type, "qdisk")) {
-disk->backend = LIBXL_DISK_BACKEND_QDISK;
-} else {
-disk->backend = LIBXL_DISK_BACKEND_UNKNOWN;
-}
-
-disk->pdev_path = strdup(""); /* xxx fixme malloc failure */
-disk->format = LIBXL_DISK_FORMAT_EMPTY;
-/* this value is returned to the user: do not free right away */
-disk->vdev = libxl__strdup(NOGC, evg->vdev);
-disk->removable = 1;
-disk->readwrite = 0;
-disk->is_cdrom = 1;
-
-libxl__event_occurred(egc, ev);
-}
-
-int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t guest_domid,
-  const char *vdev, libxl_ev_user user,
-  libxl_evgen_disk_eject **evgen_out) {
-GC_INIT(ctx);
-CTX_LOCK;
-int rc;
-char *path;
-libxl_evgen_disk_eject *evg = NULL;
-
-evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
-memset(evg, 0, sizeof(*evg));
-evg->user = user;
-evg->domid = guest_domid;
-LIBXL_LIST_INSERT_HEAD(>disk_eject_evgens, evg, entry);
-
-uint32_t domid = libxl_get_stubdom_id(ctx, guest_domid);
-
-if (!domid)
-domid = guest_domid;
-
-int devid = libxl__device_disk_dev_number(vdev, NULL, NULL);
-
-path = GCSPRINTF("%s/device/vbd/%d/eject",
- libxl__xs_get_dompath(gc, domid),
- devid);
-if (!path) { rc = ERROR_NOMEM; goto out; }
-
-const char *libxl_path = GCSPRINTF("%s/device/vbd/%d",
- libxl__xs_libxl_path(gc, domid),
- devid);
-evg->be_ptr_path = libxl__sprintf(NOGC, "%s/backend", libxl_path);
-
-const char *configured_vdev;
-rc = libxl__xs_read_checked(gc, XBT_NULL,
-GCSPRINTF("%s/dev", libxl_path), _vdev);
-if (rc) goto out;
-
-evg->vdev = libxl__strdup(NOGC, configured_vdev);
-
-rc = libxl__ev_xswatch_register(gc, >watch,
-   

[Xen-devel] [PATCH v2 11/12] libxl: carve out domain specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the domain
related functions to libxl_domain.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile   |1 +
 tools/libxl/libxl.c| 1722 ---
 tools/libxl/libxl_domain.c | 1744 
 3 files changed, 1745 insertions(+), 1722 deletions(-)
 create mode 100644 tools/libxl/libxl_domain.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 99ddae1..6cc7b45 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -138,6 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
+   libxl_domain.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 67c0a13..0ef8744 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -16,8 +16,6 @@
 
 #include "libxl_internal.h"
 
-#define PAGE_TO_MEMKB(pages) ((pages) * 4)
-
 int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 unsigned flags, xentoollog_logger * lg)
 {
@@ -353,1188 +351,6 @@ const char *libxl_defbool_to_string(libxl_defbool b)
 }
 
 
/**/
-int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
- const char *old_name, const char *new_name,
- xs_transaction_t trans)
-{
-libxl_ctx *ctx = libxl__gc_owner(gc);
-char *dom_path = 0;
-const char *name_path;
-char *got_old_name;
-unsigned int got_old_len;
-xs_transaction_t our_trans = 0;
-uint32_t stub_dm_domid;
-const char *stub_dm_old_name = NULL, *stub_dm_new_name = NULL;
-int rc;
-libxl_dominfo info;
-char *uuid;
-const char *vm_name_path;
-
-libxl_dominfo_init();
-
-dom_path = libxl__xs_get_dompath(gc, domid);
-if (!dom_path) goto x_nomem;
-
-name_path= GCSPRINTF("%s/name", dom_path);
-if (!name_path) goto x_nomem;
-
-stub_dm_domid = libxl_get_stubdom_id(CTX, domid);
-if (stub_dm_domid) {
-stub_dm_old_name = libxl__stub_dm_name(gc, old_name);
-stub_dm_new_name = libxl__stub_dm_name(gc, new_name);
-}
-
- retry_transaction:
-if (!trans) {
-trans = our_trans = xs_transaction_start(ctx->xsh);
-if (!our_trans) {
-LOGEVD(ERROR, errno, domid, "Create xs transaction for domain 
(re)name");
-goto x_fail;
-}
-}
-
-if (!new_name) {
-LOGD(ERROR, domid, "New domain name not specified");
-rc = ERROR_INVAL;
-goto x_rc;
-}
-
-if (new_name[0]) {
-/* nonempty names must be unique */
-uint32_t domid_e;
-rc = libxl_name_to_domid(ctx, new_name, _e);
-if (rc == ERROR_INVAL) {
-/* no such domain, good */
-} else if (rc != 0) {
-LOGD(ERROR, domid, "Unexpected error checking for existing 
domain");
-goto x_rc;
-} else if (domid_e == domid) {
-/* domain already has this name, ok (but we do still
- * need the rest of the code as we may need to check
- * old_name, for example). */
-} else {
-LOGD(ERROR, domid, "Domain with name \"%s\" already exists.", 
new_name);
-rc = ERROR_INVAL;
-goto x_rc;
-}
-}
-
-if (old_name) {
-got_old_name = xs_read(ctx->xsh, trans, name_path, _old_len);
-if (!got_old_name) {
-LOGEVD(ERROR, errno, domid,
-   "Check old name for domain allegedly named `%s'",
-   old_name);
-goto x_fail;
-}
-if (strcmp(old_name, got_old_name)) {
-LOGD(ERROR, domid,
- "Allegedly named `%s' is actually named `%s' - racing ?",
- old_name,
- got_old_name);
-free(got_old_name);
-goto x_fail;
-}
-free(got_old_name);
-}
-if (!xs_write(ctx->xsh, trans, name_path,
-  new_name, strlen(new_name))) {
-LOGD(ERROR, domid,
- "Failed to write new name `%s'"
- " for domain previously named `%s'",
- new_name,
- old_name);
-goto x_fail;
-}
-
-/* update /vm//name */
-rc = libxl_domain_info(ctx, , domid);
-if (rc)
-goto x_rc;
-
-uuid = GCSPRINTF(LIBXL_UUID_FMT, LIBXL_UUID_BYTES(info.uuid));
-vm_name_path = GCSPRINTF("/vm/%s/name", uuid);
-if (libxl__xs_write_checked(gc, trans, vm_name_path, new_name))
-goto x_fail;
-
-if 

[Xen-devel] [PATCH v2 02/12] libxl: make some functions global to prepare splitting up libxl.c

[Juergen Gross]

Splitting up libxl.c will require two functions to be globally visible.
Add their prototypes to libxl_internal.h.

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl.c  | 12 ++--
 tools/libxl/libxl_internal.h |  7 +++
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 0641a8a..ea66149 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -594,9 +594,9 @@ int libxl_domain_preserve(libxl_ctx *ctx, uint32_t domid,
 return 0;
 }
 
-static void xcinfo2xlinfo(libxl_ctx *ctx,
-  const xc_domaininfo_t *xcinfo,
-  libxl_dominfo *xlinfo)
+void xcinfo2xlinfo(libxl_ctx *ctx,
+   const xc_domaininfo_t *xcinfo,
+   libxl_dominfo *xlinfo)
 {
 size_t size;
 
@@ -4342,9 +4342,9 @@ out_no_transaction:
 }
 
 /* out_target_memkb and out_max_memkb can be NULL */
-static int libxl__get_memory_target(libxl__gc *gc, uint32_t domid,
-uint64_t *out_target_memkb,
-uint64_t *out_max_memkb)
+int libxl__get_memory_target(libxl__gc *gc, uint32_t domid,
+ uint64_t *out_target_memkb,
+ uint64_t *out_max_memkb)
 {
 int rc;
 char *target = NULL, *static_max = NULL, *endptr = NULL;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index a093bc6..b880801 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4246,6 +4246,13 @@ uint64_t libxl__get_targetmem_fudge(libxl__gc *gc,
 return info->video_memkb + mem_target_fudge;
 }
 
+int libxl__get_memory_target(libxl__gc *gc, uint32_t domid,
+ uint64_t *out_target_memkb,
+ uint64_t *out_max_memkb);
+void xcinfo2xlinfo(libxl_ctx *ctx,
+   const xc_domaininfo_t *xcinfo,
+   libxl_dominfo *xlinfo);
+
 /* Macros used to compare device identifier. Returns true if the two
  * devices have same identifier. */
 #define COMPARE_DEVID(a, b) ((a)->devid == (b)->devid)
-- 
2.10.2


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

[Xen-devel] [PATCH v2 01/12] libxl: adjust copyright comment of libxl.c

[Juergen Gross]

The copyright of libxl.c is a little bit outdated.

Adjust it to reality.

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index d400fa2..0641a8a 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1,7 +1,5 @@
 /*
- * Copyright (C) 2009  Citrix Ltd.
- * Author Vincent Hanquez 
- * Author Stefano Stabellini 
+ * Copyright 2009-2017 Citrix Ltd and other contributors
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU Lesser General Public License as published
-- 
2.10.2


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

[Xen-devel] [PATCH v2 03/12] libxl: white space cleanup

[Juergen Gross]

Before moving code to new sources clean up some white space issues in
libxl.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ea66149..6b87f48 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -72,7 +72,7 @@ int libxl_ctx_alloc(libxl_ctx **pctx, int version,
 
 ctx->childproc_hooks = __childproc_default_hooks;
 ctx->childproc_user = 0;
-
+
 ctx->sigchld_selfpipe[0] = -1;
 ctx->sigchld_selfpipe[1] = -1;
 libxl__ev_fd_init(>sigchld_selfpipe_efd);
@@ -355,8 +355,6 @@ const char *libxl_defbool_to_string(libxl_defbool b)
 }
 
 
/**/
-
-
 int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
  const char *old_name, const char *new_name,
  xs_transaction_t trans)
@@ -1242,7 +1240,7 @@ int libxl_evenable_domain_death(libxl_ctx *ctx, uint32_t 
domid,
 GC_INIT(ctx);
 libxl_evgen_domain_death *evg, *evg_search;
 int rc;
-
+
 CTX_LOCK;
 
 evg = malloc(sizeof(*evg));  if (!evg) { rc = ERROR_NOMEM; goto out; }
@@ -1315,7 +1313,7 @@ static void disk_eject_xswatch_callback(libxl__egc *egc, 
libxl__ev_xswatch *w,
 
 libxl_event *ev = NEW_EVENT(egc, DISK_EJECT, evg->domid, evg->user);
 libxl_device_disk *disk = >u.disk_eject.disk;
-
+
 rc = libxl__xs_read_checked(gc, XBT_NULL, evg->be_ptr_path, );
 if (rc) {
 LIBXL__EVENT_DISASTER(egc, "xs_read failed reading be_ptr_path",
@@ -1425,7 +1423,7 @@ void libxl_evdisable_disk_eject(libxl_ctx *ctx, 
libxl_evgen_disk_eject *evg) {
 GC_INIT(ctx);
 libxl__evdisable_disk_eject(gc, evg);
 GC_FREE;
-}
+}
 
 /* Callbacks for libxl_domain_destroy */
 
@@ -2515,7 +2513,6 @@ out:
 return rc;
 }
 
-
 static int libxl__append_disk_list(libxl__gc *gc,
uint32_t domid,
libxl_device_disk **disks,
@@ -2862,7 +2859,7 @@ static char * libxl__alloc_vdev(libxl__gc *gc, void 
*get_vdev_user,
 
 /* Callbacks */
 
-char *libxl__device_disk_find_local_path(libxl__gc *gc, 
+char *libxl__device_disk_find_local_path(libxl__gc *gc,
   libxl_domid guest_domid,
   const libxl_device_disk *disk,
   bool qdisk_direct)
@@ -2884,7 +2881,7 @@ char *libxl__device_disk_find_local_path(libxl__gc *gc,
 path = libxl__strdup(gc, disk->pdev_path);
 LOG(DEBUG, "Directly accessing local RAW disk %s", path);
 goto out;
-} 
+}
 
 /*
  * If we're being called for a qemu path, we can pass the target
@@ -2894,9 +2891,9 @@ char *libxl__device_disk_find_local_path(libxl__gc *gc,
 path = libxl__strdup(gc, disk->pdev_path);
 LOG(DEBUG, "Directly accessing local QDISK target %s", path);
 goto out;
-} 
+}
 
-/* 
+/*
  * If the format isn't raw and / or we're using a script, then see
  * if the script has written a path to the "cooked" node
  */
@@ -2965,7 +2962,7 @@ void libxl__device_disk_local_initiate_attach(libxl__egc 
*egc,
 if (in_disk->script != NULL)
 disk->script = libxl__strdup(gc, in_disk->script);
 disk->vdev = NULL;
-
+
 rc = libxl__device_disk_setdefault(gc, disk, LIBXL_TOOLSTACK_DOMID);
 if (rc) goto out;
 
@@ -3042,7 +3039,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 rc = libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID,
  disk, device);
 if (rc != 0) goto out;
-
+
 aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
-- 
2.10.2


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

[Xen-devel] [PATCH v2 05/12] libxl: carve out scheduler specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the scheduler
related functions to libxl_sched.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile  |   2 +-
 tools/libxl/libxl.c   | 891 
 tools/libxl/libxl_sched.c | 915 ++
 3 files changed, 916 insertions(+), 892 deletions(-)
 create mode 100644 tools/libxl/libxl_sched.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 0125871..7514cc2 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -137,7 +137,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o \
-   libxl_cpupool.o \
+   libxl_cpupool.o libxl_sched.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 d0080ca..ae6c7d4 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -4830,146 +4830,6 @@ err:
 return NULL;
 }
 
-static int libxl__set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid,
-   uint32_t vcpuid,
-   const libxl_bitmap *cpumap_hard,
-   const libxl_bitmap *cpumap_soft,
-   unsigned flags)
-{
-GC_INIT(ctx);
-libxl_bitmap hard, soft;
-int rc;
-
-libxl_bitmap_init();
-libxl_bitmap_init();
-
-if (!cpumap_hard && !cpumap_soft && !flags) {
-rc = ERROR_INVAL;
-goto out;
-}
-
-/*
- * Xen wants writable hard and/or soft cpumaps, to put back in them
- * the effective hard and/or soft affinity that will be used.
- */
-if (cpumap_hard) {
-rc = libxl_cpu_bitmap_alloc(ctx, , 0);
-if (rc)
-goto out;
-
-libxl__bitmap_copy_best_effort(gc, , cpumap_hard);
-flags |= XEN_VCPUAFFINITY_HARD;
-}
-if (cpumap_soft) {
-rc = libxl_cpu_bitmap_alloc(ctx, , 0);
-if (rc)
-goto out;
-
-libxl__bitmap_copy_best_effort(gc, , cpumap_soft);
-flags |= XEN_VCPUAFFINITY_SOFT;
-}
-
-if (xc_vcpu_setaffinity(ctx->xch, domid, vcpuid,
-cpumap_hard ? hard.map : NULL,
-cpumap_soft ? soft.map : NULL,
-flags)) {
-LOGED(ERROR, domid, "Setting vcpu affinity");
-rc = ERROR_FAIL;
-goto out;
-}
-
-/*
- * Let's check the results. Hard affinity will never be empty, but it
- * is possible that Xen will use something different from what we asked
- * for various reasons. If that's the case, report it.
- */
-if (cpumap_hard &&
-!libxl_bitmap_equal(cpumap_hard, , 0))
-LOGD(DEBUG, domid, "New hard affinity for vcpu %d has unreachable 
cpus", vcpuid);
-/*
- * Soft affinity can both be different from what asked and empty. Check
- * for (and report) both.
- */
-if (cpumap_soft) {
-if (!libxl_bitmap_equal(cpumap_soft, , 0))
-LOGD(DEBUG, domid, "New soft affinity for vcpu %d has unreachable 
cpus",
- vcpuid);
-if (libxl_bitmap_is_empty())
-LOGD(WARN, domid, "All cpus in soft affinity of vcpu %d are 
unreachable."
- " Only hard affinity will be considered for scheduling",
- vcpuid);
-}
-
-rc = 0;
- out:
-libxl_bitmap_dispose();
-libxl_bitmap_dispose();
-GC_FREE;
-return rc;
-}
-
-int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t domid, uint32_t vcpuid,
-   const libxl_bitmap *cpumap_hard,
-   const libxl_bitmap *cpumap_soft)
-{
-return libxl__set_vcpuaffinity(ctx, domid, vcpuid, cpumap_hard,
-   cpumap_soft, 0);
-}
-
-int libxl_set_vcpuaffinity_force(libxl_ctx *ctx, uint32_t domid,
- uint32_t vcpuid,
- const libxl_bitmap *cpumap_hard,
- const libxl_bitmap *cpumap_soft)
-{
-return libxl__set_vcpuaffinity(ctx, domid, vcpuid, cpumap_hard,
-   cpumap_soft, XEN_VCPUAFFINITY_FORCE);
-}
-
-int libxl_set_vcpuaffinity_all(libxl_ctx *ctx, uint32_t domid,
-   unsigned int max_vcpus,
-   const libxl_bitmap *cpumap_hard,
-   const libxl_bitmap *cpumap_soft)
-{
-GC_INIT(ctx);
-int i, rc = 0;
-
-for (i = 0; i < max_vcpus; i++) {
-if (libxl_set_vcpuaffinity(ctx, domid, i, cpumap_hard, cpumap_soft)) {
-LOGD(WARN, domid, 

[Xen-devel] [PATCH v2 09/12] libxl: move device specific functions out of libxl.c

[Juergen Gross]

Move the few generic device specific functions left in libxl.c to
libxl_device.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl.c| 416 -
 tools/libxl/libxl_device.c | 414 
 2 files changed, 414 insertions(+), 416 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f9aad9b..3cf4a56 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1527,50 +1527,6 @@ out:
 
 
/**/
 
-/* generic callback for devices that only need to set ao_complete */
-void device_addrm_aocomplete(libxl__egc *egc, libxl__ao_device *aodev)
-{
-STATE_AO_GC(aodev->ao);
-
-if (aodev->rc) {
-if (aodev->dev) {
-LOGD(ERROR, aodev->dev->domid, "Unable to %s %s with id %u",
-libxl__device_action_to_string(aodev->action),
-libxl__device_kind_to_string(aodev->dev->kind),
-aodev->dev->devid);
-} else {
-LOG(ERROR, "unable to %s device",
-   libxl__device_action_to_string(aodev->action));
-}
-goto out;
-}
-
-out:
-libxl__ao_complete(egc, ao, aodev->rc);
-return;
-}
-
-/* common function to get next device id */
-int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
-{
-char *libxl_dom_path, **l;
-unsigned int nb;
-int nextid = -1;
-
-if (!(libxl_dom_path = libxl__xs_libxl_path(gc, domid)))
-return nextid;
-
-l = libxl__xs_directory(gc, XBT_NULL,
-GCSPRINTF("%s/device/%s", libxl_dom_path, device),
-);
-if (l == NULL || nb == 0)
-nextid = 0;
-else
-nextid = strtoul(l[nb - 1], NULL, 10) + 1;
-
-return nextid;
-}
-
 int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
@@ -1579,378 +1535,6 @@ int libxl__resolve_domid(libxl__gc *gc, const char 
*name, uint32_t *domid)
 }
 
 
/**/
-
-/*
- * Data structures used to track devices handled by driver domains
- */
-
-/*
- * Structure that describes a device handled by a driver domain
- */
-typedef struct libxl__ddomain_device {
-libxl__device *dev;
-LIBXL_SLIST_ENTRY(struct libxl__ddomain_device) next;
-} libxl__ddomain_device;
-
-/*
- * Structure that describes a domain and it's associated devices
- */
-typedef struct libxl__ddomain_guest {
-uint32_t domid;
-int num_vifs, num_vbds, num_qdisks;
-LIBXL_SLIST_HEAD(, struct libxl__ddomain_device) devices;
-LIBXL_SLIST_ENTRY(struct libxl__ddomain_guest) next;
-} libxl__ddomain_guest;
-
-/*
- * Main structure used by a driver domain to keep track of devices
- * currently in use
- */
-typedef struct {
-libxl__ao *ao;
-libxl__ev_xswatch watch;
-LIBXL_SLIST_HEAD(, struct libxl__ddomain_guest) guests;
-} libxl__ddomain;
-
-static libxl__ddomain_guest *search_for_guest(libxl__ddomain *ddomain,
-   uint32_t domid)
-{
-libxl__ddomain_guest *dguest;
-
-LIBXL_SLIST_FOREACH(dguest, >guests, next) {
-if (dguest->domid == domid)
-return dguest;
-}
-return NULL;
-}
-
-static libxl__ddomain_device *search_for_device(libxl__ddomain_guest *dguest,
-libxl__device *dev)
-{
-libxl__ddomain_device *ddev;
-
-LIBXL_SLIST_FOREACH(ddev, >devices, next) {
-#define LIBXL_DEVICE_CMP(dev1, dev2, entry) (dev1->entry == dev2->entry)
-if (LIBXL_DEVICE_CMP(ddev->dev, dev, backend_devid) &&
-LIBXL_DEVICE_CMP(ddev->dev, dev, backend_domid) &&
-LIBXL_DEVICE_CMP(ddev->dev, dev, devid) &&
-LIBXL_DEVICE_CMP(ddev->dev, dev, domid) &&
-LIBXL_DEVICE_CMP(ddev->dev, dev, backend_kind) &&
-LIBXL_DEVICE_CMP(ddev->dev, dev, kind))
-return ddev;
-#undef LIBXL_DEVICE_CMP
-}
-
-return NULL;
-}
-
-static void device_complete(libxl__egc *egc, libxl__ao_device *aodev)
-{
-STATE_AO_GC(aodev->ao);
-
-LOG(DEBUG, "device %s %s %s",
-   libxl__device_backend_path(gc, aodev->dev),
-   libxl__device_action_to_string(aodev->action),
-   aodev->rc ? "failed" : "succeed");
-
-if (aodev->action == LIBXL__DEVICE_ACTION_REMOVE)
-free(aodev->dev);
-
-libxl__nested_ao_free(aodev->ao);
-}
-
-static void qdisk_spawn_outcome(libxl__egc *egc, libxl__dm_spawn_state *dmss,
-int rc)
-{
-STATE_AO_GC(dmss->spawn.ao);
-
-LOGD(DEBUG, dmss->guest_domid, "qdisk backend spawn %s",
-rc ? "failed" : "succeed");
-
-libxl__nested_ao_free(dmss->spawn.ao);
-}
-
-/*
- * The following comment applies to both add_device and remove_device.
- *
- * If the return value is 

[Xen-devel] [PATCH v2 00/12] libxl: split up libxl.c

[Juergen Gross]

libxl.c has become rather large. Split it up into multiple files.

Changes are:
- modification of Copyright comment (patch 1)
- made two functions non-static: libxl__get_memory_target(),
  xcinfo2xlinfo() (patch 2)
- white space cleanup of libxl.c (patch 3)
- moving functions into new or existing sources (patches 4-11):
  just code movement, no functional changes besides needed Makefile
  adjustments for new sources
- made one function static: libxl__device_frontend_path() (patch 12)

Changes in V2:
- address comments of Ian Jackson: add new patches 1-3, 12

Juergen Gross (12):
  libxl: adjust copyright comment of libxl.c
  libxl: make some functions global to prepare splitting up libxl.c
  libxl: white space cleanup
  libxl: carve out cpupool specific functions from libxl.c
  libxl: carve out scheduler specific functions from libxl.c
  libxl: carve out disk specific functions from libxl.c
  libxl: carve out console specific functions from libxl.c
  libxl: carve out memory specific functions from libxl.c
  libxl: move device specific functions out of libxl.c
  libxl: carve out tmem specific functions from libxl.c
  libxl: carve out domain specific functions from libxl.c
  libxl: make one function static

 tools/libxl/Makefile |4 +-
 tools/libxl/libxl.c  | 6254 +-
 tools/libxl/libxl_console.c  |  862 ++
 tools/libxl/libxl_cpupool.c  |  443 +++
 tools/libxl/libxl_device.c   |  416 ++-
 tools/libxl/libxl_disk.c | 1258 +
 tools/libxl/libxl_domain.c   | 1744 
 tools/libxl/libxl_internal.h |8 +-
 tools/libxl/libxl_mem.c  |  601 
 tools/libxl/libxl_sched.c|  915 ++
 tools/libxl/libxl_tmem.c |  167 ++
 11 files changed, 6417 insertions(+), 6255 deletions(-)
 create mode 100644 tools/libxl/libxl_console.c
 create mode 100644 tools/libxl/libxl_cpupool.c
 create mode 100644 tools/libxl/libxl_disk.c
 create mode 100644 tools/libxl/libxl_domain.c
 create mode 100644 tools/libxl/libxl_mem.c
 create mode 100644 tools/libxl/libxl_sched.c
 create mode 100644 tools/libxl/libxl_tmem.c

-- 
2.10.2


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

[Xen-devel] [PATCH v2 10/12] libxl: carve out tmem specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the tmem
related functions to libxl_tmem.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile |   2 +-
 tools/libxl/libxl.c  | 142 
 tools/libxl/libxl_tmem.c | 167 +++
 3 files changed, 168 insertions(+), 143 deletions(-)
 create mode 100644 tools/libxl/libxl_tmem.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 4b05e34..99ddae1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -137,7 +137,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
-   libxl_cpupool.o libxl_mem.o libxl_sched.o \
+   libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.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 3cf4a56..67c0a13 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2105,148 +2105,6 @@ uint32_t libxl_vm_get_start_time(libxl_ctx *ctx, 
uint32_t domid)
 return ret;
 }
 
-char *libxl_tmem_list(libxl_ctx *ctx, uint32_t domid, int use_long)
-{
-int r;
-char _buf[32768];
-GC_INIT(ctx);
-
-r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_LIST, domid, 32768,
-use_long, _buf);
-if (r < 0) {
-LOGED(ERROR, domid, "Can not get tmem list");
-GC_FREE;
-return NULL;
-}
-
-GC_FREE;
-return strdup(_buf);
-}
-
-int libxl_tmem_freeze(libxl_ctx *ctx, uint32_t domid)
-{
-int r, rc;
-GC_INIT(ctx);
-
-r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_FREEZE, domid, 0, 0,
-NULL);
-if (r < 0) {
-LOGED(ERROR, domid, "Can not freeze tmem pools");
-rc = ERROR_FAIL;
-goto out;
-}
-
-rc = 0;
-out:
-GC_FREE;
-return rc;
-}
-
-int libxl_tmem_thaw(libxl_ctx *ctx, uint32_t domid)
-{
-int r, rc;
-GC_INIT(ctx);
-
-r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_THAW, domid, 0, 0,
-NULL);
-if (r < 0) {
-LOGED(ERROR, domid, "Can not thaw tmem pools");
-rc = ERROR_FAIL;
-goto out;
-}
-
-rc = 0;
-out:
-GC_FREE;
-return rc;
-}
-
-static int32_t tmem_setop_from_string(char *set_name, uint32_t val,
-  xen_tmem_client_t *info)
-{
-if (!strcmp(set_name, "weight"))
-info->weight = val;
-else if (!strcmp(set_name, "compress"))
-info->flags.u.compress = val;
-else
-return -1;
-
-return 0;
-}
-
-int libxl_tmem_set(libxl_ctx *ctx, uint32_t domid, char* name, uint32_t set)
-{
-int r, rc;
-xen_tmem_client_t info;
-GC_INIT(ctx);
-
-r = xc_tmem_control(ctx->xch, -1 /* pool_id */,
-XEN_SYSCTL_TMEM_OP_GET_CLIENT_INFO,
-domid, sizeof(info), 0 /* arg */, );
-if (r < 0) {
-LOGED(ERROR, domid, "Can not get tmem data!");
-rc = ERROR_FAIL;
-goto out;
-}
-rc = tmem_setop_from_string(name, set, );
-if (rc == -1) {
-LOGEVD(ERROR, -1, domid, "Invalid set, valid sets are 
");
-rc = ERROR_INVAL;
-goto out;
-}
-r = xc_tmem_control(ctx->xch, -1 /* pool_id */,
-XEN_SYSCTL_TMEM_OP_SET_CLIENT_INFO,
-domid, sizeof(info), 0 /* arg */, );
-if (r < 0) {
-LOGED(ERROR, domid, "Can not set tmem %s", name);
-rc = ERROR_FAIL;
-goto out;
-}
-
-rc = 0;
-out:
-GC_FREE;
-return rc;
-}
-
-int libxl_tmem_shared_auth(libxl_ctx *ctx, uint32_t domid,
-   char* uuid, int auth)
-{
-int r, rc;
-GC_INIT(ctx);
-
-r = xc_tmem_auth(ctx->xch, domid, uuid, auth);
-if (r < 0) {
-LOGED(ERROR, domid, "Can not set tmem shared auth");
-rc = ERROR_FAIL;
-goto out;
-}
-
-rc = 0;
-out:
-GC_FREE;
-return rc;
-}
-
-int libxl_tmem_freeable(libxl_ctx *ctx)
-{
-int r, rc;
-GC_INIT(ctx);
-
-r = xc_tmem_control(ctx->xch, -1, XEN_SYSCTL_TMEM_OP_QUERY_FREEABLE_MB,
--1, 0, 0, 0);
-if (r < 0) {
-LOGE(ERROR, "Can not get tmem freeable memory");
-rc = ERROR_FAIL;
-goto out;
-}
-
-rc = 0;
-out:
-GC_FREE;
-return rc;
-}
-
 static int fd_set_flags(libxl_ctx *ctx, int fd,
 int fcntlgetop, int fcntlsetop, const char *fl,
 int flagmask, int set_p)
diff --git a/tools/libxl/libxl_tmem.c b/tools/libxl/libxl_tmem.c
new file mode 

[Xen-devel] [PATCH v2 04/12] libxl: carve out cpupool specific functions from libxl.c

[Juergen Gross]

libxl.c has grown to an uncomfortable size. Carve out the cpupool
related functions to libxl_cpupool.c.

Signed-off-by: Juergen Gross 
---
 tools/libxl/Makefile|   1 +
 tools/libxl/libxl.c | 418 -
 tools/libxl/libxl_cpupool.c | 443 
 3 files changed, 444 insertions(+), 418 deletions(-)
 create mode 100644 tools/libxl/libxl_cpupool.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 91e2f97..0125871 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -137,6 +137,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
libxl_vtpm.o libxl_nic.o \
+   libxl_cpupool.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 6b87f48..d0080ca 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -683,100 +683,6 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo 
*info_r,
 return 0;
 }
 
-/* Returns:
- *   0 - success
- *   ERROR_FAIL + errno == ENOENT - no entry found
- *   ERROR_$FOO + errno != ENOENT - other failure
- */
-static int cpupool_info(libxl__gc *gc,
-libxl_cpupoolinfo *info,
-uint32_t poolid,
-bool exact /* exactly poolid or >= poolid */)
-{
-xc_cpupoolinfo_t *xcinfo;
-int rc = ERROR_FAIL;
-
-xcinfo = xc_cpupool_getinfo(CTX->xch, poolid);
-if (xcinfo == NULL)
-{
-if (exact || errno != ENOENT)
-LOGE(ERROR, "failed to get info for cpupool%d", poolid);
-return ERROR_FAIL;
-}
-
-if (exact && xcinfo->cpupool_id != poolid)
-{
-LOG(ERROR, "got info for cpupool%d, wanted cpupool%d\n",
-xcinfo->cpupool_id, poolid);
-goto out;
-}
-
-info->poolid = xcinfo->cpupool_id;
-info->pool_name = libxl_cpupoolid_to_name(CTX, info->poolid);
-if (!info->pool_name) {
-rc = ERROR_FAIL;
-goto out;
-}
-info->sched = xcinfo->sched_id;
-info->n_dom = xcinfo->n_dom;
-rc = libxl_cpu_bitmap_alloc(CTX, >cpumap, 0);
-if (rc)
-goto out;
-
-memcpy(info->cpumap.map, xcinfo->cpumap, info->cpumap.size);
-
-rc = 0;
-out:
-xc_cpupool_infofree(CTX->xch, xcinfo);
-return rc;
-}
-
-int libxl_cpupool_info(libxl_ctx *ctx,
-   libxl_cpupoolinfo *info, uint32_t poolid)
-{
-GC_INIT(ctx);
-int rc = cpupool_info(gc, info, poolid, true);
-GC_FREE;
-return rc;
-}
-
-libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx *ctx, int *nb_pool_out)
-{
-GC_INIT(ctx);
-libxl_cpupoolinfo info, *ptr;
-
-int i;
-uint32_t poolid;
-
-ptr = NULL;
-
-poolid = 0;
-for (i = 0;; i++) {
-libxl_cpupoolinfo_init();
-if (cpupool_info(gc, , poolid, false)) {
-libxl_cpupoolinfo_dispose();
-if (errno != ENOENT) goto out;
-break;
-}
-
-ptr = libxl__realloc(NOGC, ptr, (i+1) * sizeof(libxl_cpupoolinfo));
-ptr[i] = info;
-poolid = info.poolid + 1;
-/* Don't dispose of info because it will be returned to caller */
-}
-
-*nb_pool_out = i;
-
-GC_FREE;
-return ptr;
-
-out:
-libxl_cpupoolinfo_list_free(ptr, i);
-*nb_pool_out = 0;
-GC_FREE;
-return NULL;
-}
-
 /* this API call only list VM running on this host. A VM can
  * be an aggregate of multiple domains. */
 libxl_vminfo * libxl_list_vm(libxl_ctx *ctx, int *nb_vm_out)
@@ -6253,330 +6159,6 @@ out:
 return rc;
 }
 
-int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap)
-{
-int ncpus;
-
-ncpus = libxl_get_max_cpus(ctx);
-if (ncpus < 0)
-return ncpus;
-
-cpumap->map = xc_cpupool_freeinfo(ctx->xch);
-if (cpumap->map == NULL)
-return ERROR_FAIL;
-
-cpumap->size = (ncpus + 7) / 8;
-
-return 0;
-}
-
-int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
- libxl_scheduler sched,
- libxl_bitmap cpumap, libxl_uuid *uuid,
- uint32_t *poolid)
-{
-GC_INIT(ctx);
-int rc;
-int i;
-xs_transaction_t t;
-char *uuid_string;
-
-uuid_string = libxl__uuid2string(gc, *uuid);
-if (!uuid_string) {
-GC_FREE;
-return ERROR_NOMEM;
-}
-
-rc = xc_cpupool_create(ctx->xch, poolid, sched);
-if (rc) {
-LOGEV(ERROR, rc, "Could not create cpupool");
-GC_FREE;
-return ERROR_FAIL;
-}
-
-libxl_for_each_bit(i, cpumap)
-if (libxl_bitmap_test(, i)) {
-rc = xc_cpupool_addcpu(ctx->xch, *poolid, i);
-if (rc) {
-   

Re: [Xen-devel] [PATCH v6] x86/hvm: add vcpu parameter to guest memory copy function

[Roger Pau Monne]

On Thu, Feb 09, 2017 at 03:10:10AM -0700, Jan Beulich wrote:
> >>> On 07.02.17 at 18:35,  wrote:
> > @@ -3178,9 +3179,9 @@ static enum hvm_copy_result __hvm_copy(
> >  {
> >  static unsigned long lastpage;
> >  if ( xchg(, gfn) != gfn )
> > -gdprintk(XENLOG_DEBUG, "guest attempted write to 
> > read-only"
> > +printk(XENLOG_DEBUG, "%pv guest attempted write to 
> > read-only"
> 
> This broke the build, and I can't see how it would have built for you.
> I've converted it to dprintk(XENLOG_G_DEBUG, ...) to retain as many
> of the original properties as possible.

Hm, this is currently building fine for me using clang 3.8. In any case, thanks
and sorry for the trouble.

Roger.

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

[Xen-devel] [PATCH] x86/acpi: fix unmapping of low 1MB memory in acpi_os_unmap_memory

[Roger Pau Monne]

Current code in acpi_os_map_memory uses the direct map in order to map memory
in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account, and
always tries to perform a vunmap, which results in the following WARN:

(XEN) Xen WARN at vmap.c:185
(XEN) [ Xen-4.9-unstable  x86_64  debug=y   Tainted:  C   ]
(XEN) CPU:0
(XEN) RIP:e008:[] vmap.c#vm_free+0xd7/0xe0
[...]
(XEN) Xen call trace:
(XEN)[] vmap.c#vm_free+0xd7/0xe0
(XEN)[] acpi_find_root_pointer+0x3a/0x170
(XEN)[] acpi_os_get_root_pointer+0x4e/0x60
(XEN)[] domain_build.c#pvh_setup_acpi_xsdt+0x90/0x240
(XEN)[] domain_build.c#pvh_setup_acpi+0x18a/0x2e0
(XEN)[] domain_build.c#construct_dom0_pvh+0xd2/0x120
(XEN)[] __start_xen+0x1d14/0x2420
(XEN)[] __high_start+0x53/0x60

Fix this by checking if the virtual address passed to acpi_os_unmap_memory
belongs to the direct map.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
 xen/drivers/acpi/osl.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 7199047..930e2d9 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -104,6 +104,13 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size 
size)
 
 void acpi_os_unmap_memory(void __iomem * virt, acpi_size size)
 {
+   if (IS_ENABLED(CONFIG_X86) &&
+   (unsigned long)virt >= DIRECTMAP_VIRT_START &&
+   (unsigned long)virt < DIRECTMAP_VIRT_END) {
+   ASSERT(!((__pa(virt) + size - 1) >> 20));
+   return;
+   }
+
if (system_state >= SYS_STATE_boot)
vunmap((void *)((unsigned long)virt & PAGE_MASK));
 }
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [linux-linus test] 105655: regressions - FAIL

[Dario Faggioli]

On Thu, 2017-02-09 at 10:00 +, osstest service owner wrote:
> flight 105655 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/105655/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR.
> vs. 59254
>  test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR.
> vs. 59254
>  test-amd64-amd64-xl-xsm  17 guest-localmigrate/x10fail REGR.
> vs. 59254
>  test-amd64-i386-xl   17 guest-localmigrate/x10fail REGR.
> vs. 59254
>  test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR.
> vs. 59254
>
I gave a quick look at these ones above, and it looks to me that Linux
is panicing either while freezing:

http://logs.test-lab.xenproject.org/osstest/logs/105655/test-amd64-amd64-xl-credit2/rimava0---var-log-xen-console-guest-debian.guest.osstest.log
http://logs.test-lab.xenproject.org/osstest/logs/105655/test-amd64-amd64-xl-multivcpu/elbling1---var-log-xen-console-guest-debian.guest.osstest.log

Or when trying to come back:

http://logs.test-lab.xenproject.org/osstest/logs/105655/test-amd64-amd64-xl/godello0---var-log-xen-console-guest-debian.guest.osstest--incoming.log
http://logs.test-lab.xenproject.org/osstest/logs/105655/test-amd64-i386-xl/chardonnay0---var-log-xen-console-guest-debian.guest.osstest--incoming.log

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

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

Re: [Xen-devel] [PATCH] x86/acpi: fix unmapping of low 1MB memory in acpi_os_unmap_memory

[Jan Beulich]

>>> On 09.02.17 at 11:37,  wrote:
> Current code in acpi_os_map_memory uses the direct map in order to map memory
> in the low 1MB, but acpi_os_unmap_memory doesn't takes that into account, 
> and
> always tries to perform a vunmap, which results in the following WARN:
> 
> (XEN) Xen WARN at vmap.c:185
> (XEN) [ Xen-4.9-unstable  x86_64  debug=y   Tainted:  C   ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] vmap.c#vm_free+0xd7/0xe0
> [...]
> (XEN) Xen call trace:
> (XEN)[] vmap.c#vm_free+0xd7/0xe0
> (XEN)[] acpi_find_root_pointer+0x3a/0x170
> (XEN)[] acpi_os_get_root_pointer+0x4e/0x60
> (XEN)[] domain_build.c#pvh_setup_acpi_xsdt+0x90/0x240
> (XEN)[] domain_build.c#pvh_setup_acpi+0x18a/0x2e0
> (XEN)[] domain_build.c#construct_dom0_pvh+0xd2/0x120
> (XEN)[] __start_xen+0x1d14/0x2420
> (XEN)[] __high_start+0x53/0x60
> 
> Fix this by checking if the virtual address passed to acpi_os_unmap_memory
> belongs to the direct map.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 


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

[Xen-devel] [ovmf test] 105658: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 41ccec58e07376fe3086d3fb4cf6290c53ca2303
baseline version:
 ovmf ad1cd1aa09c0a8660c857de916105b1fd566ca8c

Last test of basis   105652  2017-02-09 00:45:19 Z0 days
Testing same since   105658  2017-02-09 05:46:04 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=41ccec58e07376fe3086d3fb4cf6290c53ca2303
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
41ccec58e07376fe3086d3fb4cf6290c53ca2303
+ branch=ovmf
+ revision=41ccec58e07376fe3086d3fb4cf6290c53ca2303
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x41ccec58e07376fe3086d3fb4cf6290c53ca2303 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

[David Woodhouse]

On Thu, 2017-02-09 at 01:56 -0700, Jan Beulich wrote:
> 
> > diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> > index 86c71be..3d9386a 100644
> > --- a/xen/arch/x86/hvm/mtrr.c
> > +++ b/xen/arch/x86/hvm/mtrr.c
> > @@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
> > gfn, 
> >  
> >  if ( direct_mmio )
> >  {
> > +    ASSERT(direct_mmio == is_iomem_page(mfn)); 
> > +
> >  if ( (mfn_x(mfn) ^ d->arch.hvm_domain.vmx.apic_access_mfn) >> 
> >order )
> >  return MTRR_TYPE_UNCACHABLE;
> >  if ( order )
> > 
> > But when I try to create a hvm domain, it failed. logs are below.
> 
> Considering the context of the change above, I'm not surprised:
> You've very likely hit the APIC access MFN.

You'll probably hit it for INVALID_MFN too on an unmap. And *do* make
it print the offending address when it triggers. :)

smime.p7s
Description: S/MIME cryptographic signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [xen-unstable test] 104131: regressions - FAIL

[Xuquan (Quan Xu)]

On February 08, 2017 4:22 PM, Chao Gao wrote:
>On Wed, Feb 08, 2017 at 10:15:28AM +, Xuquan (Quan Xu) wrote:
>>On February 08, 2017 4:52 PM, Jan Beulich wrote:
>> On 08.02.17 at 09:27,  wrote:
 Assumed vCPU is in guest_mode..
 When apicv is enabled, hypervisor calls vmx_deliver_posted_intr(),
 then
 __vmx_deliver_posted_interrupt() to deliver interrupt, but no vmexit
 (also no
 vcpu_kick() )..
 In __vmx_deliver_posted_interrupt(), it is __conditional__ to
 deliver posted interrupt. if posted interrupt is not delivered, the
 posted interrupt is pending until next VM entry -- by PIR to vIRR..

 one condition is :
 In __vmx_deliver_posted_interrupt(),  ' if (
 !test_and_set_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))' ..

 Specifically, we did verify it by RES interrupt, which is used for
 smp_reschedule_interrupt..
 We even cost more time to deliver RES interrupt than no-apicv in
>>>average..

 If RES interrupt (no. 1) is delivered by posted way (the vcpu is
 still guest_mode).. when tries to deliver next-coming RES interrupt
 (no. 2) by posted way, The next-coming RES interrupt (no. 2) is not
 delivered, as we set the VCPU_KICK_SOFTIRQ bit when we deliver RES
>interrupt (no.
 1)..

 Then the next-coming RES interrupt (no. 2) is pending until next VM
 entry -- by PIR to vIRR..


 We can fix it as below(I don't think this is a best one, it is
 better to set the VCPU_KICK_SOFTIRQ bit, but not test it):

 --- a/xen/arch/x86/hvm/vmx/vmx.c
 +++ b/xen/arch/x86/hvm/vmx/vmx.c
 @@ -1846,7 +1846,7 @@ static void
>>>__vmx_deliver_posted_interrupt(struct vcpu *v)
  {
  unsigned int cpu = v->processor;

 -if ( !test_and_set_bit(VCPU_KICK_SOFTIRQ,
>>>_pending(cpu))
 +if ( !test_bit(VCPU_KICK_SOFTIRQ, _pending(cpu))
   && (cpu != smp_processor_id()) )
  send_IPI_mask(cpumask_of(cpu), posted_intr_vector);
  }
>>>
>>>While I don't think I fully understand your description,
>>
>>Sorry!!
>>
>>>the line you change
>>>here has always been puzzling me: If we were to raise a softirq here,
>>>we ought to call cpu_raise_softirq() instead of partly open coding what it
>does.
>>>So I think not marking that softirq pending (but doing this
>>>incompletely) is a valid change in any case.
>>
>>As comments in pi_notification_interrupt()  --
>>xen/arch/x86/hvm/vmx/vmx.c 
>> *
>> * we need to set VCPU_KICK_SOFTIRQ for the current cpu, just like
>> * __vmx_deliver_posted_interrupt(). So the pending interrupt in
>PIRR will
>> * be synced to vIRR before VM-Exit in time.
>> *
>>
>>
>>I think setting VCPU_KICK_SOFTIRQ bit -- the pending interrupt in PIRR will
>be synced to vIRR before VM-Exit in time.
>>That's also why i said it is better to set the VCPU_KICK_SOFTIRQ bit, but
>not test it..
>>
>
>I think there is a typo. It should be "before VM-Entry in time". It set
>VCPU_KICK_SOFTIRQ bit only to jump to vmx_do_vmentry again instead of
>entering guest directly. Jumping to vmx_do_vmentry again can re-sync the
>PIR to vIRR in vmx_intr_assist(). 

impressive analysis..
chao, could you show the related code?

Quan


>In root-mode, cpu treat the pi notification
>interrupt as normal interrupt, so cpu will run the interrupt handler
>pi_notification_interrupt() instead of syncing PIR to vIRR automatically.
>Receiving a pi notificatio interrupt means some interrupts have been
>posted in PIR. Setting that bit is to deliver these new arrival interrupts
>before this VM-entry.
>


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

[Xen-devel] 4.7.2 / 4.6.5 preparations

[Jan Beulich]

All,

these stable releases are due in about 3 weeks time. Please indicate
backports you consider necessary but find still missing. Commits
already marked for backporting:

e719192026 xen: credit2: never consider CPUs outside of our cpupool.
(for 4.7.5 only, unless anyone cares to also provide 4.6 backports of
not just this, but also 548db87428 and 7478ebe160+ad5808d905, if
applicable in the first place)

30921dc2df x86/ept: allow write-combining on !mfn_valid() MMIO mappings again

Jan


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

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

[Wei Liu]

Hmm... not sure why my reply didn't have you in the To: field.

On Thu, Feb 09, 2017 at 10:13:13AM +, Wei Liu wrote:
> On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote:
> > On 02/08/17 10:31 +, Wei Liu wrote:
> > > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:
> > > > On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> > > > > > If any error code is returned when creating a domain, stop the 
> > > > > > domain
> > > > > > creation.
> > > > >
> > > > > This looks like it is a bug-fix that can be spun off from this
> > > > > patchset?
> > > > >
> > > > 
> > > > Yes, if everyone considers it's really a bug and the fix does not
> > > > cause compatibility problem (e.g. xl w/o this patch does not abort the
> > > > domain creation if it fails to connect to QEMU VNC port).
> > > > 
> > > 
> > > I'm two minded here. If the failure to connect is caused by some
> > > temporary glitches in QEMU and we're sure it will eventually succeed,
> > > there is no need to abort domain creation. If failure to connect is due
> > > to permanent glitches, we should abort.
> > > 
> > 
> > Sorry, I should say "*query* QEMU VNC port" instead of *connect*.
> > 
> > libxl__qmp_initializations() currently does following tasks.
> > 1/ Create a QMP socket.
> > 
> >   I think all failures in 1/ should be considered as permanent. It
> >   does not only fail the following tasks, but also fails the device
> >   hotplug which needs to cooperate with QEMU.
> > 
> > 2/ If 1/ succeeds, query qmp about parameters of serial port and fill
> >   them in xenstore.
> > 3/ If 1/ and 2/ succeed, set and query qmp about parameters (password,
> >   address, port) of VNC and fill them in xenstore.
> > 
> >   If we assume Xen always send the correct QMP commands and
> >   parameters, the QMP failures in 2/ and 3/ will be caused by QMP
> >   socket errors (see qmp_next()), which are hard to tell whether they
> >   are permanent or temporal. However, if the missing of serial port
> >   or VNC is considered as not affecting the execution of guest
> >   domain, we may ignore failures here.
> > 
> > > OOI how did you discover this issue? That could be the key to understand
> > > the issue here.
> > 
> > The next patch adds code in libxl__qmp_initialization() to query qmp
> > about vNVDIMM parameters (e.g. the base gpfn which is calculated by
> > QEMU) and return error code if it fails. While I was developing that
> > patch, I found xl didn't stop even if bugs in my QEMU patches failed
> > the code in my Xen patch.
> > 
> 
> Right, this should definitely be fatal.
> 
> > Maybe we could let libxl__qmp_initializations() report whether a
> > failure can be tolerant. For non-tolerant failures (e.g. those in 1/),
> > xl should stop. For tolerant failures (e.g. those in 2/ and 3/), xl
> > can continue, but it needs to warn those failures.
> > 
> 
> Yes, we can do that. It's an internal function, we can change things as
> we see fit.
> 
> I would suggest you only make vNVDIMM failure fatal as a start.
> 
> Wei.

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

Re: [Xen-devel] 4.7.2 / 4.6.5 preparations

[Andrew Cooper]

On 09/02/17 09:52, Jan Beulich wrote:
> All,
>
> these stable releases are due in about 3 weeks time. Please indicate
> backports you consider necessary but find still missing. Commits
> already marked for backporting:
>
> e719192026 xen: credit2: never consider CPUs outside of our cpupool.
> (for 4.7.5 only, unless anyone cares to also provide 4.6 backports of
> not just this, but also 548db87428 and 7478ebe160+ad5808d905, if
> applicable in the first place)
>
> 30921dc2df x86/ept: allow write-combining on !mfn_valid() MMIO mappings again

Neither are functional fixes, but d0fd9ae54491 and d45fae589b8d are both
useful as extra information.  (Both of these patches originated because
of an absence of information in customer bug reports.)

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[Wei Liu]

On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
> On 08/02/17 16:11, Dario Faggioli wrote:
> > On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
> >> Callers to libxl_cpupool_create() can either request a specific pool
> >> id, or request that Xen do it for them.  But at the moment, the
> >> "automatic" selection is indicated by using a magic value, 0.  This
> >> is
> >> undesirable both because it doesn't obviously have meaning, but also
> >> because '0' is a valid cpupool (albeit one which at the moment can't
> >> be changed).
> >>
> >> Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
> >> instead.  Still accept '0' as meaning "ANY" for backwards
> >> compatibility.
> >>
> >> Signed-off-by: George Dunlap 
> >>
> > Reviewed-by: Dario Faggioli 
> > 
> > With one remark.
> > 
> >> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> >> --- a/tools/libxl/libxl.h
> >> +++ b/tools/libxl/libxl.h
> >> @@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx,
> >> uint32_t domid, char* uuid,
> >>  int libxl_tmem_freeable(libxl_ctx *ctx);
> >>  
> >>  int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
> >> +
> >> +/* 
> >> + * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
> >> + * free poolid for you.
> >> + */
> >> +#define LIBXL_CPUPOOL_POOLID_ANY 0x
> >>
> > Do we want this to be here, or in libxl_types.idl.
> > 
> > Asking because, AFAICT, it's the only one LIBXL_FOO_BAR defined like
> > this. I appreciate that there's few point in making this an enum, as it
> > is only one value, and will most likely remain so, but still, I thought
> > I'd at least bring this up.
> > 
> > FWIW, my Reviewed-by stands both if it is kept as is, and if it is
> > moved to IDL.
> 
> Well there's things like:
> 
> #define LIBXL_PCI_FUNC_ALL (~0U)
> 
> #define LIBXL_TIMER_MODE_DEFAULT -1
> #define LIBXL_MEMKB_DEFAULT ~0ULL
> 
> #define LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT (2048 * 1024)
> 
> #define LIBXL_MS_VM_GENID_LEN 16
> 
> #define LIBXL_SUSPEND_DEBUG 1
> #define LIBXL_SUSPEND_LIVE 2
> 
> Many of which seem similar in some ways.  Enums I think are meant to be
> exhaustive (as in, contain all possible options), not be special cases.
> 
> But I'm happy to defer to the tools maintainers.
> 

I don't really care if it is an enum or a macro.

There is an issue that is  more subtle than where it lives or what form
it is in.

You need to modify all the poolid fields in various structure to make it
as default.  Otherwise the whole json infrastructure would still use 0
as the default value.

And maybe a LIBXL_HAVE macro is needed, too.

Wei.

>  -George
> 
> > 
> > Regards,
> > Dario
> > 
> 

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

Re: [Xen-devel] [PATCH 1/2] tools/libxc: Introduce XC_CPUPOOL_POOLID_ANY

[Wei Liu]

On Wed, Feb 08, 2017 at 02:51:45PM +, George Dunlap wrote:
> Callers to xc_cpupool_create() can either request a specific pool id,
> or request that Xen do it for them.  But at the moment, the
> "automatic" selection is indicated by using a magic value, 0.  This is
> undesirable both because it doesn't obviously have meaning, but also
> because '0' is a valid cpupool (albeit one which at the moment can't
> be changed).
> 
> Introduce a constant, XC_CPUPOOL_POOLID_ANY, to indicate this instead.
> Have it be the default for the python bindings.
> 
> Manually translate it, even though it's the same underlying value,
> because we don't yet have a relaible way of enforcing that these
> values are the same.
> 
> Signed-off-by: George Dunlap 
> ---
> 
> I realize this is somewhat of a bike shed, but I want to avoid
> propagating this "magic number" interface into the xenlight bindings
> if I can.
> 
> Also, at some point we might use the IDL to enforce that the libxl
> values are identical to the Xen values, at which point we can just
> pass the value in directly.
> 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH RESEND v17] xen/sndif: Add sound-device ABI

[Oleksandr Andrushchenko]

On 02/08/2017 05:29 PM, Konrad Rzeszutek Wilk wrote:

. snip..

Reviewed-by: Konrad Rzeszutek Wilk 



Couple of issues I found in sndif while preparing displif for review:
1. missing string constants
+#define XENSND_FIELD_BE_VERSIONS"versions"
+#define XENSND_FIELD_FE_VERSION "version"

2. I would like to have one more part in the state diagrams section
which is currently missing: recovery flow for the case when
backend/frontend dies:

+ *--- Recovery flow 
---

+ *
+ * In case of frontend unrecoverable errors backend handles that as
+ * if frontend goes into the XenbusStateClosed state.
+ *
+ * In case of backend unrecoverable errors frontend tries removing
+ * the emulated device. If this is possible at the moment of error,
+ * then frontend goes into the XenbusStateInitialising state and is 
ready for

+ * new connection with backend. If the emulated device is still in use and
+ * cannot be removed, then frontend goes into the 
XenbusStateReconfiguring state

+ * until either the emulated device removed or backend initiates a new
+ * connection. On the emulated device removal frontend goes into the
+ * XenbusStateInitialising state.
+ *

Thank you,
Oleksandr

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

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

[Jan Beulich]

>>> On 09.02.17 at 09:27,  wrote:
> On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote:
> On 08.02.17 at 08:31,  wrote:
  From: Jan Beulich [mailto:jbeul...@suse.com]
 Sent: Monday, February 06, 2017 11:38 PM
 
 >>> On 06.02.17 at 15:48,  wrote:
 > On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
 >> >
 >> > >
 >> > > >
 >> > > > On 06.02.17 at 14:55,  wrote:
 >> > Switch its return type to bool to match its use, and simplify the
 >> > ARM
 >> > implementation slightly.
 >> >
 >> > No functional change.
 >> >
 >> > Signed-off-by: Andrew Cooper 
 >> Reviewed-by: Jan Beulich 
 >>
 >> And perhaps that's what should be used in epte_get_entry_emt()
 >> instead of !mfn_valid() in David's patch. David, would you be okay
 >> with your patch changed to that effect upon commit?
 >
 > I don't think that works, at least not literally
 > s/!mfn_valid()/is_iomem_page()/
 >
 > In my patch, mfn_valid() is checked *after* we've processed the
 > 'direct_mmio' case that all MMIO should hit. In a sane world I think
 > it's *only* actually catching INVALID_MFN, and probably should never
 > match on any other value of mfn.
 >
 > I don't quite understand why we pass 'direct_mmio' in as a separate
 > argument. Perhaps there's scope for doing a sanity check that
 > 'direct_mmio == is_iomem_page(mfn)' — because when would that *not* be
 > true?
 
 Likely never. The reasons for why this was done the way it is
 escape me. Adding VMX maintainers once again.
>>> 
>>> I'm not the original author of that code. Here is what I found from the 
>>> code:
>>> 
>>> There are two places caring direct_mmio: resolve_misconfig and ept_
>>> set_entry. It's decided upon p2m type:
>>> 
>>>   int emt = epte_get_entry_emt(p2m->domain, gfn, _mfn(e.mfn),
>>> level * EPT_TABLE_ORDER, ,
>>> e.sa_p2mt == p2m_mmio_direct);
>>> 
>>> I'm not sure whether p2m_mmio_direct always makes is_iomem_page
>>> true. If true then yes we may not require this parameter at all.
>>
>>From an abstract perspective the two should always correlate. We
>>may want to take an intermediate step though and first only add
>>checking, and perhaps a release later remove the extra parameter
>>if the check never triggered for anyone.
>>
> 
> I add one assertion to the original code, like below.
> 
> diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
> index 86c71be..3d9386a 100644
> --- a/xen/arch/x86/hvm/mtrr.c
> +++ b/xen/arch/x86/hvm/mtrr.c
> @@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
> gfn, 
>  
>  if ( direct_mmio )
>  {
> +ASSERT(direct_mmio == is_iomem_page(mfn)); 
> +
>  if ( (mfn_x(mfn) ^ d->arch.hvm_domain.vmx.apic_access_mfn) >> order )
>  return MTRR_TYPE_UNCACHABLE;
>  if ( order )
> 
> But when I try to create a hvm domain, it failed. logs are below.

Considering the context of the change above, I'm not surprised:
You've very likely hit the APIC access MFN.

Jan

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

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
> On Thu, 9 Feb 2017, Julien Grall wrote:
> > On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  wrote:
> > > > Hi Tamas,
> > > > 
> > > > Can you please try to configure your e-mail client to use '>' rather 
> > > > than
> > > > '
> > > > '? It makes quite hard to read the e-mail.
> > > 
> > > Hm, not sure why it switched but should be fine now.
> > > 
> > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> > > > > > wrote:
> > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias wrote:
> > > > 
> > > > 
> > > > > If platform_hvc() consumes an SMC, it's considered part of the Xen
> > > > > API.
> > > > > Visible but not filterable by a monitor.
> > > > > 
> > > > > 
> > > > > Platforms can then dictate which SMC calls are better handled 
> > > > > within
> > > > > Xen and
> > > > > which ones can be exposed to dom0 user-space.
> > > > > 
> > > > > In addition, there could be a hypercall to disable platform 
> > > > > specific
> > > > > handling
> > > > > in Xen alltogether for a given guest. Then everything goes to dom0
> > > > > user-space.
> > > > > 
> > > > > It's a little messy...
> > > > > 
> > > > > 
> > > > > 
> > > > > That is messy and I would not want any SMCs reaching the firmware when
> > > > > the monitor application is in use. The monitor interface is disabled 
> > > > > by
> > > > > default and there aren't any known usecases where the SMC has to reach
> > > > > both the firmware and the monitor application as well. So I think it 
> > > > > is
> > > > > safe to just make the two things mutually exclusive.
> > > > 
> > > > 
> > > > If you look at the SMC Calling Convention [1] both HVC and SMC are
> > > > considered a conduit for service call to the secure firmware or
> > > > hypervisor.
> > > > It would be up to the hypervisor deciding what to do.
> > > > 
> > > > Lets imagine the guest is deciding to use HVC to access the secure
> > > > firmware
> > > > (AFAIU this patch series is adding that), are you going to monitor all 
> > > > the
> > > > HVCs (including hypercall)?
> > > 
> > > There are some fundamental differences between HVC and SMC calls
> > > though. An HVC can only land in the hypervisor, so as a hypercall, I
> > > would expect it to be something I can deny via XSM. That is a
> > > sufficient option for now to block the path to the firmware. If we end
> > > up needing to support an application that uses that hypercall for
> > > something critical, then yes, it would also need to be hooked into the
> > > monitor system. At the moment this is not necessary.
> > 
> > My point is not about what is necessary at the moment. But what is right
> > things to do. If you look at the spec, HVC are not only for hypercall, but 
> > any
> > other kind of services. Why would you deny something that is valid from the
> > specification (see 5.2.1)?
> > 
> > "The SMC calling convention, however, does not specify which instruction
> > (either SMC or HVC) to use to invoke a
> > particular service."
> 
> To have a generic solution, we need a way to specify a set of HVC/SMC
> calls that get monitored and a set that get handled in Xen (platform
> specific or otherwise). I think it is OK not to do both, at least at the
> beginning, but we might want to add that feature in the future.
> 
> As much as I would like to see that, in respect to this series, I don't
> think we should ask Edgar to introduce such a mechanism. However, we do
> need to decide what Xen should do when platform_hvc is implemented and
> monitor is also enabled.
> 
> I think the default should be to only call platform_hvc, because there
> are many valid monitoring use-cases which don't require those few
> platform specific SMC/HVC calls to be forwarded to the monitor.
> 
> However, if we did that, we would break Tamas' scenario. Thus, I suggest
> we also introduce a simple compile time option or Xen command line
> option to forward all platform_hvc calls to the monitor instead of
> implementing them in Xen. Something like "MONITOR_OVERRIDE". In the
> future, we can replace it with a more generic framework to dynamically
> configure at runtime which SMC/HVC calls get forwarded.
> 
> What do you think?

This could work in some scenarios, but for example on the ZynqMP,
dom0 needs access to Firmware as it boots, otherwise a lot of I/O
will end up non-functional (with recent kernels). Anyway, I think it
would give us a path forward. Future patches could either implement
finer control or something else.

Perhaps a hypercall to allow dom0 to turn off any platform_hvc handling for
a given guest would help. If that mode is enabled, Xen is hands off on
any platform specific HVC/SMC. It still leaves the 

Re: [Xen-devel] [RFC v2 3/6] xen/arm: Allow platform_hvc to handle guest SMC calls

[Edgar E. Iglesias]

On Thu, Feb 09, 2017 at 10:12:41AM +0100, Edgar E. Iglesias wrote:
> On Wed, Feb 08, 2017 at 05:20:44PM -0800, Stefano Stabellini wrote:
> > On Thu, 9 Feb 2017, Julien Grall wrote:
> > > On 08/02/2017 23:28, Tamas K Lengyel wrote:
> > > > On Wed, Feb 8, 2017 at 3:04 PM, Julien Grall  
> > > > wrote:
> > > > > Hi Tamas,
> > > > > 
> > > > > Can you please try to configure your e-mail client to use '>' rather 
> > > > > than
> > > > > '
> > > > > '? It makes quite hard to read the e-mail.
> > > > 
> > > > Hm, not sure why it switched but should be fine now.
> > > > 
> > > > > On 08/02/2017 20:15, Tamas K Lengyel wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, Feb 8, 2017 at 12:40 PM, Edgar E. Iglesias
> > > > > > > wrote:
> > > > > > On Wed, Feb 08, 2017 at 06:29:13PM +0100, Edgar E. Iglesias 
> > > > > > wrote:
> > > > > 
> > > > > 
> > > > > > If platform_hvc() consumes an SMC, it's considered part of the 
> > > > > > Xen
> > > > > > API.
> > > > > > Visible but not filterable by a monitor.
> > > > > > 
> > > > > > 
> > > > > > Platforms can then dictate which SMC calls are better handled 
> > > > > > within
> > > > > > Xen and
> > > > > > which ones can be exposed to dom0 user-space.
> > > > > > 
> > > > > > In addition, there could be a hypercall to disable platform 
> > > > > > specific
> > > > > > handling
> > > > > > in Xen alltogether for a given guest. Then everything goes to 
> > > > > > dom0
> > > > > > user-space.
> > > > > > 
> > > > > > It's a little messy...
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > That is messy and I would not want any SMCs reaching the firmware 
> > > > > > when
> > > > > > the monitor application is in use. The monitor interface is 
> > > > > > disabled by
> > > > > > default and there aren't any known usecases where the SMC has to 
> > > > > > reach
> > > > > > both the firmware and the monitor application as well. So I think 
> > > > > > it is
> > > > > > safe to just make the two things mutually exclusive.
> > > > > 
> > > > > 
> > > > > If you look at the SMC Calling Convention [1] both HVC and SMC are
> > > > > considered a conduit for service call to the secure firmware or
> > > > > hypervisor.
> > > > > It would be up to the hypervisor deciding what to do.
> > > > > 
> > > > > Lets imagine the guest is deciding to use HVC to access the secure
> > > > > firmware
> > > > > (AFAIU this patch series is adding that), are you going to monitor 
> > > > > all the
> > > > > HVCs (including hypercall)?
> > > > 
> > > > There are some fundamental differences between HVC and SMC calls
> > > > though. An HVC can only land in the hypervisor, so as a hypercall, I
> > > > would expect it to be something I can deny via XSM. That is a
> > > > sufficient option for now to block the path to the firmware. If we end
> > > > up needing to support an application that uses that hypercall for
> > > > something critical, then yes, it would also need to be hooked into the
> > > > monitor system. At the moment this is not necessary.
> > > 
> > > My point is not about what is necessary at the moment. But what is right
> > > things to do. If you look at the spec, HVC are not only for hypercall, 
> > > but any
> > > other kind of services. Why would you deny something that is valid from 
> > > the
> > > specification (see 5.2.1)?
> > > 
> > > "The SMC calling convention, however, does not specify which instruction
> > > (either SMC or HVC) to use to invoke a
> > > particular service."
> > 
> > To have a generic solution, we need a way to specify a set of HVC/SMC
> > calls that get monitored and a set that get handled in Xen (platform
> > specific or otherwise). I think it is OK not to do both, at least at the
> > beginning, but we might want to add that feature in the future.
> > 
> > As much as I would like to see that, in respect to this series, I don't
> > think we should ask Edgar to introduce such a mechanism. However, we do
> > need to decide what Xen should do when platform_hvc is implemented and
> > monitor is also enabled.
> > 
> > I think the default should be to only call platform_hvc, because there
> > are many valid monitoring use-cases which don't require those few
> > platform specific SMC/HVC calls to be forwarded to the monitor.
> > 
> > However, if we did that, we would break Tamas' scenario. Thus, I suggest
> > we also introduce a simple compile time option or Xen command line
> > option to forward all platform_hvc calls to the monitor instead of
> > implementing them in Xen. Something like "MONITOR_OVERRIDE". In the
> > future, we can replace it with a more generic framework to dynamically
> > configure at runtime which SMC/HVC calls get forwarded.
> > 
> > What do you think?
> 
> This could work in some scenarios, but for example on the ZynqMP,
> dom0 needs access to Firmware as it boots, otherwise a lot of I/O
> will end up 

Re: [Xen-devel] [PATCH 0/9] libxl: spolit up libxl.c

[Wei Liu]

On Thu, Feb 09, 2017 at 09:51:48AM +0800, Zhang Chen wrote:
> 
> 
> On 02/09/2017 12:54 AM, Wei Liu wrote:
> > And CC Zhangchen
> 
> Thanks, I will apply this patch set before test my patch.
> 

This is not yet the final form. Please need to wait until this work gets
applied.

Wei.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

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

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

[Wei Liu]

On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote:
> On 02/08/17 10:31 +, Wei Liu wrote:
> > On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:
> > > On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> > > > > If any error code is returned when creating a domain, stop the domain
> > > > > creation.
> > > >
> > > > This looks like it is a bug-fix that can be spun off from this
> > > > patchset?
> > > >
> > > 
> > > Yes, if everyone considers it's really a bug and the fix does not
> > > cause compatibility problem (e.g. xl w/o this patch does not abort the
> > > domain creation if it fails to connect to QEMU VNC port).
> > > 
> > 
> > I'm two minded here. If the failure to connect is caused by some
> > temporary glitches in QEMU and we're sure it will eventually succeed,
> > there is no need to abort domain creation. If failure to connect is due
> > to permanent glitches, we should abort.
> > 
> 
> Sorry, I should say "*query* QEMU VNC port" instead of *connect*.
> 
> libxl__qmp_initializations() currently does following tasks.
> 1/ Create a QMP socket.
> 
>   I think all failures in 1/ should be considered as permanent. It
>   does not only fail the following tasks, but also fails the device
>   hotplug which needs to cooperate with QEMU.
> 
> 2/ If 1/ succeeds, query qmp about parameters of serial port and fill
>   them in xenstore.
> 3/ If 1/ and 2/ succeed, set and query qmp about parameters (password,
>   address, port) of VNC and fill them in xenstore.
> 
>   If we assume Xen always send the correct QMP commands and
>   parameters, the QMP failures in 2/ and 3/ will be caused by QMP
>   socket errors (see qmp_next()), which are hard to tell whether they
>   are permanent or temporal. However, if the missing of serial port
>   or VNC is considered as not affecting the execution of guest
>   domain, we may ignore failures here.
> 
> > OOI how did you discover this issue? That could be the key to understand
> > the issue here.
> 
> The next patch adds code in libxl__qmp_initialization() to query qmp
> about vNVDIMM parameters (e.g. the base gpfn which is calculated by
> QEMU) and return error code if it fails. While I was developing that
> patch, I found xl didn't stop even if bugs in my QEMU patches failed
> the code in my Xen patch.
> 

Right, this should definitely be fatal.

> Maybe we could let libxl__qmp_initializations() report whether a
> failure can be tolerant. For non-tolerant failures (e.g. those in 1/),
> xl should stop. For tolerant failures (e.g. those in 2/ and 3/), xl
> can continue, but it needs to warn those failures.
> 

Yes, we can do that. It's an internal function, we can change things as
we see fit.

I would suggest you only make vNVDIMM failure fatal as a start.

Wei.

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

Re: [Xen-devel] [PATCH v2 00/12] libxl: split up libxl.c

[Wei Liu]

On Thu, Feb 09, 2017 at 10:30:13AM +0100, Juergen Gross wrote:
> libxl.c has become rather large. Split it up into multiple files.
> 
> Changes are:
> - modification of Copyright comment (patch 1)
> - made two functions non-static: libxl__get_memory_target(),
>   xcinfo2xlinfo() (patch 2)
> - white space cleanup of libxl.c (patch 3)
> - moving functions into new or existing sources (patches 4-11):
>   just code movement, no functional changes besides needed Makefile
>   adjustments for new sources
> - made one function static: libxl__device_frontend_path() (patch 12)
> 
> Changes in V2:
> - address comments of Ian Jackson: add new patches 1-3, 12
> 
> Juergen Gross (12):
>   libxl: adjust copyright comment of libxl.c
>   libxl: make some functions global to prepare splitting up libxl.c
>   libxl: white space cleanup
>   libxl: carve out cpupool specific functions from libxl.c
>   libxl: carve out scheduler specific functions from libxl.c
>   libxl: carve out disk specific functions from libxl.c
>   libxl: carve out console specific functions from libxl.c
>   libxl: carve out memory specific functions from libxl.c
>   libxl: move device specific functions out of libxl.c
>   libxl: carve out tmem specific functions from libxl.c
>   libxl: carve out domain specific functions from libxl.c
>   libxl: make one function static
> 

Series:

Reviewed-by: Wei Liu 

I'm a bit two-minded about the last patch, though.

Wei.

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

Re: [Xen-devel] [PATCH] xen/mm: Alter is_iomem_page() to use mfn_t

[Chao Gao]

On Thu, Feb 09, 2017 at 01:56:14AM -0700, Jan Beulich wrote:
 On 09.02.17 at 09:27,  wrote:
>> On Wed, Feb 08, 2017 at 10:05:38AM -0700, Jan Beulich wrote:
>> On 08.02.17 at 08:31,  wrote:
>  From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, February 06, 2017 11:38 PM
> 
> >>> On 06.02.17 at 15:48,  wrote:
> > On Mon, 2017-02-06 at 07:26 -0700, Jan Beulich wrote:
> >> >
> >> > >
> >> > > >
> >> > > > On 06.02.17 at 14:55,  wrote:
> >> > Switch its return type to bool to match its use, and simplify the
> >> > ARM
> >> > implementation slightly.
> >> >
> >> > No functional change.
> >> >
> >> > Signed-off-by: Andrew Cooper 
> >> Reviewed-by: Jan Beulich 
> >>
> >> And perhaps that's what should be used in epte_get_entry_emt()
> >> instead of !mfn_valid() in David's patch. David, would you be okay
> >> with your patch changed to that effect upon commit?
> >
> > I don't think that works, at least not literally
> > s/!mfn_valid()/is_iomem_page()/
> >
> > In my patch, mfn_valid() is checked *after* we've processed the
> > 'direct_mmio' case that all MMIO should hit. In a sane world I think
> > it's *only* actually catching INVALID_MFN, and probably should never
> > match on any other value of mfn.
> >
> > I don't quite understand why we pass 'direct_mmio' in as a separate
> > argument. Perhaps there's scope for doing a sanity check that
> > 'direct_mmio == is_iomem_page(mfn)' — because when would that *not* be
> > true?
> 
> Likely never. The reasons for why this was done the way it is
> escape me. Adding VMX maintainers once again.
 
 I'm not the original author of that code. Here is what I found from the 
 code:
 
 There are two places caring direct_mmio: resolve_misconfig and ept_
 set_entry. It's decided upon p2m type:
 
   int emt = epte_get_entry_emt(p2m->domain, gfn, _mfn(e.mfn),
 level * EPT_TABLE_ORDER, ,
 e.sa_p2mt == p2m_mmio_direct);
 
 I'm not sure whether p2m_mmio_direct always makes is_iomem_page
 true. If true then yes we may not require this parameter at all.
>>>
>>>From an abstract perspective the two should always correlate. We
>>>may want to take an intermediate step though and first only add
>>>checking, and perhaps a release later remove the extra parameter
>>>if the check never triggered for anyone.
>>>
>> 
>> I add one assertion to the original code, like below.
>> 
>> diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
>> index 86c71be..3d9386a 100644
>> --- a/xen/arch/x86/hvm/mtrr.c
>> +++ b/xen/arch/x86/hvm/mtrr.c
>> @@ -784,6 +784,8 @@ int epte_get_entry_emt(struct domain *d, unsigned long 
>> gfn, 
>>  
>>  if ( direct_mmio )
>>  {
>> +ASSERT(direct_mmio == is_iomem_page(mfn)); 
>> +
>>  if ( (mfn_x(mfn) ^ d->arch.hvm_domain.vmx.apic_access_mfn) >> order 
>> )
>>  return MTRR_TYPE_UNCACHABLE;
>>  if ( order )
>> 
>> But when I try to create a hvm domain, it failed. logs are below.
>
>Considering the context of the change above, I'm not surprised:
>You've very likely hit the APIC access MFN.
>

Jan is right. When the assertion fails, the value of gfn is 0xfee00.

Do you mean that is_iomem_page() is equal to direct_mmio except some
corner cases such as APIC access MFN and INVALID_MFN( any others? ) ?

Thanks
Chao

>Jan

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

Re: [Xen-devel] [PATCH v2 07/10] xen: credit2: always mark a tickled pCPU as... tickled!

[Dario Faggioli]

On Thu, 2017-02-09 at 14:59 +0100, Dario Faggioli wrote:
> In fact, whether or not a pCPU has been tickled, and is
> therefore about to re-schedule, is something we look at
> and base decisions on in various places.
> 
> So, let's make sure that we do that basing on accurate
> information.
> 
> While there, also tweak a little bit smt_idle_mask_clear()
> (used for implementing SMT support), so that it only alter
> the relevant cpumask when there is the actual need for this.
> (This is only for reduced overhead, behavior remains the
> same).
> 
So, while working on other things with this series applied, I noticed
some strange behavior, for which it turned out this patch is
responsible.

More specifically...

> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index addee7b..bfb4891 100644
> @@ -1289,9 +1300,8 @@ runq_tickle(const struct scheduler *ops, struct
> csched2_vcpu *new, s_time_t now)
>  sizeof(d),
>  (unsigned char *));
>  }
> -__cpumask_set_cpu(ipid, >tickled);
> -smt_idle_mask_clear(ipid, >smt_idle);
> -cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
> +
> +tickle_cpu(cpu, rqd);
>  
... this, quite obviously, wants to be:

  tickle_cpu(ipid, rqd);

I'll fix this in v2.

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

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

Re: [Xen-devel] [DOC v4] Xen transport for 9pfs

[Stefano Stabellini]

On Wed, 8 Feb 2017, Konrad Rzeszutek Wilk wrote:
> > ## Ring Setup
> > 
> > The shared page has the following layout:
> > 
> > typedef uint32_t XEN_9PFS_RING_IDX;
> > 
> > struct xen_9pfs_intf {
> > XEN_9PFS_RING_IDX in_cons, in_prod;
> > uint8_t pad[56];
> > XEN_9PFS_RING_IDX out_cons, out_prod;
> > 
> > uint32_t ring_order;
> > /* this is an array of (1 << ring_order) elements */
> > grant_ref_t ref[1];
> > };
> > 
> > /* not actually C compliant (ring_order changes from ring to ring) */
> > struct ring_data {
> > char in[((1 << ring_order) << PAGE_SHIFT) / 2];
> > char out[((1 << ring_order) << PAGE_SHIFT) / 2];
> > };
> > 
> 
> This is the same comment about the the PV Calls structure.
> 
> Would it make sense to add the 'in_events' and 'out_events'
> as a notification mechanism?

As I wrote in the case of PV Calls, given that it's just an optimization
and increases complexity, what if we add some padding right after

  XEN_9PFS_RING_IDX out_cons, out_prod;

so that if we want to add it in the future, we can just place there,
instead of the first 4 bytes of the padding array?

struct xen_9pfs_intf {
XEN_9PFS_RING_IDX in_cons, in_prod;
uint8_t pad[56];
XEN_9PFS_RING_IDX out_cons, out_prod;
uint8_t pad[56];

uint32_t ring_order;
/* this is an array of (1 << ring_order) elements */
grant_ref_t ref[1];
};


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

Re: [Xen-devel] qemu-upstream triggering OOM killer

[Stefano Stabellini]

CC'ing Anthony

On Thu, 9 Feb 2017, Jan Beulich wrote:
> Stefano,
> 
> the recent qemuu update results in the produced binary triggering the
> OOM killer on the first system I tried the updated code on. Is there
> anything known in this area? Are there any hints as to finding out
> what is going wrong?

Hi Jan,

Do you mean QEMU upstream (from qemu.org) or qemu-xen/staging (that
hasn't changed much in the last couple of months)? Do you know if it's
something Xen specific?

In terms of new Xen specific changes in QEMU upstream,
3a6c9172ac5951e6dac2b3f6 has the potential for changing memory
allocations, but shouldn't cause an OOM. If it's easy to reproduce, I
would bisect it.

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

Re: [Xen-devel] [early RFC] ARM PCI Passthrough design document

[Stefano Stabellini]

On Fri, 3 Feb 2017, Edgar E. Iglesias wrote:
> On Thu, Feb 02, 2017 at 03:12:52PM -0800, Stefano Stabellini wrote:
> > On Thu, 2 Feb 2017, Edgar E. Iglesias wrote:
> > > On Wed, Feb 01, 2017 at 07:04:43PM +, Julien Grall wrote:
> > > > Hi Edgar,
> > > > 
> > > > On 31/01/2017 19:06, Edgar E. Iglesias wrote:
> > > > >On Tue, Jan 31, 2017 at 05:09:53PM +, Julien Grall wrote:
> > > > >>On 31/01/17 16:53, Edgar E. Iglesias wrote:
> > > > >>>On Wed, Jan 25, 2017 at 06:53:20PM +, Julien Grall wrote:
> > > > On 24/01/17 20:07, Stefano Stabellini wrote:
> > > > >On Tue, 24 Jan 2017, Julien Grall wrote:
> > > > For generic host bridge, the initialization is inexistent. However 
> > > > some host
> > > > bridge (e.g xgene, xilinx) may require some specific setup and also
> > > > configuring clocks. Given that Xen only requires to access the 
> > > > configuration
> > > > space, I was thinking to let DOM0 initialization the host bridge. 
> > > > This would
> > > > avoid to import a lot of code in Xen, however this means that we 
> > > > need to
> > > > know when the host bridge has been initialized before accessing the
> > > > configuration space.
> > > > >>>
> > > > >>>
> > > > >>>Yes, that's correct.
> > > > >>>There's a sequence on the ZynqMP that involves assiging Gigabit 
> > > > >>>Transceivers
> > > > >>>to PCI (GTs are shared among PCIe, USB, SATA and the Display Port),
> > > > >>>enabling clocks and configuring a few registers to enable ECAM and 
> > > > >>>MSI.
> > > > >>>
> > > > >>>I'm not sure if this could be done prior to starting Xen. Perhaps.
> > > > >>>If so, bootloaders would have to know a head of time what devices
> > > > >>>the GTs are supposed to be configured for.
> > > > >>
> > > > >>I've got further questions regarding the Gigabit Transceivers. You 
> > > > >>mention
> > > > >>they are shared, do you mean that multiple devices can use a GT at 
> > > > >>the same
> > > > >>time? Or the software is deciding at startup which device will use a 
> > > > >>given
> > > > >>GT? If so, how does the software make this decision?
> > > > >
> > > > >Software will decide at startup. AFAIK, the allocation is normally done
> > > > >once but I guess that in theory you could design boards that could 
> > > > >switch
> > > > >at runtime. I'm not sure we need to worry about that use-case though.
> > > > >
> > > > >The details can be found here:
> > > > >https://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
> > > > >
> > > > >I suggest looking at pages 672 and 733.
> > > > 
> > > > Thank you for the documentation. I am trying to understand if we could 
> > > > move
> > > > initialization in Xen as suggested by Stefano. I looked at the driver in
> > > > Linux and the code looks simple not many dependencies. However, I was 
> > > > not
> > > > able to find where the Gigabit Transceivers are configured. Do you have 
> > > > any
> > > > link to the code for that?
> > > 
> > > Hi Julien,
> > > 
> > > I suspect that this setup has previously been done by the initial 
> > > bootloader
> > > auto-generated from design configuration tools.
> > > 
> > > Now, this is moving into Linux.
> > > There's a specific driver that does that but AFAICS, it has not been 
> > > upstreamed yet.
> > > You can see it here:
> > > https://github.com/Xilinx/linux-xlnx/blob/master/drivers/phy/phy-zynqmp.c
> > > 
> > > DTS nodes that need a PHY can then just refer to it, here's an example 
> > > from SATA:
> > >  {
> > > phy-names = "sata-phy";
> > > phys = < PHY_TYPE_SATA 1 3 15000>;
> > > };
> > > 
> > > I'll see if I can find working examples for PCIe on the ZCU102. Then I'll 
> > > share
> > > DTS, Kernel etc.
> > > 
> > > If you are looking for a platform to get started, an option could be if I 
> > > get you a build of
> > > our QEMU that includes models for the PCIe controller, MSI and SMMU 
> > > connections.
> > > These models are friendly wrt. PHY configs and initialization sequences, 
> > > it will
> > > accept pretty much any sequence and still work. This would allow you to 
> > > focus on
> > > architectural issues rather than exact details of init sequences (which 
> > > we can
> > > deal with later).
> > > 
> > > 
> > > 
> > > > 
> > > > This would also mean that the MSI interrupt controller will be moved in 
> > > > Xen.
> > > > Which I think is a more sensible design (see more below).
> > > > 
> > > > >>
> > > > - For all other host bridges => I don't know if there are host 
> > > >  bridges
> > > > falling under this category. I also don't have any idea how to 
> > > > handle this.
> > > > 
> > > > >
> > > > >Otherwise, if Dom0 is the only one to drive the physical host 
> > > > >bridge,
> > > > >and Xen is the one to provide the emulated host bridge, how are 
> > > > >DomU PCI
> > > > >config reads and writes supposed to work in details?
> > > > 
> > > > 

Re: [Xen-devel] [DOC v8] PV Calls protocol design

[Stefano Stabellini]

On Tue, 7 Feb 2017, Konrad Rzeszutek Wilk wrote:
> .snip..
> >  Frontend XenBus Nodes
> > 
> > version
> >  Values: 
> > 
> >  Protocol version, chosen among the ones supported by the backend
> >  (see **versions** under [Backend XenBus Nodes]). Currently the
> >  value must be "1".
> > 
> > port
> >  Values: 
> > 
> >  The identifier of the Xen event channel used to signal activity
> >  in the command ring.
> > 
> > ring-ref
> >  Values: 
> > 
> >  The Xen grant reference granting permission for the backend to map
> >  the sole page in a single page sized command ring.
> > 
> >  Backend XenBus Nodes
> > 
> > versions
> >  Values: 
> > 
> >  List of comma separated protocol versions supported by the backend.
> >  For example "1,2,3". Currently the value is just "1", as there is
> >  only one version.
> > 
> > max-page-order
> >  Values: 
> > 
> >  The maximum supported size of a memory allocation in units of
> >  log2n(machine pages), e.g. 0 == 1 page,  1 = 2 pages, 2 == 4 pages,
> >  etc.
> 
> .. for the **data rings** (not to be confused with the command ring).
> 
> > 
> > function-calls
> >  Values: 
> > 
> >  Value "0" means that no calls are supported.
> >  Value "1" means that socket, connect, release, bind, listen, accept
> >  and poll are supported.
> > 
> ..snip..
> > ### Commands Ring
> > 
> > The shared ring is used by the frontend to forward POSIX function calls
> > to the backend. We shall refer to this ring as **commands ring** to
> > distinguish it from other rings which can be created later in the
> > lifecycle of the protocol (see [Indexes Page and Data ring]). The grant
> > reference for shared page for this ring is shared on xenstore (see
> > [Frontend XenBus Nodes]). The ring format is defined using the familiar
> > `DEFINE_RING_TYPES` macro (`xen/include/public/io/ring.h`).  Frontend
> > requests are allocated on the ring using the `RING_GET_REQUEST` macro.
> > The list of commands below is in calling order.
> > 
> > The format is defined as follows:
> > 
> > #define PVCALLS_SOCKET 0
> > #define PVCALLS_CONNECT1
> > #define PVCALLS_RELEASE2
> > #define PVCALLS_BIND   3
> > #define PVCALLS_LISTEN 4
> > #define PVCALLS_ACCEPT 5
> > #define PVCALLS_POLL   6
> > 
> > struct xen_pvcalls_request {
> > uint32_t req_id; /* private to guest, echoed in response */
> > uint32_t cmd;/* command to execute */
> > union {
> > struct xen_pvcalls_socket {
> > uint64_t id;
> > uint32_t domain;
> > uint32_t type;
> > uint32_t protocol;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[4];
> 
> Could that be shifted to the right?

Tabs vs Spaces, sigh. I fixed it.


> > #endif
> > } socket;
> > struct xen_pvcalls_connect {
> > uint64_t id;
> > uint8_t addr[28];
> > uint32_t len;
> > uint32_t flags;
> > grant_ref_t ref;
> > uint32_t evtchn;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[4];
> > #endif
> > } connect;
> > struct xen_pvcalls_release {
> > uint64_t id;
> > uint8_t reuse;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[7];
> 
> Could that be shifted to the right?

yep


> > #endif
> > } release;
> > struct xen_pvcalls_bind {
> > uint64_t id;
> > uint8_t addr[28];
> > uint32_t len;
> > } bind;
> > struct xen_pvcalls_listen {
> > uint64_t id;
> > uint32_t backlog;
> > #ifdef CONFIG_X86_32
> > uint8_t pad[4];
> 
> Could that be shifted to the right?

yep


> > #endif
> > } listen;
> > struct xen_pvcalls_accept {
> > uint64_t id;
> > uint64_t id_new;
> > grant_ref_t ref;
> > uint32_t evtchn;
> > } accept;
> > struct xen_pvcalls_poll {
> > uint64_t id;
> > } poll;
> > /* dummy member to force sizeof(struct 
> > xen_pvcalls_request) to match across archs */
> >

[Xen-devel] Xen on ARM IRQ latency and scheduler overhead

[Stefano Stabellini]

Hi all,

I have run some IRQ latency measurements on Xen on ARM on a Xilinx
ZynqMP board (four Cortex A53 cores, GICv2).

Dom0 has 1 vcpu pinned to cpu0, DomU has 1 vcpu pinned to cpu2.
Dom0 is Ubuntu. DomU is an ad-hoc baremetal app to measure interrupt
latency: https://github.com/edgarigl/tbm

I modified the app to use the phys_timer instead of the virt_timer.  You
can build it with:

make CFG=configs/xen-guest-irq-latency.cfg 

I modified Xen to export the phys_timer to guests, see the very hacky
patch attached. This way, the phys_timer interrupt should behave like
any conventional device interrupts assigned to a guest.

These are the results, in nanosec:

AVG MIN MAX WARM MAX

NODEBUG no WFI  1890180031702070
NODEBUG WFI 4850481070304980
NODEBUG no WFI credit2  2217209034202650
NODEBUG WFI credit2 8080789010320   8300

DEBUG no WFI2252208033202650
DEBUG WFI   6500614085208130
DEBUG WFI, credit2  8050787010680   8450

DEBUG means Xen DEBUG build.
WARM MAX is the maximum latency, taking out the first few interrupts to
warm the caches.
WFI is the ARM and ARM64 sleeping instruction, trapped and emulated by
Xen by calling vcpu_block.

As you can see, depending on whether the guest issues a WFI or not while
waiting for interrupts, the results change significantly. Interestingly,
credit2 does worse than credit1 in this area.

Trying to figure out where those 3000-4000ns of difference between the
WFI and non-WFI cases come from, I wrote a patch to zero the latency
introduced by xen/arch/arm/domain.c:schedule_tail. That saves about
1000ns. There are no other arch specific context switch functions worth
optimizing.

We are down to 2000-3000ns. Then, I started investigating the scheduler.
I measured how long it takes to run "vcpu_unblock": 1050ns, which is
significant. I don't know what is causing the remaining 1000-2000ns, but
I bet on another scheduler function. Do you have any suggestions on
which one?


Assuming that the problem is indeed the scheduler, one workaround that
we could introduce today would be to avoid calling vcpu_unblock on guest
WFI and call vcpu_yield instead. This change makes things significantly
better:

 AVG MIN MAX WARM MAX
DEBUG WFI (yield, no block)  2900219051305130
DEBUG WFI (yield, no block) credit2  3514228061805430

Is that a reasonable change to make? Would it cause significantly more
power consumption in Xen (because xen/arch/arm/domain.c:idle_loop might
not be called anymore)?


If we wanted to zero the difference between the WFI and non-WFI cases,
would we need a new scheduler? A simple "noop scheduler" that statically
assigns vcpus to pcpus, one by one, until they run out, then return
error? Or do we need more extensive modifications to
xen/common/schedule.c? Any other ideas?


Thanks,

Stefanodiff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7e43691..f5ff69b 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -663,6 +663,7 @@ void arch_domain_destroy(struct domain *d)
 /* IOMMU page table is shared with P2M, always call
  * iommu_domain_destroy() before p2m_teardown().
  */
+WRITE_SYSREG32(0, CNTP_CTL_EL0);
 iommu_domain_destroy(d);
 p2m_teardown(d);
 domain_vgic_free(d);
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index a5348f2..5c8b621 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -47,7 +47,7 @@ static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 static void gic_update_one_lr(struct vcpu *v, int i);
 
-static const struct gic_hw_operations *gic_hw_ops;
+const struct gic_hw_operations *gic_hw_ops;
 
 void register_gic_ops(const struct gic_hw_operations *ops)
 {
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index dd62ba6..9a4e50d 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -184,6 +184,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
 }
 
 /* Dispatch an interrupt */
+extern const struct gic_hw_operations *gic_hw_ops;
 void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
 {
 struct irq_desc *desc = irq_to_desc(irq);
@@ -202,6 +203,12 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, 
int is_fiq)
 irq_enter();
 
 spin_lock(>lock);
+
+if (irq == 30) {
+set_bit(_IRQ_GUEST, >status);
+desc->handler = gic_hw_ops->gic_guest_irq_type;
+}
+
 desc->handler->ack(desc);
 
 if ( !desc->action )
@@ -224,7 +231,23 @@ 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);
+if (irq != 30)
+vgic_vcpu_inject_spi(info->d, info->virq);
+else {
+struct domain *d;
+  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-buildfail REGR. vs. 105279
 build-amd64   5 xen-buildfail REGR. vs. 105279
 build-amd64-xsm   5 xen-buildfail REGR. vs. 105279
 build-i3865 xen-buildfail REGR. vs. 105279
 build-armhf   5 xen-buildfail REGR. vs. 105279
 build-armhf-xsm   5 xen-buildfail REGR. vs. 105279

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

Re: [Xen-devel] [RFC XEN PATCH 15/16] tools/libxl: handle return code of libxl__qmp_initializations()

[Haozhong Zhang]

On 02/09/17 10:13 +, Wei Liu wrote:

On Thu, Feb 09, 2017 at 10:47:01AM +0800, Haozhong Zhang wrote:

On 02/08/17 10:31 +, Wei Liu wrote:
> On Wed, Feb 08, 2017 at 02:07:26PM +0800, Haozhong Zhang wrote:
> > On 01/27/17 17:11 -0500, Konrad Rzeszutek Wilk wrote:
> > > On Mon, Oct 10, 2016 at 08:32:34AM +0800, Haozhong Zhang wrote:
> > > > If any error code is returned when creating a domain, stop the domain
> > > > creation.
> > >
> > > This looks like it is a bug-fix that can be spun off from this
> > > patchset?
> > >
> >
> > Yes, if everyone considers it's really a bug and the fix does not
> > cause compatibility problem (e.g. xl w/o this patch does not abort the
> > domain creation if it fails to connect to QEMU VNC port).
> >
>
> I'm two minded here. If the failure to connect is caused by some
> temporary glitches in QEMU and we're sure it will eventually succeed,
> there is no need to abort domain creation. If failure to connect is due
> to permanent glitches, we should abort.
>

Sorry, I should say "*query* QEMU VNC port" instead of *connect*.

libxl__qmp_initializations() currently does following tasks.
1/ Create a QMP socket.

  I think all failures in 1/ should be considered as permanent. It
  does not only fail the following tasks, but also fails the device
  hotplug which needs to cooperate with QEMU.

2/ If 1/ succeeds, query qmp about parameters of serial port and fill
  them in xenstore.
3/ If 1/ and 2/ succeed, set and query qmp about parameters (password,
  address, port) of VNC and fill them in xenstore.

  If we assume Xen always send the correct QMP commands and
  parameters, the QMP failures in 2/ and 3/ will be caused by QMP
  socket errors (see qmp_next()), which are hard to tell whether they
  are permanent or temporal. However, if the missing of serial port
  or VNC is considered as not affecting the execution of guest
  domain, we may ignore failures here.

> OOI how did you discover this issue? That could be the key to understand
> the issue here.

The next patch adds code in libxl__qmp_initialization() to query qmp
about vNVDIMM parameters (e.g. the base gpfn which is calculated by
QEMU) and return error code if it fails. While I was developing that
patch, I found xl didn't stop even if bugs in my QEMU patches failed
the code in my Xen patch.



Right, this should definitely be fatal.


Maybe we could let libxl__qmp_initializations() report whether a
failure can be tolerant. For non-tolerant failures (e.g. those in 1/),
xl should stop. For tolerant failures (e.g. those in 2/ and 3/), xl
can continue, but it needs to warn those failures.



Yes, we can do that. It's an internal function, we can change things as
we see fit.

I would suggest you only make vNVDIMM failure fatal as a start.



I'll send a patch out of this series to implement above w/o NVDIMM
stuffs.

Thanks,
Haozhong

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

[Xen-devel] [xen-unstable test] 105669: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 105629

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 105629
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 105629
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 105629
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 105629
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 105629
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 105629
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 105629
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 105629
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 105629

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 build-arm64   5 xen-buildfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   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

version targeted for testing:
 xen  991033fad2cc23c45415fbcd0ab6405250e6b35c
baseline version:
 xen  63e1d01b8fd948b3e0fa3beea494e407668aa43b

Last test of basis   105629  2017-02-08 06:54:04 Z1 days
Failing since105640  2017-02-08 14:19:37 Z1 days4 attempts
Testing same since   105669  2017-02-09 14:49:05 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Baptiste Daroussin 
  Fatih Acar 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  16 guest-saverestore.2   fail REGR. vs. 59254
 test-amd64-amd64-xl  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-xsm   17 guest-localmigrate/x10fail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-armhf-armhf-libvirt-raw  6 xen-bootfail baseline untested
 test-armhf-armhf-xl-vhd   6 xen-bootfail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linux99378fd26803328cbab64ae60fa98e1394d07a6d
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  582 days
Failing since 59348  2015-07-10 04:24:05 Z  581 days  262 attempts
Testing same since   105672  2017-02-09 21:19:17 Z0 days1 attempts


7569 people touched revisions under test,
not listing them all

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

[Xen-devel] [qemu-upstream-unstable test] 105675: regressions - FAIL

[osstest service owner]

flight 105675 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/105675/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  18 leak-check/check fail REGR. vs. 104067
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 
104067

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104067
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104067
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104067
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104067

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   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-amd64-i386-libvirt-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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu728e90b41d46c1c1c210ac496204efd51936db75
baseline version:
 qemuu5cd2e1739763915e6b4c247eef71f948dc808bd5

Last test of basis   104067  2017-01-06 23:12:11 Z   34 days
Testing same since   105675  2017-02-09 23:12:05 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Li Qiang 
  Stefano Stabellini 

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

[Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

This is the ABI for the two halves of a para-virtualized
display driver.

This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
  o multiple dynamically allocated/destroyed framebuffers
  o buffers of arbitrary sizes
  o better configuration options including multiple display support

Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS

Future extensions to the existing protocol may include:
  o allow display/connector cloning
  o allow allocating objects other than display buffers
  o add planes/overlays support
  o support scaling
  o support rotation

==
Rationale for introducing this protocol instead of
using the existing fbif:
==

1. In/out event sizes
  o fbif - 40 octets
  o displif - 40 octets
This is only the initial version of the displif protocol
which means that there could be requests which will not fit
(WRT introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif.

2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
xendispl_resp) which is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)

3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.

Changes since v2:
 * updated XenStore configuration template/pattern
 * added "Recovery flow" to state diagram description
 * renamed gref_directory_start to gref_directory
 * added missing "versions" and "version" string constants

Changes since v1:
 * fixed xendispl_event_page padding size
 * added versioning support
 * explicitly define value types for XenStore fields
 * text decoration re-work
 * added offsets to ASCII box notation

Changes since initial:
 * DRM changed to DISPL, protocol made generic
 * major re-work addressing issues raised for sndif

Signed-off-by: Oleksandr Grytsov 
Signed-off-by: Oleksandr Andrushchenko 
---
 xen/include/public/io/displif.h | 778 
 1 file changed, 778 insertions(+)
 create mode 100644 xen/include/public/io/displif.h

diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
new file mode 100644
index ..849f27fe5f1d
--- /dev/null
+++ b/xen/include/public/io/displif.h
@@ -0,0 +1,778 @@
+/**
+ * displif.h
+ *
+ * Unified display device I/O interface for Xen guest OSes.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright (C) 2016-2017 EPAM Systems Inc.
+ *
+ * Authors: Oleksandr Andrushchenko 
+ *  Oleksandr Grytsov 
+ */
+
+#ifndef __XEN_PUBLIC_IO_DISPLIF_H__
+#define __XEN_PUBLIC_IO_DISPLIF_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/*
+ **
+ *  Main features provided by the protocol
+ 

[Xen-devel] [PATCH v3] displif: add ABI for para-virtual display

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

This is the ABI for the two halves of a para-virtualized
display driver.

This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
  o multiple dynamically allocated/destroyed framebuffers
  o buffers of arbitrary sizes
  o better configuration options including multiple display support

Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS

Future extensions to the existing protocol may include:
  o allow display/connector cloning
  o allow allocating objects other than display buffers
  o add planes/overlays support
  o support scaling
  o support rotation

Thank you,
Oleksandr Andrushchenko
Oleksandr Grytsov

Oleksandr Andrushchenko (1):
  displif: add ABI for para-virtual display

 xen/include/public/io/displif.h | 778 
 1 file changed, 778 insertions(+)
 create mode 100644 xen/include/public/io/displif.h

-- 
2.7.4


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

[Xen-devel] [xen-4.6-testing test] 105673: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104585

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 105664 pass in 105673
 test-amd64-amd64-pair20 guest-start/debian fail pass in 105664

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds   15 guest-start/debian.repeat fail blocked in 104585
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 104585
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 104585
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 104585
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 104585
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 104585
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 104585
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 104585

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-4   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   62 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 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 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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  576f319a804bce8c9a7fb70a042f873f5eaf0151
baseline version:
 xen  09f521a077024d5955d766eef7a040d2af928ec2

Last test of basis   104585  2017-01-22 08:19:51 Z   18 days
Testing same since   105664  2017-02-09 10:14:26 Z0 days2 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Joao Martins 

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

Re: [Xen-devel] [PATCH v6 04/24] x86: refactor psr: implement CPU init and free flow.

[Yi Sun]

On 17-02-08 14:03:15, Konrad Rzeszutek Wilk wrote:
> > > +static void cpu_fini_work(unsigned int cpu)
> > > +{
> > > +unsigned int socket = cpu_to_socket(cpu);
> > > +
> > > +if ( !socket_cpumask[socket] || 
> > > cpumask_empty(socket_cpumask[socket]) )
> > 
> > I fear I don't understand this.
> > 
> > Looking at 65a399ac it says:
> > 
> > +.notifier_call = cpu_callback,
> > +/*
> > + * Ensure socket_cpumask is still valid in CPU_DEAD notification
> > + * (E.g. our CPU_DEAD notification should be called ahead of
> > + * cpu_smpboot_free).
> > 
> > Which means that socket_cpumask[socket] should have an value.
> > 
> > In fact cpumask_any(socket_cpumask[socket]) will return true at this
> > point.
> > 
> > Which means that code above gets called if this psr_cpu_fini is called
> > _after_ cpu_smpboot_free (b/c socket_cpumask[socket] will be NULL), see
> > cpu_smpboot_free.
> > 
> > But with .priority being -1 that won't happen.
> > 
> > But lets ignore that, lets say it does get called _after_
> > cpu_smpboot_free. In which case the first part of the 'if' condition
> > is true and we end up doing: cpumask_empty(NULL) which will result
> > in an page fault.
> > 
> > I think this is a bug.
> 
> I missed the fact that we call this function on CPU_UP_CANCELED
> _and_ CPU_DEAD and that remove_siblinginfo is called before CPU_DEAD.
> 
> So say the socket is being onlined and we are the first CPU on
> that (CPU=2).
> 
> 
> 1) CPU_UP_PREPARE notifier calls psr_cpu_prepare which allocates
>'feat_l3_cat'.
> 
> 2). Some other notifies dies and we end up calling CPU_UP_CANCELED.
>psr_cpu_fini -> cpu_fini_work:
> 
>Since __cpu_up has not been called that means
>socket_cpumask[socket] == NULL
> 
>and we enter free_feature.
> 
>It does 'if !(socket_info + socket)' effectively. And that is false
>as init_psr was the one initializing that array which means the
>pointer (info aka socket_info + socket) certainly is not NULL.
> 
>Anyhow this means free_feature tries to walk the list - but 'info'
>is full of zeros.
> 
>Which means list_for_each_entry_safe is going to blow when trying
>to set 'n' (as pos is zero aka NULL).
> 
>Perhaps you want an INIT_LIST_HEAD in 'init_psr' so that free_feature
>can be idempotent?
> 
>Or perhaps you need '&&' in the if conditional (and naturally
>remove the !)?
> 
>I wonder what other CPU notifiers are guilty of this..
> 
You are right. I made a mistake here. Thanks a lot for finding out the issue!

In previous version, I called INIT_LIST_HEAD in init_psr. But I moved it into
cpu_init_work to place it together with spin_lock_init per review comments.
This causes this mis-match issue. I think your suggestion is good to change
check criteria as below.

if ( socket_cpumask[socket] && cpumask_empty(socket_cpumask[socket]) )

Then, free_feature will only be executed when CPU_STARTING has been done.

> 
> Lets try another example:
> 
> 1) CPU_UP_PREPARE notifier calls psr_cpu_prepare which allocates
>'feat_l3_cat'.
> 
> 2) All notifiers were OK, the __cpu_up has been called. The
>socket_cpumask[socket] = 
> 
> 3) All notifiers are called with CPU_ONLINE.
>All good.
> 
> 
> ..some time later ..
> 
> 4). CPU is brought down. Notifiers for CPU_DOWN_PREPARE are called
>[psr is not part of it]
> 
> 5) CPU notifiers CPU_DEAD are called. They all have to return
> NOTIFY_DONE otherwise we hit 'BUG_ON'
> 
>We call psr_cpu_fini -> cpu_fini_work
> 
>socket_cpumask[socket] has some data, so the first conditional
>is false:
> 
> ( !socket_cpumask[socket] ||
> 
>the second:
> 
> cpumask_empty(socket_cpumask[socket]) )
> 
>is true as take_cpu_down -> __cpu_disable -> remove_siblinginfo
> 
>was called before us.(and this is the first CPU in the socket).
> 
>And we call free_feature.
>which is correct and we free our data.
> 
>And the 'cpumask_empty' guards us so that we only call this
>on the very last CPU.
> 
> 
>   And we would still call this if the conditional was:
> 
>   if ( socket_cpumask[socket] && cpumask_empty(socket_cpumask[socket]))
> 
>   I think?
> 
> Feel free to poke holes at my analysis - I am sure I missed some edge
> case.

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

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[George Dunlap]

On 09/02/17 10:35, Wei Liu wrote:
> On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
>> On 08/02/17 16:11, Dario Faggioli wrote:
>>> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
 Callers to libxl_cpupool_create() can either request a specific pool
 id, or request that Xen do it for them.  But at the moment, the
 "automatic" selection is indicated by using a magic value, 0.  This
 is
 undesirable both because it doesn't obviously have meaning, but also
 because '0' is a valid cpupool (albeit one which at the moment can't
 be changed).

 Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
 instead.  Still accept '0' as meaning "ANY" for backwards
 compatibility.

 Signed-off-by: George Dunlap 

>>> Reviewed-by: Dario Faggioli 
>>>
>>> With one remark.
>>>
 diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
 --- a/tools/libxl/libxl.h
 +++ b/tools/libxl/libxl.h
 @@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx,
 uint32_t domid, char* uuid,
  int libxl_tmem_freeable(libxl_ctx *ctx);
  
  int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
 +
 +/* 
 + * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
 + * free poolid for you.
 + */
 +#define LIBXL_CPUPOOL_POOLID_ANY 0x

>>> Do we want this to be here, or in libxl_types.idl.
>>>
>>> Asking because, AFAICT, it's the only one LIBXL_FOO_BAR defined like
>>> this. I appreciate that there's few point in making this an enum, as it
>>> is only one value, and will most likely remain so, but still, I thought
>>> I'd at least bring this up.
>>>
>>> FWIW, my Reviewed-by stands both if it is kept as is, and if it is
>>> moved to IDL.
>>
>> Well there's things like:
>>
>> #define LIBXL_PCI_FUNC_ALL (~0U)
>>
>> #define LIBXL_TIMER_MODE_DEFAULT -1
>> #define LIBXL_MEMKB_DEFAULT ~0ULL
>>
>> #define LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT (2048 * 1024)
>>
>> #define LIBXL_MS_VM_GENID_LEN 16
>>
>> #define LIBXL_SUSPEND_DEBUG 1
>> #define LIBXL_SUSPEND_LIVE 2
>>
>> Many of which seem similar in some ways.  Enums I think are meant to be
>> exhaustive (as in, contain all possible options), not be special cases.
>>
>> But I'm happy to defer to the tools maintainers.
>>
> 
> I don't really care if it is an enum or a macro.
> 
> There is an issue that is  more subtle than where it lives or what form
> it is in.
> 
> You need to modify all the poolid fields in various structure to make it
> as default.  Otherwise the whole json infrastructure would still use 0
> as the default value.

Hmm, at the moment there are only two structs that include poolid:
cpupoolinfo, which is OUT-only (so the field should always be
initialized) and domain_create_info, for which 0 is a much better
default logically than "ANY".

> 
> And maybe a LIBXL_HAVE macro is needed, too.

I thought about that, but figured people could just do #ifdef
LIBXL_CPUPOOL_POOLID_ANY.  It seemed a bit strange to define a whole new
macro just to see if another macro existed.

Thoughts?

 -George


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

Re: [Xen-devel] [PATCH 2/2] tools/libxl: Introduce LIBXL_CPUPOOL_POOLID_ANY

[Wei Liu]

On Thu, Feb 09, 2017 at 11:17:46AM +, George Dunlap wrote:
> On 09/02/17 10:35, Wei Liu wrote:
> > On Wed, Feb 08, 2017 at 04:17:58PM +, George Dunlap wrote:
> >> On 08/02/17 16:11, Dario Faggioli wrote:
> >>> On Wed, 2017-02-08 at 14:51 +, George Dunlap wrote:
>  Callers to libxl_cpupool_create() can either request a specific pool
>  id, or request that Xen do it for them.  But at the moment, the
>  "automatic" selection is indicated by using a magic value, 0.  This
>  is
>  undesirable both because it doesn't obviously have meaning, but also
>  because '0' is a valid cpupool (albeit one which at the moment can't
>  be changed).
> 
>  Introduce a constant, LIBXL_CPUPOOL_POOLID_ANY, to indicate this
>  instead.  Still accept '0' as meaning "ANY" for backwards
>  compatibility.
> 
>  Signed-off-by: George Dunlap 
> 
> >>> Reviewed-by: Dario Faggioli 
> >>>
> >>> With one remark.
> >>>
>  diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
>  --- a/tools/libxl/libxl.h
>  +++ b/tools/libxl/libxl.h
>  @@ -2086,6 +2086,12 @@ int libxl_tmem_shared_auth(libxl_ctx *ctx,
>  uint32_t domid, char* uuid,
>   int libxl_tmem_freeable(libxl_ctx *ctx);
>   
>   int libxl_get_freecpus(libxl_ctx *ctx, libxl_bitmap *cpumap);
>  +
>  +/* 
>  + * Set poolid to LIBXL_CPUOOL_POOLID_ANY to have Xen choose a
>  + * free poolid for you.
>  + */
>  +#define LIBXL_CPUPOOL_POOLID_ANY 0x
> 
> >>> Do we want this to be here, or in libxl_types.idl.
> >>>
> >>> Asking because, AFAICT, it's the only one LIBXL_FOO_BAR defined like
> >>> this. I appreciate that there's few point in making this an enum, as it
> >>> is only one value, and will most likely remain so, but still, I thought
> >>> I'd at least bring this up.
> >>>
> >>> FWIW, my Reviewed-by stands both if it is kept as is, and if it is
> >>> moved to IDL.
> >>
> >> Well there's things like:
> >>
> >> #define LIBXL_PCI_FUNC_ALL (~0U)
> >>
> >> #define LIBXL_TIMER_MODE_DEFAULT -1
> >> #define LIBXL_MEMKB_DEFAULT ~0ULL
> >>
> >> #define LIBXL_RDM_MEM_BOUNDARY_MEMKB_DEFAULT (2048 * 1024)
> >>
> >> #define LIBXL_MS_VM_GENID_LEN 16
> >>
> >> #define LIBXL_SUSPEND_DEBUG 1
> >> #define LIBXL_SUSPEND_LIVE 2
> >>
> >> Many of which seem similar in some ways.  Enums I think are meant to be
> >> exhaustive (as in, contain all possible options), not be special cases.
> >>
> >> But I'm happy to defer to the tools maintainers.
> >>
> > 
> > I don't really care if it is an enum or a macro.
> > 
> > There is an issue that is  more subtle than where it lives or what form
> > it is in.
> > 
> > You need to modify all the poolid fields in various structure to make it
> > as default.  Otherwise the whole json infrastructure would still use 0
> > as the default value.
> 
> Hmm, at the moment there are only two structs that include poolid:
> cpupoolinfo, which is OUT-only (so the field should always be
> initialized) and domain_create_info, for which 0 is a much better
> default logically than "ANY".
> 

I don't follow here. Isn't 0 already "ANY"?

> > 
> > And maybe a LIBXL_HAVE macro is needed, too.
> 
> I thought about that, but figured people could just do #ifdef
> LIBXL_CPUPOOL_POOLID_ANY.  It seemed a bit strange to define a whole new
> macro just to see if another macro existed.
> 

I want to reserve the possibility to change that into an enum in the
future.

Wei.

> Thoughts?
> 
>  -George
> 

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

[Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

[Roger Pau Monne]

The usage of the __transparent__ attribute in 991033fa introduces some issues
when compiled with clang 3.8.0:

xen/include/asm/hvm/vmx/vmx.h:605:15: error: transparent_union attribute can 
only be
  applied to a union definition; attribute ignored 
[-Werror,-Wignored-attributes]
typedef union __transparent__ ept_qual {
  ^
xen/include/xen/compiler.h:50:44: note: expanded from macro '__transparent__'
#define __transparent__ __attribute__((__transparent_union__))

This can be easily fixed by moving the attribute to the end of the definition,
but then the following error triggers:

xen/include/asm/hvm/vmx/vmx.h:607:5: error: size of field '' (16 bits) does not
  match the size of the first field in transparent union; transparent_union 
attribute ignored
  [-Werror,-Wignored-attributes]
struct {
^
xen/include/asm/hvm/vmx/vmx.h:606:19: note: size of first field is 64 bits
unsigned long raw;
  ^

Which can be fixed by introducing a new field in the nested structure that
contains the padding in order to match the size of an unsigned long.

Signed-off-by: Roger Pau Monné 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/include/asm-x86/hvm/vmx/vmx.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/hvm/vmx/vmx.h 
b/xen/include/asm-x86/hvm/vmx/vmx.h
index 5f7512b..52646b7 100644
--- a/xen/include/asm-x86/hvm/vmx/vmx.h
+++ b/xen/include/asm-x86/hvm/vmx/vmx.h
@@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
 void vmx_pi_hooks_deassign(struct domain *d);
 
 /* EPT violation qualifications definitions */
-typedef union __transparent__ ept_qual {
+typedef union ept_qual {
 unsigned long raw;
 struct {
 bool read:1, write:1, fetch:1,
 eff_read:1, eff_write:1, eff_exec:1, /* eff_user_exec */:1,
 gla_valid:1,
 gla_fault:1; /* Valid iff gla_valid. */
+unsigned long /* pad */:55;
 };
-} ept_qual_t;
+} ept_qual_t __transparent__;
 
 #define EPT_L4_PAGETABLE_SHIFT  39
 #define EPT_PAGETABLE_ENTRIES   512
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [PATCH v2 12/12] libxl: make one function static

[Ian Jackson]

Juergen Gross writes ("[PATCH v2 12/12] libxl: make one function static"):
> libxl__device_frontend_path() is used in libxl_device.c only. Make it
> static.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v2 00/12] libxl: split up libxl.c

[Ian Jackson]

Juergen Gross writes ("[PATCH v2 00/12] libxl: split up libxl.c"):
>   libxl: carve out cpupool specific functions from libxl.c
>   libxl: carve out scheduler specific functions from libxl.c
>   libxl: carve out disk specific functions from libxl.c
>   libxl: carve out console specific functions from libxl.c
>   libxl: carve out memory specific functions from libxl.c
>   libxl: move device specific functions out of libxl.c
>   libxl: carve out tmem specific functions from libxl.c
>   libxl: carve out domain specific functions from libxl.c

I have verified your assertion that these patches are just code
motion.

So for patches 4-11 inclusive:

Acked-by: Ian Jackson 

Ian.

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

Re: [Xen-devel] kernel BUG at block/bio.c:1786 -- (xen_blkif_schedule on the stack)

[Wei Liu]

CC Roger and Konrad

On Mon, Feb 06, 2017 at 12:31:20AM +0100, Håkon Alstadheim wrote:
> I get the BUG below in dom0 when trying to start a windows 10 domu (hvm,
> with some pv-drivers installed ) . Below is "xl info", then comes dmesg
> output, and finally domu config attached at end.
> 
> This domain is started very rarely, so may have been broken for some
> time. All my other domains ar linux. This message is just a data-point
> for whoever is interested, with possibly more data if anybody wants to
> ask me anything. NOT expecting quick resolution of this :-/ .
> 
> The domain boots part of the way, screen resolution gets changed and
> then it keeps spinning for ~ 5 seconds before stopping.
> 
> -
> # xl info
> host   : gentoo
> release: 4.9.8-gentoo
> version: #1 SMP Sun Feb 5 04:25:10 CET 2017
> machine: x86_64
> nr_cpus: 24
> max_cpu_id : 23
> nr_nodes   : 2
> cores_per_socket   : 6
> threads_per_core   : 2
> cpu_mhz: 2394
> hw_caps:
> b7ebfbff:77fef3ff:2c100800:0021:0001:37ab::0100
> virt_caps  : hvm hvm_directio
> total_memory   : 65376
> free_memory: 20811
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 8
> xen_extra  : .0
> xen_version: 4.8.0
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> xen_changeset  :
> xen_commandline: ssd-xen-noidle-autogen-marker
> console_timestamps=date loglvl=warn/warn guest_loglvl=warn/warn
> iommu=1,verbose,debug iommu_inclusive_mapping=1 com1=115200,8n1
> com2=115200,8n1 console=com2 dom0_max_vcpus=4 dom0_vcpus_pin=1
> dom0_mem=7G,max:7G cpufreq=xen,performance,verbose
> sched_smt_power_savings=1 apic_verbosity=debug e820-verbose=1
> core_parking=power cpuidle=0 nmi=dom0 tmem=1 tmem_compress=0 tmem_dedup=0
> cc_compiler: x86_64-pc-linux-gnu-gcc (Gentoo 5.4.0 p1.0,
> pie-0.6.5) 5.4.0
> cc_compile_by  :
> cc_compile_domain  : alstadheim.priv.no
> cc_compile_date: Thu Dec 22 01:53:23 CET 2016
> build_id   : 14ea86d056798436b26a27b06046797e
> xend_config_format : 4
> 
> --
> [339809.663061] br0: port 12(vif7.0) entered blocking state
> [339809.663063] br0: port 12(vif7.0) entered disabled state
> [339809.663123] device vif7.0 entered promiscuous mode
> [339809.664885] IPv6: ADDRCONF(NETDEV_UP): vif7.0: link is not ready
> [339809.742522] br0: port 13(vif7.0-emu) entered blocking state
> [339809.742523] br0: port 13(vif7.0-emu) entered disabled state
> [339809.742573] device vif7.0-emu entered promiscuous mode
> [339809.744386] br0: port 13(vif7.0-emu) entered blocking state
> [339809.744388] br0: port 13(vif7.0-emu) entered forwarding state
> [339864.059095] xen-blkback: backend/vbd/7/768: prepare for reconnect
> [339864.138002] xen-blkback: backend/vbd/7/768: using 1 queues, protocol
> 1 (x86_64-abi)
> [339864.241039] xen-blkback: backend/vbd/7/832: prepare for reconnect
> [339864.337997] xen-blkback: backend/vbd/7/832: using 1 queues, protocol
> 1 (x86_64-abi)
> [339875.245306] vif vif-7-0 vif7.0: Guest Rx ready
> [339875.245345] IPv6: ADDRCONF(NETDEV_CHANGE): vif7.0: link becomes ready
> [339875.245391] br0: port 12(vif7.0) entered blocking state
> [339875.245395] br0: port 12(vif7.0) entered forwarding state
> [339894.122151] [ cut here ]
> [339894.122169] kernel BUG at block/bio.c:1786!
> [339894.122173] invalid opcode:  [#1] SMP
> [339894.122176] Modules linked in: xt_physdev iptable_filter ip_tables
> x_tables nfsd auth_rpcgss oid_registry nfsv4 dns_resolver nfsv3 nfs_acl
> binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp
> crc32c_intel pcspkr serio_raw i2c_i801 i2c_smbus iTCO_wdt
> iTCO_vendor_support amdgpu drm_kms_helper syscopyarea bcache input_leds
> sysfillrect sysimgblt fb_sys_fops ttm drm uas shpchp ipmi_ssif rtc_cmos
> acpi_power_meter wmi tun snd_hda_codec_realtek snd_hda_codec_generic
> snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd
> usbip_host usbip_core pktcdvd tmem lpc_ich xen_wdt nct6775 hwmon_vid
> dm_zero dm_thin_pool dm_persistent_data dm_bio_prison dm_service_time
> dm_round_robin dm_queue_length dm_multipath dm_log_userspace cn
> virtio_pci virtio_scsi virtio_blk virtio_console virtio_balloon
> [339894.122233]  xts gf128mul aes_x86_64 cbc sha512_generic
> sha256_generic sha1_generic libiscsi scsi_transport_iscsi virtio_net
> virtio_ring virtio tg3 libphy e1000 fuse overlay nfs lockd grace sunrpc
> jfs multipath linear raid10 raid1 raid0 dm_raid raid456
> async_raid6_recov 

Re: [Xen-devel] [PATCH] x86/vmx: fix build with clang 3.8.0

[Andrew Cooper]

On 09/02/17 13:01, Jan Beulich wrote:
 On 09.02.17 at 13:49,  wrote:
>> On 09/02/17 11:33, Roger Pau Monne wrote:
>>> --- a/xen/include/asm-x86/hvm/vmx/vmx.h
>>> +++ b/xen/include/asm-x86/hvm/vmx/vmx.h
>>> @@ -602,15 +602,16 @@ void vmx_pi_hooks_assign(struct domain *d);
>>>  void vmx_pi_hooks_deassign(struct domain *d);
>>>  
>>>  /* EPT violation qualifications definitions */
>>> -typedef union __transparent__ ept_qual {
>>> +typedef union ept_qual {
>> Please can we use
>>
>> typedef __transparent__ union ept_qual {
>>
>> which clang is happy with, and will help avoid problems such as the
>> cper_mce_record issue in c/s f8be76e2fe
> Would clang also be happy with it moved near the end of that
> line
>
> typedef union ept_qual __transparent__ {
>
> Having the attribute ahead of "union" is, I think, strictly speaking
> undefined behavior, as it then may as well apply to "typedef".

No.  The result is

/local/xen.git/xen/include/asm/hvm/vmx/vmx.h:605:40: error: expected
identifier or '('
typedef union ept_qual __transparent__ {
   ^
/local/xen.git/xen/include/asm/hvm/vmx/vmx.h:614:3: error: type
specifier missing, defaults to 'int' [-Werror,-Wimplicit-int]
} ept_qual_t;
  ^~
2 errors generated.

In which case the original patch as proposed will probably do.  It turns
out the presence of ept_qual_t does cause a compiler error if
__transparent__ is missing from scope.

~Andrew

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

[Xen-devel] [PATCH v4 1/3] xen: clean up xenbus internal headers

[Juergen Gross]

The xenbus driver has an awful mixture of internally and globally
visible headers: some of the internally used only stuff is defined in
the global header include/xen/xenbus.h while some stuff defined in
internal headers is used by other drivers, too.

Clean this up by moving the externally used symbols to
include/xen/xenbus.h and the symbols used internally only to a new
header drivers/xen/xenbus/xenbus.h replacing xenbus_comms.h and
xenbus_probe.h

Signed-off-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
---
v2: update commit message, re-add lost copyright
---
 drivers/xen/xenbus/{xenbus_probe.h => xenbus.h} | 63 ++---
 drivers/xen/xenbus/xenbus_client.c  |  2 +-
 drivers/xen/xenbus/xenbus_comms.c   |  2 +-
 drivers/xen/xenbus/xenbus_comms.h   | 51 
 drivers/xen/xenbus/xenbus_dev_backend.c |  2 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c|  4 +-
 drivers/xen/xenbus/xenbus_probe.c   |  3 +-
 drivers/xen/xenbus/xenbus_probe_backend.c   |  3 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c  |  3 +-
 drivers/xen/xenbus/xenbus_xs.c  |  3 +-
 drivers/xen/xenfs/super.c   |  2 +-
 drivers/xen/xenfs/xenstored.c   |  2 +-
 include/xen/xenbus.h| 12 ++---
 13 files changed, 52 insertions(+), 100 deletions(-)
 rename drivers/xen/xenbus/{xenbus_probe.h => xenbus.h} (59%)
 delete mode 100644 drivers/xen/xenbus/xenbus_comms.h

diff --git a/drivers/xen/xenbus/xenbus_probe.h b/drivers/xen/xenbus/xenbus.h
similarity index 59%
rename from drivers/xen/xenbus/xenbus_probe.h
rename to drivers/xen/xenbus/xenbus.h
index c9ec7ca..a6b007d 100644
--- a/drivers/xen/xenbus/xenbus_probe.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -1,7 +1,5 @@
-/**
- * xenbus_probe.h
- *
- * Talks to Xen Store to figure out what devices we have.
+/*
+ * Private include for xenbus communications.
  *
  * Copyright (C) 2005 Rusty Russell, IBM Corporation
  * Copyright (C) 2005 XenSource Ltd.
@@ -31,8 +29,8 @@
  * IN THE SOFTWARE.
  */
 
-#ifndef _XENBUS_PROBE_H
-#define _XENBUS_PROBE_H
+#ifndef _XENBUS_XENBUS_H
+#define _XENBUS_XENBUS_H
 
 #define XEN_BUS_ID_SIZE20
 
@@ -54,35 +52,46 @@ enum xenstore_init {
XS_LOCAL,
 };
 
+extern enum xenstore_init xen_store_domain_type;
 extern const struct attribute_group *xenbus_dev_groups[];
 
-extern int xenbus_match(struct device *_dev, struct device_driver *_drv);
-extern int xenbus_dev_probe(struct device *_dev);
-extern int xenbus_dev_remove(struct device *_dev);
-extern int xenbus_register_driver_common(struct xenbus_driver *drv,
-struct xen_bus_type *bus,
-struct module *owner,
-const char *mod_name);
-extern int xenbus_probe_node(struct xen_bus_type *bus,
-const char *type,
-const char *nodename);
-extern int xenbus_probe_devices(struct xen_bus_type *bus);
+int xs_init(void);
+int xb_init_comms(void);
+void xb_deinit_comms(void);
+int xb_write(const void *data, unsigned int len);
+int xb_read(void *data, unsigned int len);
+int xb_data_to_read(void);
+int xb_wait_for_data_to_read(void);
 
-extern void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
+int xenbus_match(struct device *_dev, struct device_driver *_drv);
+int xenbus_dev_probe(struct device *_dev);
+int xenbus_dev_remove(struct device *_dev);
+int xenbus_register_driver_common(struct xenbus_driver *drv,
+ struct xen_bus_type *bus,
+ struct module *owner,
+ const char *mod_name);
+int xenbus_probe_node(struct xen_bus_type *bus,
+ const char *type,
+ const char *nodename);
+int xenbus_probe_devices(struct xen_bus_type *bus);
 
-extern void xenbus_dev_shutdown(struct device *_dev);
+void xenbus_dev_changed(const char *node, struct xen_bus_type *bus);
 
-extern int xenbus_dev_suspend(struct device *dev);
-extern int xenbus_dev_resume(struct device *dev);
-extern int xenbus_dev_cancel(struct device *dev);
+void xenbus_dev_shutdown(struct device *_dev);
 
-extern void xenbus_otherend_changed(struct xenbus_watch *watch,
-   const char **vec, unsigned int len,
-   int ignore_on_shutdown);
+int xenbus_dev_suspend(struct device *dev);
+int xenbus_dev_resume(struct device *dev);
+int xenbus_dev_cancel(struct device *dev);
 
-extern int xenbus_read_otherend_details(struct xenbus_device *xendev,
-   char *id_node, char *path_node);
+void xenbus_otherend_changed(struct xenbus_watch *watch,
+  

[Xen-devel] [PATCH v4 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Juergen Gross]

Handling of multiple concurrent Xenstore accesses through xenbus driver
either from the kernel or user land is rather lame today: xenbus is
capable to have one access active only at one point of time.

Rewrite xenbus to handle multiple requests concurrently by making use
of the request id of the Xenstore protocol. This requires to:

- Instead of blocking inside xb_read() when trying to read data from
  the xenstore ring buffer do so only in the main loop of
  xenbus_thread().

- Instead of doing writes to the xenstore ring buffer in the context of
  the caller just queue the request and do the write in the dedicated
  xenbus thread.

- Instead of just forwarding the request id specified by the caller of
  xenbus to xenstore use a xenbus internal unique request id. This will
  allow multiple outstanding requests.

- Modify the locking scheme in order to allow multiple requests being
  active in parallel.

- Instead of waiting for the reply of a user's xenstore request after
  writing the request to the xenstore ring buffer return directly to
  the caller and do the waiting in the read path.

Additionally signal handling was optimized by avoiding waking up the
xenbus thread or sending an event to Xenstore in case the addressed
entity is known to be running already.

As a result communication with Xenstore is sped up by a factor of up
to 5: depending on the request type (read or write) and the amount of
data transferred the gain was at least 20% (small reads) and went up to
a factor of 5 for large writes.

In the end some more rough edges of xenbus have been smoothed:

- Handling of memory shortage when reading from xenstore ring buffer in
  the xenbus driver was not optimal: it was busy looping and issuing a
  warning in each loop.

- In case of xenstore not running in dom0 but in a stubdom we end up
  with two xenbus threads running as the initialization of xenbus in
  dom0 expecting a local xenstored will be redone later when connecting
  to the xenstore domain. Up to now this was no problem as locking
  would prevent the two xenbus threads interfering with each other, but
  this was just a waste of kernel resources.

- An out of memory situation while writing to or reading from the
  xenstore ring buffer no longer will lead to a possible loss of
  synchronization with xenstore.

- The user read and write part are now interruptible by signals.

Signed-off-by: Juergen Gross 
---
V4: - correct xs_request_enter() to avoid deadlocks in case of a
  connection being used for transactions and non-transactional
  accesses in parallel
- correct xs_request_exit() to account for failed transactions
  as requested by Boris Ostrovsky

V3: simplify xs_request_enter() as requested by Boris Ostrovsky

V2: address comments of Boris Ostrovsky:
- guard xs_request_id by lock
- move state struct definitions to the place where they are being
  used
- rate limit some warnings
- use barrier() instead of cpu_relax()
- add/remove some comments
- minor changes like naming of variables
---
 drivers/xen/xenbus/xenbus.h  |  48 ++-
 drivers/xen/xenbus/xenbus_comms.c| 313 --
 drivers/xen/xenbus/xenbus_dev_frontend.c | 188 +++
 drivers/xen/xenbus/xenbus_xs.c   | 538 ++-
 4 files changed, 684 insertions(+), 403 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
index 5199527..149c5e7 100644
--- a/drivers/xen/xenbus/xenbus.h
+++ b/drivers/xen/xenbus/xenbus.h
@@ -32,6 +32,10 @@
 #ifndef _XENBUS_XENBUS_H
 #define _XENBUS_XENBUS_H
 
+#include 
+#include 
+#include 
+
 #define XEN_BUS_ID_SIZE20
 
 struct xen_bus_type {
@@ -52,16 +56,49 @@ enum xenstore_init {
XS_LOCAL,
 };
 
+struct xs_watch_event {
+   struct list_head list;
+   unsigned int len;
+   struct xenbus_watch *handle;
+   const char *path;
+   const char *token;
+   char body[];
+};
+
+enum xb_req_state {
+   xb_req_state_queued,
+   xb_req_state_wait_reply,
+   xb_req_state_got_reply,
+   xb_req_state_aborted
+};
+
+struct xb_req_data {
+   struct list_head list;
+   wait_queue_head_t wq;
+   struct xsd_sockmsg msg;
+   enum xsd_sockmsg_type type;
+   char *body;
+   const struct kvec *vec;
+   int num_vecs;
+   int err;
+   enum xb_req_state state;
+   void (*cb)(struct xb_req_data *);
+   void *par;
+};
+
 extern enum xenstore_init xen_store_domain_type;
 extern const struct attribute_group *xenbus_dev_groups[];
+extern struct mutex xs_response_mutex;
+extern struct list_head xs_reply_list;
+extern struct list_head xb_write_list;
+extern wait_queue_head_t xb_waitq;
+extern struct mutex xb_write_mutex;
 
 int xs_init(void);
 int xb_init_comms(void);
 void xb_deinit_comms(void);
-int xb_write(const void *data, unsigned int len);
-int xb_read(void *data, unsigned int len);
-int 

[Xen-devel] [PATCH v4 2/3] xen: modify xenstore watch event interface

[Juergen Gross]

Today a Xenstore watch event is delivered via a callback function
declared as:

void (*callback)(struct xenbus_watch *,
 const char **vec, unsigned int len);

As all watch events only ever come with two parameters (path and token)
changing the prototype to:

void (*callback)(struct xenbus_watch *,
 const char *path, const char *token);

is the natural thing to do.

Apply this change and adapt all users.

Cc: konrad.w...@oracle.com
Cc: roger@citrix.com
Cc: wei.l...@citrix.com
Cc: paul.durr...@citrix.com
Cc: net...@vger.kernel.org

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Boris Ostrovsky 
---
 drivers/block/xen-blkback/xenbus.c |  6 +++---
 drivers/net/xen-netback/xenbus.c   |  8 
 drivers/xen/cpu_hotplug.c  |  5 ++---
 drivers/xen/manage.c   |  6 +++---
 drivers/xen/xen-balloon.c  |  2 +-
 drivers/xen/xen-pciback/xenbus.c   |  2 +-
 drivers/xen/xenbus/xenbus.h|  6 +++---
 drivers/xen/xenbus/xenbus_client.c |  4 ++--
 drivers/xen/xenbus/xenbus_dev_frontend.c   | 21 -
 drivers/xen/xenbus/xenbus_probe.c  | 11 ---
 drivers/xen/xenbus/xenbus_probe_backend.c  |  8 
 drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++---
 drivers/xen/xenbus/xenbus_xs.c | 29 ++---
 include/xen/xenbus.h   |  6 +++---
 14 files changed, 59 insertions(+), 69 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 415e79b..8fe61b5 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -38,8 +38,8 @@ struct backend_info {
 static struct kmem_cache *xen_blkif_cachep;
 static void connect(struct backend_info *);
 static int connect_ring(struct backend_info *);
-static void backend_changed(struct xenbus_watch *, const char **,
-   unsigned int);
+static void backend_changed(struct xenbus_watch *, const char *,
+   const char *);
 static void xen_blkif_free(struct xen_blkif *blkif);
 static void xen_vbd_free(struct xen_vbd *vbd);
 
@@ -661,7 +661,7 @@ static int xen_blkbk_probe(struct xenbus_device *dev,
  * ready, connect.
  */
 static void backend_changed(struct xenbus_watch *watch,
-   const char **vec, unsigned int len)
+   const char *path, const char *token)
 {
int err;
unsigned major;
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 85b742e..bb854f9 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -734,7 +734,7 @@ static int xen_net_read_mac(struct xenbus_device *dev, u8 
mac[])
 }
 
 static void xen_net_rate_changed(struct xenbus_watch *watch,
-   const char **vec, unsigned int len)
+const char *path, const char *token)
 {
struct xenvif *vif = container_of(watch, struct xenvif, credit_watch);
struct xenbus_device *dev = xenvif_to_xenbus_device(vif);
@@ -791,7 +791,7 @@ static void xen_unregister_credit_watch(struct xenvif *vif)
 }
 
 static void xen_mcast_ctrl_changed(struct xenbus_watch *watch,
-  const char **vec, unsigned int len)
+  const char *path, const char *token)
 {
struct xenvif *vif = container_of(watch, struct xenvif,
  mcast_ctrl_watch);
@@ -866,8 +866,8 @@ static void unregister_hotplug_status_watch(struct 
backend_info *be)
 }
 
 static void hotplug_status_changed(struct xenbus_watch *watch,
-  const char **vec,
-  unsigned int vec_size)
+  const char *path,
+  const char *token)
 {
struct backend_info *be = container_of(watch,
   struct backend_info,
diff --git a/drivers/xen/cpu_hotplug.c b/drivers/xen/cpu_hotplug.c
index 5676aef..7a4daa2 100644
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -68,13 +68,12 @@ static void vcpu_hotplug(unsigned int cpu)
 }
 
 static void handle_vcpu_hotplug_event(struct xenbus_watch *watch,
-   const char **vec, unsigned int len)
+ const char *path, const char *token)
 {
unsigned int cpu;
char *cpustr;
-   const char *node = vec[XS_WATCH_PATH];
 
-   cpustr = strstr(node, "cpu/");
+   cpustr = strstr(path, "cpu/");
if (cpustr != NULL) {
sscanf(cpustr, "cpu/%u", );
   

[Xen-devel] [PATCH v4 0/3] xen: optimize xenbus performance

[Juergen Gross]

The xenbus driver used for communication with Xenstore (all kernel
accesses to Xenstore and in case of Xenstore living in another domain
all accesses of the local domain to Xenstore) is rather simple
especially regarding multiple concurrent accesses: they are just being
serialized in spite of Xenstore being capable to handle multiple
parallel accesses.

Clean up the external interface(s) of xenbus and optimize its
performance by allowing multiple concurrent accesses to Xenstore.

V4:
- patch 3: correct xs_request_enter()
- patch 3: correct xs_request_exit() as requested by Boris Ostrovsky

V3:
- patch 3: simplify coding as requested by Boris Ostrovsky

V2:
- patch 1: update commit message, re-add lost copyright
- patch 3: address comments of Boris Ostrovsky:
- guard xs_request_id by lock
- move state struct definitions to the place where they are being
  used
- rate limit some warnings
- use barrier() instead of cpu_relax()
- add/remove some comments
- minor changes like naming of variables

Juergen Gross (3):
  xen: clean up xenbus internal headers
  xen: modify xenstore watch event interface
  xen: optimize xenbus driver for multiple concurrent xenstore accesses

 drivers/block/xen-blkback/xenbus.c |   6 +-
 drivers/net/xen-netback/xenbus.c   |   8 +-
 drivers/xen/cpu_hotplug.c  |   5 +-
 drivers/xen/manage.c   |   6 +-
 drivers/xen/xen-balloon.c  |   2 +-
 drivers/xen/xen-pciback/xenbus.c   |   2 +-
 drivers/xen/xenbus/xenbus.h| 135 +++
 drivers/xen/xenbus/xenbus_client.c |   6 +-
 drivers/xen/xenbus/xenbus_comms.c  | 315 +++--
 drivers/xen/xenbus/xenbus_comms.h  |  51 ---
 drivers/xen/xenbus/xenbus_dev_backend.c|   2 +-
 drivers/xen/xenbus/xenbus_dev_frontend.c   | 213 ++-
 drivers/xen/xenbus/xenbus_probe.c  |  14 +-
 drivers/xen/xenbus/xenbus_probe.h  |  88 -
 drivers/xen/xenbus/xenbus_probe_backend.c  |  11 +-
 drivers/xen/xenbus/xenbus_probe_frontend.c |  17 +-
 drivers/xen/xenbus/xenbus_xs.c | 544 +
 drivers/xen/xenfs/super.c  |   2 +-
 drivers/xen/xenfs/xenstored.c  |   2 +-
 include/xen/xenbus.h   |  18 +-
 20 files changed, 835 insertions(+), 612 deletions(-)
 create mode 100644 drivers/xen/xenbus/xenbus.h
 delete mode 100644 drivers/xen/xenbus/xenbus_comms.h
 delete mode 100644 drivers/xen/xenbus/xenbus_probe.h

-- 
2.10.2


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

Re: [Xen-devel] [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Boris Ostrovsky]

On 02/09/2017 09:27 AM, Paul Durrant wrote:

-Original Message-
From: Paul Durrant [mailto:paul.durr...@citrix.com]
Sent: 09 February 2017 14:18
To: xen-de...@lists.xenproject.org; linux-ker...@vger.kernel.org
Cc: Paul Durrant ; Boris Ostrovsky
; Juergen Gross 
Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

Recently a new dm_op[1] hypercall was added to Xen to provide a
mechanism
for restricting device emulators (such as QEMU) to a limited set of
hypervisor operations, and being able to audit those operations in the
kernel of the domain in which they run.

This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
__HYPERVISOR_dm_op,
bouncing the callers buffers through kernel memory to allow the address
ranges to be audited (and negating the need to bounce through locked
memory in user-space).


Actually, it strikes me (now that I've posted the patch) that I should probably 
just mlock the user buffers rather than bouncing them through kernel... Anyway, 
I'd still appreciate review on other aspects of the patch.



Are you suggesting that the caller (user) mlocks the buffers?

-boris


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

[Xen-devel] [RFC PATCH v1 02/21] x86: NUMA: Refactor NUMA code

[vijay . kilari]

From: Vijaya Kumar K 

Move common generic NUMA code to xen/common/numa.c from
xen/arch/x86/numa.c. Also move generic code in header file
xen/include/asm-x86/numa.h to xen/include/xen/numa.h

This common code can be re-used later for ARM.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/x86/numa.c| 299 ---
 xen/common/Makefile|   1 +
 xen/common/numa.c  | 342 +
 xen/include/asm-x86/numa.h |  47 ---
 xen/include/xen/numa.h |  54 +++
 5 files changed, 397 insertions(+), 346 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 6f4d438..bc787e0 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -25,27 +25,12 @@ custom_param("numa", numa_setup);
 #define Dprintk(x...)
 #endif
 
-/* from proto.h */
-#define round_up(x,y) x)+(y))-1) & (~((y)-1)))
-
-struct node_data node_data[MAX_NUMNODES];
-
-/* Mapping from pdx to node id */
-int memnode_shift;
-static typeof(*memnodemap) _memnodemap[64];
-unsigned long memnodemapsize;
-u8 *memnodemap;
-
-nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {
-[0 ... NR_CPUS-1] = NUMA_NO_NODE
-};
 /*
  * Keep BIOS's CPU2node information, should not be used for memory allocaion
  */
 nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
 [0 ... MAX_LOCAL_APIC-1] = NUMA_NO_NODE
 };
-cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
@@ -57,134 +42,6 @@ int srat_disabled(void)
 return numa_off || acpi_numa < 0;
 }
 
-/*
- * Given a shift value, try to populate memnodemap[]
- * Returns :
- * 1 if OK
- * 0 if memnodmap[] too small (of shift too small)
- * -1 if node overlap or lost ram (shift too big)
- */
-static int __init populate_memnodemap(const struct node *nodes,
-  int numnodes, int shift, nodeid_t 
*nodeids)
-{
-unsigned long spdx, epdx;
-int i, res = -1;
-
-memset(memnodemap, NUMA_NO_NODE, memnodemapsize * sizeof(*memnodemap));
-for ( i = 0; i < numnodes; i++ )
-{
-spdx = paddr_to_pdx(nodes[i].start);
-epdx = paddr_to_pdx(nodes[i].end - 1) + 1;
-if ( spdx >= epdx )
-continue;
-if ( (epdx >> shift) >= memnodemapsize )
-return 0;
-do {
-if ( memnodemap[spdx >> shift] != NUMA_NO_NODE )
-return -1;
-
-if ( !nodeids )
-memnodemap[spdx >> shift] = i;
-else
-memnodemap[spdx >> shift] = nodeids[i];
-
-spdx += (1UL << shift);
-} while ( spdx < epdx );
-res = 1;
-}
-
-return res;
-}
-
-static int __init allocate_cachealigned_memnodemap(void)
-{
-unsigned long size = PFN_UP(memnodemapsize * sizeof(*memnodemap));
-unsigned long mfn = alloc_boot_pages(size, 1);
-
-if ( !mfn )
-{
-printk(KERN_ERR
-   "NUMA: Unable to allocate Memory to Node hash map\n");
-memnodemapsize = 0;
-return -1;
-}
-
-memnodemap = mfn_to_virt(mfn);
-mfn <<= PAGE_SHIFT;
-size <<= PAGE_SHIFT;
-printk(KERN_DEBUG "NUMA: Allocated memnodemap from %lx - %lx\n",
-   mfn, mfn + size);
-memnodemapsize = size / sizeof(*memnodemap);
-
-return 0;
-}
-
-/*
- * The LSB of all start and end addresses in the node map is the value of the
- * maximum possible shift.
- */
-static int __init extract_lsb_from_nodes(const struct node *nodes,
- int numnodes)
-{
-int i, nodes_used = 0;
-unsigned long spdx, epdx;
-unsigned long bitfield = 0, memtop = 0;
-
-for ( i = 0; i < numnodes; i++ )
-{
-spdx = paddr_to_pdx(nodes[i].start);
-epdx = paddr_to_pdx(nodes[i].end - 1) + 1;
-if ( spdx >= epdx )
-continue;
-bitfield |= spdx;
-nodes_used++;
-if ( epdx > memtop )
-memtop = epdx;
-}
-if ( nodes_used <= 1 )
-i = BITS_PER_LONG - 1;
-else
-i = find_first_bit(, sizeof(unsigned long)*8);
-memnodemapsize = (memtop >> i) + 1;
-return i;
-}
-
-int __init compute_hash_shift(struct node *nodes, int numnodes,
-  nodeid_t *nodeids)
-{
-int shift;
-
-shift = extract_lsb_from_nodes(nodes, numnodes);
-if ( memnodemapsize <= ARRAY_SIZE(_memnodemap) )
-memnodemap = _memnodemap;
-else if ( allocate_cachealigned_memnodemap() )
-return -1;
-printk(KERN_DEBUG "NUMA: Using %d for the hash shift.\n", shift);
-
-if ( populate_memnodemap(nodes, numnodes, shift, nodeids) != 1 )
-{
-printk(KERN_INFO "Your memory is not aligned you need to "
-   "rebuild your hypervisor with a bigger NODEMAPSIZE "
-   "shift=%d\n", shift);
-return -1;
-}
-
-return shift;
-}
-/* initialize NODE_DATA given nodeid and 

[Xen-devel] [RFC PATCH v1 00/21] ARM: Add Xen NUMA support

[vijay . kilari]

From: Vijaya Kumar K 

With this RFC patch series, NUMA support is added for arm platform.
Both DT and ACPI based NUMA support is added.
Only Xen is made aware of NUMA platform. Dom0 is awareness is not
added.

As part of this series, the code under x86 architecture is
reused by moving into common files.
New files xen/common/numa.c and xen/commom/srat.c files are
added which are common for both x86 and arm.

Patches 1 - 12 & 20 are for DT NUMA and 13 - 19 & 21 are for
ACPI NUMA.

DT NUMA: The following major changes are performed
 - Dropped numa-node-id information from Dom0 DT.
   So that Dom0 devices make allocation from node 0 for
   devmalloc requests.
 - Memory DT is not deleted by EFI. It is exposed to Xen
   to extract numa information.
 - On NUMA failure, Fallback to Non-NUMA booting.
   Assuming all the memory and CPU's are under node 0.
 - CONFIG_NUMA is introduced.

ACPI NUMA:
 - MADT is parsed before parsing SRAT table to extract
   CPU_ID to MPIDR mapping info. In Linux, while parsing SRAT
   table, MADT table is opened and extract MPIDR. However this
   approach is not working on Xen it allows only one table to
   be open at a time because when ACPI table is opened, Xen
   maps to single region. So opening ACPI tables recursively
   leads to overwriting of contents.
 - SRAT table is parsed for ACPI_SRAT_TYPE_GICC_AFFINITY to extract
   proximity info and MPIDR from CPU_ID to MPIDR mapping table.
 - SRAT table is parsed for ACPI_SRAT_TYPE_MEMORY_AFFINITY to extract
   memory proximity.
 - Re-use SLIT parsing of x86 for node distance information.
 - CONFIG_ACPI_NUMA is introduced

The node_distance() API is implemented separately for x86 and arm
as arm has DT and ACPI based distance information.

No changes are made to x86 implementation only code is refactored.
Hence only compilation tested for x86.

Code is shared at https://github.com/vijaykilari/xen-numa rfc_1

Note: Please use this patch series only for review.
For testing, patch to boot allocator is required. Which will
be sent outside this series.

Vijaya Kumar K (21):
  ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA
  x86: NUMA: Refactor NUMA code
  NUMA: Move arch specific NUMA code as common
  NUMA: Refactor generic and arch specific code of numa_setup
  ARM: efi: Do not delete memory node from fdt
  ARM: NUMA: Parse CPU NUMA information
  ARM: NUMA: Parse memory NUMA information
  ARM: NUMA: Parse NUMA distance information
  ARM: NUMA: Add CPU NUMA support
  ARM: NUMA: Add memory NUMA support
  ARM: NUMA: Add fallback on NUMA failure
  ARM: NUMA: Do not expose numa info to DOM0
  ACPI: Refactor acpi SRAT and SLIT table handling code
  ACPI: Move srat_disabled to common code
  ARM: NUMA: Extract MPIDR from MADT table
  ARM: NUMA: Extract proximity from SRAT table
  ARM: NUMA: Extract memory proximity from SRAT table
  ARM: NUMA: update node_distance with ACPI support
  ARM: NUMA: Initialize ACPI NUMA
  ARM: NUMA: Enable CONFIG_NUMA config
  ARM: NUMA: Enable CONFIG_ACPI_NUMA config

 xen/arch/arm/Kconfig|   5 +
 xen/arch/arm/Makefile   |   3 +
 xen/arch/arm/acpi_numa.c| 257 +
 xen/arch/arm/bootfdt.c  |  21 +-
 xen/arch/arm/domain_build.c |   9 +
 xen/arch/arm/dt_numa.c  | 244 
 xen/arch/arm/efi/efi-boot.h |  25 --
 xen/arch/arm/numa.c | 249 
 xen/arch/arm/setup.c|   5 +
 xen/arch/arm/smpboot.c  |   3 +
 xen/arch/x86/domain_build.c |   1 +
 xen/arch/x86/numa.c | 318 +-
 xen/arch/x86/physdev.c  |   1 +
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   1 +
 xen/arch/x86/srat.c | 183 +--
 xen/arch/x86/x86_64/mm.c|   1 +
 xen/common/Makefile |   2 +
 xen/common/numa.c   | 439 
 xen/common/srat.c   | 157 +
 xen/drivers/acpi/numa.c |  37 +++
 xen/drivers/acpi/osl.c  |   2 +
 xen/drivers/passthrough/vtd/iommu.c |   1 +
 xen/include/acpi/actbl1.h   |  17 +-
 xen/include/asm-arm/acpi.h  |   2 +
 xen/include/asm-arm/numa.h  |  41 
 xen/include/asm-x86/acpi.h  |   2 -
 xen/include/asm-x86/numa.h  |  53 +
 xen/include/xen/acpi.h  |  39 
 xen/include/xen/device_tree.h   |   7 +
 xen/include/xen/numa.h  |  61 -
 xen/include/xen/srat.h  |  15 ++
 32 files changed, 1620 insertions(+), 582 deletions(-)
 create mode 100644 xen/arch/arm/acpi_numa.c
 create mode 100644 xen/arch/arm/dt_numa.c
 create mode 100644 xen/arch/arm/numa.c
 create mode 100644 xen/common/numa.c
 create mode 100644 xen/common/srat.c
 create mode 100644 xen/include/xen/srat.h

-- 
2.7.4

[Xen-devel] [RFC PATCH v1 01/21] ARM: NUMA: Add existing ARM numa code under CONFIG_NUMA

[vijay . kilari]

From: Vijaya Kumar K 

Right not CONFIG_NUMA is not enabled for ARM and
existing code in asm-arm/numa.h is for !COFIG_NUMA.
Hence put this code under #ifndef CONFIG_NUMA.

This help to make this changes work when CONFIG_NUMA
is not enabled.

Also define NODES_SHIFT macro for ARM.

Signed-off-by: Vijaya Kumar K 
---
 xen/include/asm-arm/numa.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a2c1a34..a60c7eb 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -3,6 +3,9 @@
 
 typedef u8 nodeid_t;
 
+#define NODES_SHIFT 2
+
+#ifndef CONFIG_NUMA
 /* Fake one node for now. See also node_online_map. */
 #define cpu_to_node(cpu) 0
 #define node_to_cpumask(node)   (cpu_online_map)
@@ -16,6 +19,7 @@ static inline __attribute__((pure)) nodeid_t 
phys_to_nid(paddr_t addr)
 #define node_spanned_pages(nid) (total_pages)
 #define node_start_pfn(nid) (pdx_to_pfn(frametable_base_pdx))
 #define __node_distance(a, b) (20)
+#endif /* CONFIG_NUMA */
 
 static inline unsigned int arch_get_dma_bitsize(void)
 {
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 03/21] NUMA: Move arch specific NUMA code as common

[vijay . kilari]

From: Vijaya Kumar K 

Move some common numa code from xen/arch/x86/srat.c
to xen/common/numa.c

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/x86/srat.c| 54 -
 xen/common/numa.c  | 55 ++
 xen/include/asm-x86/acpi.h |  1 -
 xen/include/asm-x86/numa.h |  1 -
 xen/include/xen/numa.h |  5 -
 5 files changed, 63 insertions(+), 53 deletions(-)

diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index d86783e..58dee09 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -25,7 +25,7 @@ static struct acpi_table_slit *__read_mostly acpi_slit;
 
 static nodemask_t memory_nodes_parsed __initdata;
 static nodemask_t processor_nodes_parsed __initdata;
-static struct node nodes[MAX_NUMNODES] __initdata;
+extern struct node nodes[MAX_NUMNODES] __initdata;
 
 struct pxm2node {
unsigned pxm;
@@ -36,9 +36,9 @@ static struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
 
 static unsigned node_to_pxm(nodeid_t n);
 
-static int num_node_memblks;
-static struct node node_memblk_range[NR_NODE_MEMBLKS];
-static nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
 
 static inline bool_t node_found(unsigned idx, unsigned pxm)
@@ -103,52 +103,6 @@ nodeid_t setup_node(unsigned pxm)
return node;
 }
 
-int valid_numa_range(u64 start, u64 end, nodeid_t node)
-{
-   int i;
-
-   for (i = 0; i < num_node_memblks; i++) {
-   struct node *nd = _memblk_range[i];
-
-   if (nd->start <= start && nd->end > end &&
-   memblk_nodeid[i] == node )
-   return 1;
-   }
-
-   return 0;
-}
-
-static __init int conflicting_memblks(u64 start, u64 end)
-{
-   int i;
-
-   for (i = 0; i < num_node_memblks; i++) {
-   struct node *nd = _memblk_range[i];
-   if (nd->start == nd->end)
-   continue;
-   if (nd->end > start && nd->start < end)
-   return i;
-   if (nd->end == end && nd->start == start)
-   return i;
-   }
-   return -1;
-}
-
-static __init void cutoff_node(int i, u64 start, u64 end)
-{
-   struct node *nd = [i];
-   if (nd->start < start) {
-   nd->start = start;
-   if (nd->end < nd->start)
-   nd->start = nd->end;
-   }
-   if (nd->end > end) {
-   nd->end = end;
-   if (nd->start > nd->end)
-   nd->start = nd->end;
-   }
-}
-
 static __init void bad_srat(void)
 {
int i;
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 59dcb63..13f147c 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -46,6 +46,61 @@ nodeid_t cpu_to_node[NR_CPUS] __read_mostly = {
 
 cpumask_t node_to_cpumask[MAX_NUMNODES] __read_mostly;
 
+int num_node_memblks;
+struct node node_memblk_range[NR_NODE_MEMBLKS];
+nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
+struct node nodes[MAX_NUMNODES] __initdata;
+
+int valid_numa_range(u64 start, u64 end, nodeid_t node)
+{
+#ifdef CONFIG_NUMA
+int i;
+
+for (i = 0; i < num_node_memblks; i++) {
+struct node *nd = _memblk_range[i];
+
+if (nd->start <= start && nd->end > end &&
+memblk_nodeid[i] == node )
+return 1;
+}
+
+return 0;
+#else
+return 1;
+#endif
+}
+
+__init int conflicting_memblks(u64 start, u64 end)
+{
+int i;
+
+for (i = 0; i < num_node_memblks; i++) {
+struct node *nd = _memblk_range[i];
+if (nd->start == nd->end)
+continue;
+if (nd->end > start && nd->start < end)
+return i;
+if (nd->end == end && nd->start == start)
+return i;
+}
+return -1;
+}
+
+__init void cutoff_node(int i, u64 start, u64 end)
+{
+struct node *nd = [i];
+if (nd->start < start) {
+nd->start = start;
+if (nd->end < nd->start)
+nd->start = nd->end;
+}
+if (nd->end > end) {
+nd->end = end;
+if (nd->start > nd->end)
+nd->start = nd->end;
+}
+}
+
 /*
  * Given a shift value, try to populate memnodemap[]
  * Returns :
diff --git a/xen/include/asm-x86/acpi.h b/xen/include/asm-x86/acpi.h
index d36bee9..f1a8e9d 100644
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -106,7 +106,6 @@ extern void acpi_reserve_bootmem(void);
 
 extern s8 acpi_numa;
 extern int acpi_scan_nodes(u64 start, u64 end);
-#define NR_NODE_MEMBLKS (MAX_NUMNODES*2)
 
 #ifdef CONFIG_ACPI_SLEEP
 
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index 61bcd8e..df1f7d5 100644
--- a/xen/include/asm-x86/numa.h
+++ 

[Xen-devel] [RFC PATCH v1 05/21] ARM: efi: Do not delete memory node from fdt

[vijay . kilari]

From: Vijaya Kumar K 

When booting in UEFI mode, UEFI passes memory information
to Dom0 using EFI memory descriptor table and deletes the
memory nodes from the host DT. However to fetch the memory
numa node id, memory DT node should not be deleted by EFI stub.

With this patch, do not delete memory node from FDT.
This memory nodes are later used by XEN to extract numa
node id information.

Also, parse memory node only if bootmeminfo is NULL.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/bootfdt.c  |  9 +++--
 xen/arch/arm/efi/efi-boot.h | 25 -
 2 files changed, 7 insertions(+), 27 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index cae6f83..979f675 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -285,8 +285,13 @@ static int __init early_scan_node(const void *fdt,
   u32 address_cells, u32 size_cells,
   void *data)
 {
-if ( device_tree_node_matches(fdt, node, "memory") )
-process_memory_node(fdt, node, name, address_cells, size_cells);
+/*
+ * Parse memory node only if bootinfo.mem is empty.
+ */
+if ( bootinfo.mem.nr_banks == 0 ) {
+if ( device_tree_node_matches(fdt, node, "memory") )
+process_memory_node(fdt, node, name, address_cells, size_cells);
+}
 else if ( device_tree_node_compatible(fdt, node, "xen,multiboot-module" ) 
||
   device_tree_node_compatible(fdt, node, "multiboot,module" ))
 process_multiboot_node(fdt, node, name, address_cells, size_cells);
diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h
index 045d6ce..0b9c37f 100644
--- a/xen/arch/arm/efi/efi-boot.h
+++ b/xen/arch/arm/efi/efi-boot.h
@@ -192,33 +192,8 @@ EFI_STATUS __init fdt_add_uefi_nodes(EFI_SYSTEM_TABLE 
*sys_table,
 int status;
 u32 fdt_val32;
 u64 fdt_val64;
-int prev;
 int num_rsv;
 
-/*
- * Delete any memory nodes present.  The EFI memory map is the only
- * memory description provided to Xen.
- */
-prev = 0;
-for (;;)
-{
-const char *type;
-int len;
-
-node = fdt_next_node(fdt, prev, NULL);
-if ( node < 0 )
-break;
-
-type = fdt_getprop(fdt, node, "device_type", );
-if ( type && strncmp(type, "memory", len) == 0 )
-{
-fdt_del_node(fdt, node);
-continue;
-}
-
-prev = node;
-}
-
/*
 * Delete all memory reserve map entries. When booting via UEFI,
 * kernel will use the UEFI memory map to find reserved regions.
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 04/21] NUMA: Refactor generic and arch specific code of numa_setup

[vijay . kilari]

From: Vijaya Kumar K 

numa_setup() contains generic and arch specific code.
Split numa_setup() and move architecture specific code
under arch_numa_setup().

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/Makefile  |  1 +
 xen/arch/arm/numa.c| 28 
 xen/arch/x86/numa.c| 11 +--
 xen/common/numa.c  | 14 ++
 xen/include/asm-arm/numa.h |  9 -
 xen/include/asm-x86/numa.h |  2 +-
 xen/include/xen/numa.h |  1 +
 7 files changed, 54 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7afb8a3..b5d7a19 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -49,6 +49,7 @@ obj-y += vm_event.o
 obj-y += vtimer.o
 obj-y += vpsci.o
 obj-y += vuart.o
+obj-$(CONFIG_NUMA) += numa.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
new file mode 100644
index 000..59d09c7
--- /dev/null
+++ b/xen/arch/arm/numa.c
@@ -0,0 +1,28 @@
+/*
+ * ARM NUMA Implementation
+ *
+ * Copyright (C) 2016 - Cavium Inc.
+ * Vijaya Kumar K 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int __init arch_numa_setup(char *opt)
+{
+return 1;
+}
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index bc787e0..28d1891 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -18,9 +18,6 @@
 #include 
 #include 
 
-static int numa_setup(char *s);
-custom_param("numa", numa_setup);
-
 #ifndef Dprintk
 #define Dprintk(x...)
 #endif
@@ -34,7 +31,6 @@ nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
-bool_t numa_off = 0;
 s8 acpi_numa = 0;
 
 int srat_disabled(void)
@@ -145,13 +141,8 @@ void __init numa_initmem_init(unsigned long start_pfn, 
unsigned long end_pfn)
 (u64)end_pfn << PAGE_SHIFT);
 }
 
-/* [numa=off] */
-static __init int numa_setup(char *opt) 
+int __init arch_numa_setup(char *opt)
 { 
-if ( !strncmp(opt,"off",3) )
-numa_off = 1;
-if ( !strncmp(opt,"on",2) )
-numa_off = 0;
 #ifdef CONFIG_NUMA_EMU
 if ( !strncmp(opt, "fake=", 5) )
 {
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 13f147c..9b9cf9c 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -32,6 +32,10 @@
 #include 
 #include 
 
+static int numa_setup(char *s);
+custom_param("numa", numa_setup);
+
+bool_t numa_off = 0;
 struct node_data node_data[MAX_NUMNODES];
 
 /* Mapping from pdx to node id */
@@ -250,6 +254,16 @@ EXPORT_SYMBOL(memnode_shift);
 EXPORT_SYMBOL(memnodemap);
 EXPORT_SYMBOL(node_data);
 
+static __init int numa_setup(char *opt)
+{
+if ( !strncmp(opt,"off",3) )
+numa_off = 1;
+if ( !strncmp(opt,"on",2) )
+numa_off = 0;
+
+return arch_numa_setup(opt);
+}
+
 static void dump_numa(unsigned char key)
 {
 s_time_t now = NOW();
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index a60c7eb..c1e8a7d 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -5,7 +5,14 @@ typedef u8 nodeid_t;
 
 #define NODES_SHIFT 2
 
-#ifndef CONFIG_NUMA
+#ifdef CONFIG_NUMA
+int arch_numa_setup(char *opt);
+#else
+static inline int arch_numa_setup(char *opt)
+{
+return 1;
+}
+
 /* Fake one node for now. See also node_online_map. */
 #define cpu_to_node(cpu) 0
 #define node_to_cpumask(node)   (cpu_online_map)
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index df1f7d5..659ff6a 100644
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -22,7 +22,6 @@ extern nodeid_t pxm_to_node(unsigned int pxm);
 #define ZONE_ALIGN (1UL << (MAX_ORDER+PAGE_SHIFT))
 
 extern void numa_init_array(void);
-extern bool_t numa_off;
 
 extern int srat_disabled(void);
 extern void srat_detect_node(int cpu);
@@ -32,5 +31,6 @@ extern nodeid_t apicid_to_node[];
 void srat_parse_regions(u64 addr);
 extern u8 __node_distance(nodeid_t a, nodeid_t b);
 unsigned int arch_get_dma_bitsize(void);
+int arch_numa_setup(char *opt);
 
 #endif
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 810f742..77c5cfd 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -18,6 +18,7 @@
   (((d)->vcpu != NULL && (d)->vcpu[0] != NULL) \
? vcpu_to_node((d)->vcpu[0]) : NUMA_NO_NODE)
 
+extern bool_t numa_off;
 struct node {
u64 start,end;
 };
-- 
2.7.4

[Xen-devel] [RFC PATCH v1 16/21] ARM: NUMA: Extract proximity from SRAT table

[vijay . kilari]

From: Vijaya Kumar K 

Register SRAT entry handler for type
ACPI_SRAT_TYPE_GICC_AFFINITY to parse SRAT table
and extract proximity for all CPU IDs.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/acpi_numa.c  | 55 +++
 xen/drivers/acpi/numa.c   | 37 +++
 xen/drivers/acpi/osl.c|  2 ++
 xen/include/acpi/actbl1.h | 17 ++-
 xen/include/xen/acpi.h| 39 +
 5 files changed, 149 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
index 3ee87f2..f659275 100644
--- a/xen/arch/arm/acpi_numa.c
+++ b/xen/arch/arm/acpi_numa.c
@@ -105,6 +105,61 @@ static int __init acpi_parse_madt_handler(struct 
acpi_subtable_header *header,
 return 0;
 }
 
+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(const struct acpi_srat_gicc_affinity 
*pa)
+{
+int pxm, node;
+u64 mpidr = 0;
+static u32 cpus_in_srat;
+
+if ( srat_disabled() )
+return;
+
+if ( pa->header.length < sizeof(struct acpi_srat_gicc_affinity) )
+{
+printk(XENLOG_WARNING "SRAT: Invalid SRAT header length: %d\n",
+   pa->header.length);
+bad_srat();
+return;
+}
+
+if ( !(pa->flags & ACPI_SRAT_GICC_ENABLED) )
+return;
+
+if ( cpus_in_srat >= NR_CPUS )
+{
+printk(XENLOG_WARNING
+   "SRAT: cpu_to_node_map[%d] is too small to fit all cpus\n",
+   NR_CPUS);
+return;
+}
+
+pxm = pa->proximity_domain;
+node = setup_node(pxm);
+if ( node == NUMA_NO_NODE || node >= MAX_NUMNODES )
+{
+printk(XENLOG_WARNING "SRAT: Too many proximity domains %d\n", pxm);
+bad_srat();
+return;
+}
+
+mpidr = acpi_get_cpu_mpidr(pa->acpi_processor_uid);
+if ( mpidr == MPIDR_INVALID )
+{
+printk(XENLOG_WARNING
+   "SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+   pxm, pa->acpi_processor_uid);
+bad_srat();
+return;
+}
+
+node_set(node, numa_nodes_parsed);
+cpus_in_srat++;
+acpi_numa = 1;
+printk(XENLOG_INFO "SRAT: PXM %d -> MPIDR 0x%lx -> Node %d\n",
+   pxm, mpidr, node);
+}
+
 void __init acpi_map_uid_to_mpidr(void)
 {
 int i;
diff --git a/xen/drivers/acpi/numa.c b/xen/drivers/acpi/numa.c
index 50bf9f8..ce22e88 100644
--- a/xen/drivers/acpi/numa.c
+++ b/xen/drivers/acpi/numa.c
@@ -25,9 +25,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #define ACPI_NUMA  0x8000
 #define _COMPONENT ACPI_NUMA
@@ -105,6 +107,21 @@ void __init acpi_table_print_srat_entry(struct 
acpi_subtable_header * header)
}
 #endif /* ACPI_DEBUG_OUTPUT */
break;
+   case ACPI_SRAT_TYPE_GICC_AFFINITY:
+#ifdef ACPI_DEBUG_OUTPUT
+   {
+   struct acpi_srat_gicc_affinity *p =
+   (struct acpi_srat_gicc_affinity *)header;
+   ACPI_DEBUG_PRINT((ACPI_DB_INFO,
+ "SRAT Processor (acpi id[0x%04x]) in"
+ " proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_GICC_ENABLED) ?
+ "enabled" : "disabled");
+   }
+#endif /* ACPI_DEBUG_OUTPUT */
+   break;
default:
printk(KERN_WARNING PREFIX
   "Found unsupported SRAT entry (type = %#x)\n",
@@ -185,6 +202,24 @@ int __init acpi_parse_srat(struct acpi_table_header *table)
return 0;
 }
 
+static int __init
+acpi_parse_gicc_affinity(struct acpi_subtable_header *header,
+const unsigned long end)
+{
+   const struct acpi_srat_gicc_affinity *processor_affinity
+   = (struct acpi_srat_gicc_affinity *)header;
+
+   if (!processor_affinity)
+   return -EINVAL;
+
+   acpi_table_print_srat_entry(header);
+
+   /* let architecture-dependent part to do it */
+   acpi_numa_gicc_affinity_init(processor_affinity);
+
+   return 0;
+}
+
 int __init
 acpi_table_parse_srat(int id, acpi_madt_entry_handler handler,
  unsigned int max_entries)
@@ -205,6 +240,8 @@ int __init acpi_numa_init(void)
acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
  acpi_parse_memory_affinity,
  NR_NODE_MEMBLKS);
+   acpi_table_parse_srat(ACPI_SRAT_TYPE_GICC_AFFINITY,
+ 

[Xen-devel] [RFC PATCH v1 15/21] ARM: NUMA: Extract MPIDR from MADT table

[vijay . kilari]

From: Vijaya Kumar K 

Parse MADT table and extract MPIDR for all
CPU IDs in MADT ACPI_MADT_TYPE_GENERIC_INTERRUPT entries
and store in cpu_uid_to_hwid[].

This mapping is used by SRAT table parsing to
extract MPIDR of the CPU ID.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/Makefile  |   1 +
 xen/arch/arm/acpi_numa.c   | 122 +
 xen/arch/arm/numa.c|   1 +
 xen/include/asm-arm/acpi.h |   2 +
 4 files changed, 126 insertions(+)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 7694485..8c5e67b 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,6 +51,7 @@ obj-y += vpsci.o
 obj-y += vuart.o
 obj-$(CONFIG_NUMA) += numa.o
 obj-$(CONFIG_NUMA) += dt_numa.o
+obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
new file mode 100644
index 000..3ee87f2
--- /dev/null
+++ b/xen/arch/arm/acpi_numa.c
@@ -0,0 +1,122 @@
+/*
+ * ACPI based NUMA setup
+ *
+ * Copyright (C) 2016 - Cavium Inc.
+ * Vijaya Kumar K 
+ *
+ * Reads the ACPI MADT and SRAT table to setup NUMA information.
+ *
+ * Contains Excerpts from x86 implementation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+extern nodemask_t numa_nodes_parsed;
+struct uid_to_mpidr {
+u32 uid;
+u64 mpidr;
+};
+
+/* Holds mapping of CPU id to MPIDR read from MADT */
+static struct uid_to_mpidr cpu_uid_to_hwid[NR_CPUS] __read_mostly;
+
+static __init void bad_srat(void)
+{
+int i;
+
+printk(KERN_ERR "SRAT: SRAT not used.\n");
+acpi_numa = -1;
+for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
+pxm2node[i].node = NUMA_NO_NODE;
+}
+
+static u64 acpi_get_cpu_mpidr(int uid)
+{
+int i;
+
+if ( uid < ARRAY_SIZE(cpu_uid_to_hwid) && cpu_uid_to_hwid[uid].uid == uid 
&&
+ cpu_uid_to_hwid[uid].mpidr != MPIDR_INVALID )
+return cpu_uid_to_hwid[uid].mpidr;
+
+for ( i = 0; i < NR_CPUS; i++ )
+{
+if ( cpu_uid_to_hwid[i].uid == uid )
+return cpu_uid_to_hwid[i].mpidr;
+}
+
+return MPIDR_INVALID;
+}
+
+static void __init
+acpi_map_cpu_to_mpidr(struct acpi_madt_generic_interrupt *processor)
+{
+static int cpus = 0;
+
+u64 mpidr = processor->arm_mpidr & MPIDR_HWID_MASK;
+
+if ( mpidr == MPIDR_INVALID )
+{
+printk("Skip MADT cpu entry with invalid MPIDR\n");
+bad_srat();
+return;
+}
+
+cpu_uid_to_hwid[cpus].mpidr = mpidr;
+cpu_uid_to_hwid[cpus].uid = processor->uid;
+
+cpus++;
+}
+
+static int __init acpi_parse_madt_handler(struct acpi_subtable_header *header,
+  const unsigned long end)
+{
+struct acpi_madt_generic_interrupt *p =
+   container_of(header, struct acpi_madt_generic_interrupt, 
header);
+
+if ( BAD_MADT_ENTRY(p, end) )
+{
+/* Though MADT is invalid, we disable NUMA by calling bad_srat() */
+bad_srat();
+return -EINVAL;
+}
+
+acpi_table_print_madt_entry(header);
+acpi_map_cpu_to_mpidr(p);
+
+return 0;
+}
+
+void __init acpi_map_uid_to_mpidr(void)
+{
+int i;
+
+for ( i  = 0; i < NR_CPUS; i++ )
+{
+cpu_uid_to_hwid[i].mpidr = MPIDR_INVALID;
+cpu_uid_to_hwid[i].uid = -1;
+}
+
+acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+acpi_parse_madt_handler, 0);
+}
+
+void __init acpi_numa_arch_fixup(void) {}
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 31dc552..5c49347 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
index 9f954d3..b1f36f4 100644
--- a/xen/include/asm-arm/acpi.h
+++ b/xen/include/asm-arm/acpi.h
@@ -68,6 +68,8 @@ static inline void enable_acpi(void)
 {
 acpi_disabled = 0;
 }
+
+void acpi_map_uid_to_mpidr(void);
 #else
 #define acpi_disabled (1)
 #define disable_acpi()
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 17/21] ARM: NUMA: Extract memory proximity from SRAT table

[vijay . kilari]

From: Vijaya Kumar K 

Register SRAT entry handler for type
ACPI_SRAT_TYPE_MEMORY_AFFINITY to parse SRAT table
and extract proximity for all memory mappings.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/acpi_numa.c | 80 
 1 file changed, 80 insertions(+)

diff --git a/xen/arch/arm/acpi_numa.c b/xen/arch/arm/acpi_numa.c
index f659275..23cb07b 100644
--- a/xen/arch/arm/acpi_numa.c
+++ b/xen/arch/arm/acpi_numa.c
@@ -30,6 +30,9 @@
 #include 
 #include 
 
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 extern nodemask_t numa_nodes_parsed;
 struct uid_to_mpidr {
 u32 uid;
@@ -38,6 +41,7 @@ struct uid_to_mpidr {
 
 /* Holds mapping of CPU id to MPIDR read from MADT */
 static struct uid_to_mpidr cpu_uid_to_hwid[NR_CPUS] __read_mostly;
+static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
 
 static __init void bad_srat(void)
 {
@@ -160,6 +164,82 @@ void __init acpi_numa_gicc_affinity_init(const struct 
acpi_srat_gicc_affinity *p
pxm, mpidr, node);
 }
 
+/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
+void __init
+acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
+{
+u64 start, end;
+unsigned pxm;
+nodeid_t node;
+int i;
+
+if ( srat_disabled() )
+return;
+
+if ( ma->header.length != sizeof(struct acpi_srat_mem_affinity) )
+{
+bad_srat();
+return;
+}
+if ( !(ma->flags & ACPI_SRAT_MEM_ENABLED) )
+return;
+
+if ( num_node_memblks >= NR_NODE_MEMBLKS )
+{
+printk(XENLOG_WARNING
+   "Too many numa entry, try bigger NR_NODE_MEMBLKS \n");
+bad_srat();
+return;
+}
+
+start = ma->base_address;
+end = start + ma->length;
+pxm = ma->proximity_domain;
+node = setup_node(pxm);
+if ( node == NUMA_NO_NODE )
+{
+bad_srat();
+return;
+}
+/* It is fine to add this area to the nodes data it will be used later*/
+i = conflicting_memblks(start, end);
+if ( i < 0 )
+/* everything fine */;
+else if ( memblk_nodeid[i] == node )
+{
+bool_t mismatch = !(ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) !=
+   !test_bit(i, memblk_hotplug);
+
+printk(XENLOG_WARNING
+   "%sSRAT: PXM %u (%"PRIx64"-%"PRIx64") overlaps with itself 
(%"PRIx64"-%"PRIx64")\n",
+   mismatch ? KERN_ERR : KERN_WARNING, pxm, start, end,
+   node_memblk_range[i].start, node_memblk_range[i].end);
+if ( mismatch )
+{
+bad_srat();
+return;
+}
+}
+else
+{
+ printk(XENLOG_WARNING
+"SRAT: PXM %u (%"PRIx64"-%"PRIx64") overlaps with PXM %u 
(%"PRIx64"-%"PRIx64")\n",
+pxm, start, end, node_to_pxm(memblk_nodeid[i]),
+node_memblk_range[i].start, node_memblk_range[i].end);
+bad_srat();
+return;
+}
+
+printk(XENLOG_INFO "SRAT: Node %u PXM %u %"PRIx64"-%"PRIx64"%s\n",
+   node, pxm, start, end,
+   ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE ? " (hotplug)" : "");
+
+numa_add_memblk(node, start, ma->length);
+node_set(node, numa_nodes_parsed);
+if (ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)
+__set_bit(num_node_memblks, memblk_hotplug);
+}
+
 void __init acpi_map_uid_to_mpidr(void)
 {
 int i;
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 14/21] ACPI: Move srat_disabled to common code

[vijay . kilari]

From: Vijaya Kumar K 

Move srat_disabled() from xen/arch/x86/numa.c to
xen/commom/srat.c.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/x86/numa.c| 7 ---
 xen/common/srat.c  | 7 +++
 xen/include/asm-x86/acpi.h | 1 -
 xen/include/asm-x86/numa.h | 1 -
 xen/include/xen/srat.h | 2 ++
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 58de324..ec251bd 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -32,13 +32,6 @@ nodeid_t apicid_to_node[MAX_LOCAL_APIC] = {
 
 nodemask_t __read_mostly node_online_map = { { [0] = 1UL } };
 
-s8 acpi_numa = 0;
-
-int srat_disabled(void)
-{
-return numa_off || acpi_numa < 0;
-}
-
 void __init numa_init_array(void)
 {
 int rr, i;
diff --git a/xen/common/srat.c b/xen/common/srat.c
index cf50c78..a96406e 100644
--- a/xen/common/srat.c
+++ b/xen/common/srat.c
@@ -30,6 +30,13 @@ extern struct node nodes[MAX_NUMNODES] __initdata;
 struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
 { [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
 
+s8 acpi_numa = 0;
+
+int srat_disabled(void)
+{
+return numa_off || acpi_numa < 0;
+}
+
 static inline bool_t node_found(unsigned idx, unsigned pxm)
 {
 return ((pxm2node[idx].pxm == pxm) &&
diff --git a/xen/include/asm-x86/acpi.h b/xen/include/asm-x86/acpi.h
index f1a8e9d..934cd66 100644
--- a/xen/include/asm-x86/acpi.h
+++ b/xen/include/asm-x86/acpi.h
@@ -104,7 +104,6 @@ extern void acpi_reserve_bootmem(void);
 
 #define ARCH_HAS_POWER_INIT1
 
-extern s8 acpi_numa;
 extern int acpi_scan_nodes(u64 start, u64 end);
 
 #ifdef CONFIG_ACPI_SLEEP
diff --git a/xen/include/asm-x86/numa.h b/xen/include/asm-x86/numa.h
index 79a445c..9c11db4 100644
--- a/xen/include/asm-x86/numa.h
+++ b/xen/include/asm-x86/numa.h
@@ -21,7 +21,6 @@ extern cpumask_t node_to_cpumask[];
 
 extern void numa_init_array(void);
 
-extern int srat_disabled(void);
 extern void srat_detect_node(int cpu);
 
 extern nodeid_t apicid_to_node[];
diff --git a/xen/include/xen/srat.h b/xen/include/xen/srat.h
index 978f1e8..ab33d86 100644
--- a/xen/include/xen/srat.h
+++ b/xen/include/xen/srat.h
@@ -6,7 +6,9 @@ struct pxm2node {
 nodeid_t node;
 };
 
+extern s8 acpi_numa;
 extern struct pxm2node __read_mostly pxm2node[MAX_NUMNODES];
+extern int srat_disabled(void);
 nodeid_t pxm_to_node(unsigned pxm);
 nodeid_t setup_node(unsigned pxm);
 unsigned node_to_pxm(nodeid_t n);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 11/21] ARM: NUMA: Add fallback on NUMA failure

[vijay . kilari]

From: Vijaya Kumar K 

On NUMA initialization failure, reset all the
NUMA structures to emulate as single node.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/numa.c | 50 --
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index aa34c82..31dc552 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,29 @@ static int __init numa_scan_mem_nodes(void)
 return 0;
 }
 
+static void __init numa_dummy_init(unsigned long start_pfn,
+   unsigned long end_pfn)
+{
+int i;
+
+nodes_clear(numa_nodes_parsed);
+memnode_shift = BITS_PER_LONG - 1;
+memnodemap = _memnodemap;
+nodes_clear(node_online_map);
+node_set_online(0);
+
+for ( i = 0; i < NR_CPUS; i++ )
+numa_set_node(i, 0);
+
+node_distance = NULL;
+for ( i = 0; i < MAX_NUMNODES * 2; i++ )
+_node_distance[i] = 0;
+
+cpumask_copy(_to_cpumask[0], cpumask_of(0));
+setup_node_bootmem(0, (u64)start_pfn << PAGE_SHIFT,
+   (u64)end_pfn << PAGE_SHIFT);
+}
+
 static int __init numa_initmem_init(void)
 {
 if ( !numa_mem_init() )
@@ -151,7 +175,9 @@ void __init init_cpu_to_node(void)
 
 int __init numa_init(void)
 {
-int i, ret = 0;
+int i, bank, ret = 0;
+paddr_t ram_start = ~0;
+paddr_t ram_end = 0;
 
 if ( numa_off )
 goto no_numa;
@@ -164,8 +190,28 @@ int __init numa_init(void)
 if ( !ret )
 ret = numa_initmem_init();
 
+if ( !ret )
+return 0;
+
 no_numa:
-return ret;
+for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
+{
+paddr_t bank_start = bootinfo.mem.bank[bank].start;
+paddr_t bank_end = bank_start + bootinfo.mem.bank[bank].size;
+
+ram_start = min(ram_start, bank_start);
+ram_end = max(ram_end, bank_end);
+}
+
+printk(XENLOG_INFO "%s\n",
+   numa_off ? "NUMA turned off" : "No NUMA configuration found");
+
+printk(XENLOG_INFO "Faking a node at %016"PRIx64"-%016"PRIx64"\n",
+   (u64)ram_start, (u64)ram_end);
+
+numa_dummy_init(PFN_UP(ram_start),PFN_DOWN(ram_end));
+
+return 0;
 }
 
 int __init arch_numa_setup(char *opt)
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 08/21] ARM: NUMA: Parse NUMA distance information

[vijay . kilari]

From: Vijaya Kumar K 

Parse distance-matrix and fetch node distance information.
Store distance information in node_distance[].

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/dt_numa.c | 90 ++
 xen/arch/arm/numa.c| 19 +-
 xen/include/asm-arm/numa.h |  1 +
 3 files changed, 109 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
index fce9e67..8979612 100644
--- a/xen/arch/arm/dt_numa.c
+++ b/xen/arch/arm/dt_numa.c
@@ -28,6 +28,19 @@
 
 nodemask_t numa_nodes_parsed;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern int _node_distance[MAX_NUMNODES * 2];
+extern int *node_distance;
+
+static int numa_set_distance(u32 nodea, u32 nodeb, u32 distance)
+{
+   if ( nodea >= MAX_NUMNODES || nodeb >= MAX_NUMNODES )
+   return -EINVAL;
+
+   _node_distance[(nodea * MAX_NUMNODES) + nodeb] = distance;
+   node_distance = &_node_distance[0];
+
+   return 0;
+}
 
 /*
  * Even though we connect cpus to numa domains later in SMP
@@ -112,6 +125,66 @@ static int __init dt_numa_process_memory_node(const void 
*fdt, int node,
 return 0;
 }
 
+static int __init dt_numa_parse_distance_map(const void *fdt, int node,
+ const char *name,
+ u32 address_cells,
+ u32 size_cells)
+{
+const struct fdt_property *prop;
+const __be32 *matrix;
+int entry_count, len, i;
+
+printk(XENLOG_INFO "NUMA: parsing numa-distance-map\n");
+
+prop = fdt_get_property(fdt, node, "distance-matrix", );
+if ( !prop )
+{
+printk(XENLOG_WARNING
+   "NUMA: No distance-matrix property in distance-map\n");
+
+return -EINVAL;
+}
+
+if ( len % sizeof(u32) != 0 )
+{
+ printk(XENLOG_WARNING
+"distance-matrix in node is not a multiple of u32\n");
+
+return -EINVAL;
+}
+
+entry_count = len / sizeof(u32);
+if ( entry_count <= 0 )
+{
+printk(XENLOG_WARNING "NUMA: Invalid distance-matrix\n");
+
+return -EINVAL;
+}
+
+matrix = (const __be32 *)prop->data;
+for ( i = 0; i + 2 < entry_count; i += 3 )
+{
+u32 nodea, nodeb, distance;
+
+nodea = dt_read_number(matrix, 1);
+matrix++;
+nodeb = dt_read_number(matrix, 1);
+matrix++;
+distance = dt_read_number(matrix, 1);
+matrix++;
+
+numa_set_distance(nodea, nodeb, distance);
+printk(XENLOG_INFO "NUMA:  distance[node%d -> node%d] = %d\n",
+   nodea, nodeb, distance);
+
+/* Set default distance of node B->A same as A->B */
+if ( nodeb > nodea )
+numa_set_distance(nodeb, nodea, distance);
+}
+
+return 0;
+}
+
 static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
 const char *name, int depth,
 u32 address_cells, u32 size_cells,
@@ -136,6 +209,18 @@ static int __init dt_numa_scan_memory_node(const void 
*fdt, int node,
 return 0;
 }
 
+static int __init dt_numa_scan_distance_node(const void *fdt, int node,
+ const char *name, int depth,
+ u32 address_cells, u32 size_cells,
+ void *data)
+{
+if ( device_tree_node_matches(fdt, node, "distance-map") )
+return dt_numa_parse_distance_map(fdt, node, name, address_cells,
+  size_cells);
+
+return 0;
+}
+
 int __init dt_numa_init(void)
 {
 int ret;
@@ -149,6 +234,11 @@ int __init dt_numa_init(void)
 
 ret = device_tree_for_each_node((void *)device_tree_flattened,
 dt_numa_scan_memory_node, NULL);
+if ( ret )
+return ret;
+
+ret = device_tree_for_each_node((void *)device_tree_flattened,
+dt_numa_scan_distance_node, NULL);
 
 return ret;
 }
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 9a7f0bb..11d100b 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -22,14 +22,31 @@
 #include 
 #include 
 #include 
+#include 
+
+int _node_distance[MAX_NUMNODES * 2];
+int *node_distance;
+
+u8 __node_distance(nodeid_t a, nodeid_t b)
+{
+if ( !node_distance )
+return a == b ? 10 : 20;
+
+return _node_distance[a * MAX_NUMNODES + b];
+}
+
+EXPORT_SYMBOL(__node_distance);
 
 int __init numa_init(void)
 {
-int ret = 0;
+int i, ret = 0;
 
 if ( numa_off )
 goto no_numa;
 
+for ( i = 0; i < MAX_NUMNODES * 2; i++ )
+_node_distance[i] = 0;
+
 ret = dt_numa_init();
 
 no_numa:
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index cdfeecd..b8857e2 100644
--- 

[Xen-devel] [RFC PATCH v1 12/21] ARM: NUMA: Do not expose numa info to DOM0

[vijay . kilari]

From: Vijaya Kumar K 

Delete numa-node-id and distance map from Dom0 DT
so that NUMA information is not exposed to Dom0.

This helps particularly to boot Node 1 devices
as if booting on Node0.

However this approach has limitation where memory allocation
for the devices should be local.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/arm/domain_build.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c97a1f5..5e89eaa 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -424,6 +424,10 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
 }
 }
 
+/* Don't expose the property numa to the guest */
+if ( dt_property_name_is_equal(prop, "numa-node-id") )
+continue;
+
 /* Don't expose the property "xen,passthrough" to the guest */
 if ( dt_property_name_is_equal(prop, "xen,passthrough") )
 continue;
@@ -1176,6 +1180,11 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_TYPE("memory"),
 /* The memory mapped timer is not supported by Xen. */
 DT_MATCH_COMPATIBLE("arm,armv7-timer-mem"),
+/*
+ * NUMA info is not exposed to Dom0.
+ * So, skip distance-map infomation
+ */
+DT_MATCH_COMPATIBLE("numa-distance-map-v1"),
 { /* sentinel */ },
 };
 static const struct dt_device_match timer_matches[] __initconst =
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 13/21] ACPI: Refactor acpi SRAT and SLIT table handling code

[vijay . kilari]

From: Vijaya Kumar K 

Move SRAT handling code which is common across
architecture is moved to new file xen/commom/srat.c
from xen/arch/x86/srat.c file. New header file srat.h is
introduced.

Signed-off-by: Vijaya Kumar 
---
 xen/arch/x86/domain_build.c |   1 +
 xen/arch/x86/numa.c |   1 +
 xen/arch/x86/physdev.c  |   1 +
 xen/arch/x86/setup.c|   1 +
 xen/arch/x86/smpboot.c  |   1 +
 xen/arch/x86/srat.c | 129 +--
 xen/arch/x86/x86_64/mm.c|   1 +
 xen/common/Makefile |   1 +
 xen/common/srat.c   | 150 
 xen/drivers/passthrough/vtd/iommu.c |   1 +
 xen/include/asm-x86/numa.h  |   2 -
 xen/include/xen/numa.h  |   1 -
 xen/include/xen/srat.h  |  13 
 13 files changed, 173 insertions(+), 130 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 243df96..4d7795b 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/numa.c b/xen/arch/x86/numa.c
index 28d1891..58de324 100644
--- a/xen/arch/x86/numa.c
+++ b/xen/arch/x86/numa.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 5a49796..2184d62 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 176ee74..ee7a368 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 9b390b8..6c61114 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 58dee09..af12e26 100644
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -18,91 +18,20 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-static struct acpi_table_slit *__read_mostly acpi_slit;
+extern struct acpi_table_slit *__read_mostly acpi_slit;
 
 static nodemask_t memory_nodes_parsed __initdata;
 static nodemask_t processor_nodes_parsed __initdata;
 extern struct node nodes[MAX_NUMNODES] __initdata;
-
-struct pxm2node {
-   unsigned pxm;
-   nodeid_t node;
-};
-static struct pxm2node __read_mostly pxm2node[MAX_NUMNODES] =
-   { [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
-
-static unsigned node_to_pxm(nodeid_t n);
-
 extern int num_node_memblks;
 extern struct node node_memblk_range[NR_NODE_MEMBLKS];
 extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 static __initdata DECLARE_BITMAP(memblk_hotplug, NR_NODE_MEMBLKS);
 
-static inline bool_t node_found(unsigned idx, unsigned pxm)
-{
-   return ((pxm2node[idx].pxm == pxm) &&
-   (pxm2node[idx].node != NUMA_NO_NODE));
-}
-
-nodeid_t pxm_to_node(unsigned pxm)
-{
-   unsigned i;
-
-   if ((pxm < ARRAY_SIZE(pxm2node)) && node_found(pxm, pxm))
-   return pxm2node[pxm].node;
-
-   for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
-   if (node_found(i, pxm))
-   return pxm2node[i].node;
-
-   return NUMA_NO_NODE;
-}
-
-nodeid_t setup_node(unsigned pxm)
-{
-   nodeid_t node;
-   unsigned idx;
-   static bool_t warned;
-   static unsigned nodes_found;
-
-   BUILD_BUG_ON(MAX_NUMNODES >= NUMA_NO_NODE);
-
-   if (pxm < ARRAY_SIZE(pxm2node)) {
-   if (node_found(pxm, pxm))
-   return pxm2node[pxm].node;
-
-   /* Try to maintain indexing of pxm2node by pxm */
-   if (pxm2node[pxm].node == NUMA_NO_NODE) {
-   idx = pxm;
-   goto finish;
-   }
-   }
-
-   for (idx = 0; idx < ARRAY_SIZE(pxm2node); idx++)
-   if (pxm2node[idx].node == NUMA_NO_NODE)
-   goto finish;
-
-   if (!warned) {
-   printk(KERN_WARNING "SRAT: Too many proximity domains (%#x)\n",
-  pxm);
-   warned = 1;
-   }
-
-   return NUMA_NO_NODE;
-
- finish:
-   node = nodes_found++;
-   if (node >= MAX_NUMNODES)
-   return NUMA_NO_NODE;
-   pxm2node[idx].pxm = pxm;
-   pxm2node[idx].node = node;
-
-   return node;
-}
-
 static __init void bad_srat(void)
 {
int i;
@@ -115,48 +44,6 @@ static __init void bad_srat(void)
mem_hotplug = 0;
 }
 
-/*
- * A lot of BIOS fill in 10 (= no distance) everywhere. This 

[Xen-devel] [RFC PATCH v1 09/21] ARM: NUMA: Add CPU NUMA support

[vijay . kilari]

From: Vijaya Kumar K 

For each cpu, update cpu_to_node[] with node id from
the MPIDR registers. Also, initialize cpu_to_node[]
with node 0.

Add macros to access cpu_to_node[] information.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/numa.c| 25 +
 xen/arch/arm/setup.c   |  2 ++
 xen/arch/arm/smpboot.c |  3 +++
 xen/include/asm-arm/numa.h | 15 +++
 4 files changed, 45 insertions(+)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 11d100b..d4dbad4 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -23,9 +23,23 @@
 #include 
 #include 
 #include 
+#include 
 
 int _node_distance[MAX_NUMNODES * 2];
 int *node_distance;
+extern nodemask_t numa_nodes_parsed;
+
+void __init numa_set_cpu_node(int cpu, unsigned long hwid)
+{
+unsigned node;
+
+node = hwid >> 16 & 0xf;
+if ( !node_isset(node, numa_nodes_parsed) || node == MAX_NUMNODES )
+node = 0;
+
+numa_set_node(cpu, node);
+numa_add_cpu(cpu);
+}
 
 u8 __node_distance(nodeid_t a, nodeid_t b)
 {
@@ -37,6 +51,17 @@ u8 __node_distance(nodeid_t a, nodeid_t b)
 
 EXPORT_SYMBOL(__node_distance);
 
+/*
+ * Setup early cpu_to_node.
+ */
+void __init init_cpu_to_node(void)
+{
+int i;
+
+for ( i = 0; i < nr_cpu_ids; i++ )
+numa_set_node(i, 0);
+}
+
 int __init numa_init(void)
 {
 int i, ret = 0;
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index b6618ca..5612ba6 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -749,6 +749,8 @@ void __init start_xen(unsigned long boot_phys_offset,
xen_paddr, xen_paddr + xen_bootmodule->size);
 xen_bootmodule->start = xen_paddr;
 
+init_cpu_to_node();
+
 setup_mm(fdt_paddr, fdt_size);
 
 /* Parse the ACPI tables for possible boot-time configuration */
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 32e8722..3667d4b 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -313,6 +314,8 @@ void start_secondary(unsigned long boot_phys_offset,
  */
 smp_wmb();
 
+numa_set_cpu_node(cpuid, hwid);
+
 /* Now report this CPU is up */
 cpumask_set_cpu(cpuid, _online_map);
 
diff --git a/xen/include/asm-arm/numa.h b/xen/include/asm-arm/numa.h
index b8857e2..33a9e53 100644
--- a/xen/include/asm-arm/numa.h
+++ b/xen/include/asm-arm/numa.h
@@ -2,16 +2,26 @@
 #define __ARCH_ARM_NUMA_H
 
 #include 
+#include 
 
 typedef u8 nodeid_t;
 
 #define NODES_SHIFT 2
 
 #ifdef CONFIG_NUMA
+
+extern cpumask_t node_to_cpumask[];
+extern nodeid_t  cpu_to_node[NR_CPUS];
+#define cpu_to_node(cpu) (cpu_to_node[cpu])
+#define parent_node(node)(node)
+#define node_to_first_cpu(node)  (__ffs(node_to_cpumask[node]))
+#define node_to_cpumask(node)(node_to_cpumask[node])
+
 int arch_numa_setup(char *opt);
 int __init numa_init(void);
 int __init dt_numa_init(void);
 u8 __node_distance(nodeid_t a, nodeid_t b);
+void __init numa_set_cpu_node(int cpu, unsigned long hwid);
 #else
 static inline int arch_numa_setup(char *opt)
 {
@@ -28,6 +38,11 @@ static inline int __init dt_numa_init(void)
 return -EINVAL;
 }
 
+static inline void __init numa_set_cpu_node(int cpu, unsigned long hwid)
+{
+return;
+}
+
 /* Fake one node for now. See also node_online_map. */
 #define cpu_to_node(cpu) 0
 #define node_to_cpumask(node)   (cpu_online_map)
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 10/21] ARM: NUMA: Add memory NUMA support

[vijay . kilari]

From: Vijaya Kumar K 

For all banks in bootinfo.mem, update nodes[] with
corresponding nodeid and register these nodes by
calling setup_node_bootmem().
compute memnode_shift and initialize memnodemap[] to fetch
nodeid for a given physical address.

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/numa.c| 90 ++
 xen/common/numa.c  | 14 
 xen/include/xen/numa.h |  1 +
 3 files changed, 105 insertions(+)

diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index d4dbad4..aa34c82 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -24,10 +24,15 @@
 #include 
 #include 
 #include 
+#include 
 
 int _node_distance[MAX_NUMNODES * 2];
 int *node_distance;
 extern nodemask_t numa_nodes_parsed;
+extern struct node nodes[MAX_NUMNODES] __initdata;
+extern int num_node_memblks;
+extern struct node node_memblk_range[NR_NODE_MEMBLKS];
+extern nodeid_t memblk_nodeid[NR_NODE_MEMBLKS];
 
 void __init numa_set_cpu_node(int cpu, unsigned long hwid)
 {
@@ -51,6 +56,88 @@ u8 __node_distance(nodeid_t a, nodeid_t b)
 
 EXPORT_SYMBOL(__node_distance);
 
+static int __init numa_mem_init(void)
+{
+nodemask_t memory_nodes_parsed;
+int bank, nodeid;
+struct node *nd;
+paddr_t start, size, end;
+
+nodes_clear(memory_nodes_parsed);
+for ( bank = 0 ; bank < bootinfo.mem.nr_banks; bank++ )
+{
+start = bootinfo.mem.bank[bank].start;
+size = bootinfo.mem.bank[bank].size;
+end = start + size;
+
+nodeid = get_numa_node(start, end);
+if ( nodeid == -EINVAL || nodeid > MAX_NUMNODES )
+{
+printk(XENLOG_WARNING
+   "NUMA: node for mem bank start 0x%lx - 0x%lx not found\n",
+   start, end);
+
+return -EINVAL;
+}
+
+nd = [nodeid];
+if ( !node_test_and_set(nodeid, memory_nodes_parsed) )
+{
+nd->start = start;
+nd->end = end;
+}
+else
+{
+if ( start < nd->start )
+nd->start = start;
+if ( nd->end < end )
+nd->end = end;
+}
+}
+
+return 0;
+}
+
+/* Use the information discovered above to actually set up the nodes. */
+static int __init numa_scan_mem_nodes(void)
+{
+int i;
+
+memnode_shift = compute_hash_shift(node_memblk_range, num_node_memblks,
+   memblk_nodeid);
+if ( memnode_shift < 0 )
+{
+printk(XENLOG_WARNING "No NUMA hash found.\n");
+memnode_shift = 0;
+}
+
+for_each_node_mask(i, numa_nodes_parsed)
+{
+u64 size = node_memblk_range[i].end - node_memblk_range[i].start;
+
+if ( size == 0 )
+printk(XENLOG_WARNING "NUMA: Node %u has no memory. \n", i);
+
+printk(XENLOG_INFO
+   "NUMA: NODE[%d]: Start 0x%lx End 0x%lx\n",
+   i, nodes[i].start, nodes[i].end);
+setup_node_bootmem(i, nodes[i].start, nodes[i].end);
+}
+
+return 0;
+}
+
+static int __init numa_initmem_init(void)
+{
+if ( !numa_mem_init() )
+{
+if ( !numa_scan_mem_nodes() )
+return 0;
+}
+
+return -EINVAL;
+}
+
 /*
  * Setup early cpu_to_node.
  */
@@ -74,6 +161,9 @@ int __init numa_init(void)
 
 ret = dt_numa_init();
 
+if ( !ret )
+ret = numa_initmem_init();
+
 no_numa:
 return ret;
 }
diff --git a/xen/common/numa.c b/xen/common/numa.c
index 62c76af..2f5266a 100644
--- a/xen/common/numa.c
+++ b/xen/common/numa.c
@@ -63,6 +63,20 @@ void __init numa_add_memblk(nodeid_t nodeid, u64 start, u64 
size)
 num_node_memblks++;
 }
 
+int __init get_numa_node(u64 start, u64 end)
+{
+int i;
+
+for ( i = 0; i < num_node_memblks; i++ )
+{
+if ( start >= node_memblk_range[i].start &&
+ end <= node_memblk_range[i].end )
+return memblk_nodeid[i];
+}
+
+return -EINVAL;
+}
+
 int valid_numa_range(u64 start, u64 end, nodeid_t node)
 {
 #ifdef CONFIG_NUMA
diff --git a/xen/include/xen/numa.h b/xen/include/xen/numa.h
index 9392a89..4f04ab4 100644
--- a/xen/include/xen/numa.h
+++ b/xen/include/xen/numa.h
@@ -68,6 +68,7 @@ static inline __attribute__((pure)) nodeid_t 
phys_to_nid(paddr_t addr)
 #endif /* CONFIG_NUMA */
 
 extern void numa_add_memblk(nodeid_t nodeid, u64 start, u64 size);
+extern int get_numa_node(u64 start, u64 end);
 extern int valid_numa_range(u64 start, u64 end, nodeid_t node);
 extern int conflicting_memblks(u64 start, u64 end);
 extern void cutoff_node(int i, u64 start, u64 end);
-- 
2.7.4


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

[Xen-devel] [RFC PATCH v1 06/21] ARM: NUMA: Parse CPU NUMA information

[vijay . kilari]

From: Vijaya Kumar K 

Parse CPU node and fetch numa-node-id information.
For each node-id found, update nodemask_t mask.

Call numa_init() from setup_mm() with start and end
pfn of the complete ram..

Signed-off-by: Vijaya Kumar K 
---
 xen/arch/arm/Makefile |  1 +
 xen/arch/arm/bootfdt.c|  8 ++---
 xen/arch/arm/dt_numa.c| 72 +++
 xen/arch/arm/numa.c   | 14 +
 xen/arch/arm/setup.c  |  3 ++
 xen/include/asm-arm/numa.h| 14 +
 xen/include/xen/device_tree.h |  4 +++
 7 files changed, 112 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index b5d7a19..7694485 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -50,6 +50,7 @@ obj-y += vtimer.o
 obj-y += vpsci.o
 obj-y += vuart.o
 obj-$(CONFIG_NUMA) += numa.o
+obj-$(CONFIG_NUMA) += dt_numa.o
 
 #obj-bin-y += o
 
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 979f675..d1122d8 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -17,8 +17,8 @@
 #include 
 #include 
 
-static bool_t __init device_tree_node_matches(const void *fdt, int node,
-  const char *match)
+bool_t __init device_tree_node_matches(const void *fdt, int node,
+   const char *match)
 {
 const char *name;
 size_t match_len;
@@ -63,8 +63,8 @@ static void __init device_tree_get_reg(const __be32 **cell, 
u32 address_cells,
 *size = dt_next_cell(size_cells, cell);
 }
 
-static u32 __init device_tree_get_u32(const void *fdt, int node,
-  const char *prop_name, u32 dflt)
+u32 __init device_tree_get_u32(const void *fdt, int node,
+   const char *prop_name, u32 dflt)
 {
 const struct fdt_property *prop;
 
diff --git a/xen/arch/arm/dt_numa.c b/xen/arch/arm/dt_numa.c
new file mode 100644
index 000..4b94c36
--- /dev/null
+++ b/xen/arch/arm/dt_numa.c
@@ -0,0 +1,72 @@
+/*
+ * OF NUMA Parsing support.
+ *
+ * Copyright (C) 2015 - 2016 Cavium Inc.
+ *
+ * Some code extracts are taken from linux drivers/of/of_numa.c
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+nodemask_t numa_nodes_parsed;
+
+/*
+ * Even though we connect cpus to numa domains later in SMP
+ * init, we need to know the node ids now for all cpus.
+*/
+static int __init dt_numa_process_cpu_node(const void *fdt, int node,
+   const char *name,
+   u32 address_cells, u32 size_cells)
+{
+u32 nid;
+
+nid = device_tree_get_u32(fdt, node, "numa-node-id", MAX_NUMNODES);
+
+if ( nid >= MAX_NUMNODES )
+printk(XENLOG_WARNING "NUMA: Node id %u exceeds maximum value\n", nid);
+else
+node_set(nid, numa_nodes_parsed);
+
+return 0;
+}
+
+static int __init dt_numa_scan_cpu_node(const void *fdt, int node,
+const char *name, int depth,
+u32 address_cells, u32 size_cells,
+void *data)
+
+{
+if ( device_tree_node_matches(fdt, node, "cpu") )
+return dt_numa_process_cpu_node(fdt, node, name, address_cells,
+size_cells);
+
+return 0;
+}
+
+int __init dt_numa_init(void)
+{
+int ret;
+
+nodes_clear(numa_nodes_parsed);
+ret = device_tree_for_each_node((void *)device_tree_flattened,
+dt_numa_scan_cpu_node, NULL);
+return ret;
+}
diff --git a/xen/arch/arm/numa.c b/xen/arch/arm/numa.c
index 59d09c7..9a7f0bb 100644
--- a/xen/arch/arm/numa.c
+++ b/xen/arch/arm/numa.c
@@ -21,6 +21,20 @@
 #include 
 #include 
 #include 
+#include 
+
+int __init numa_init(void)
+{
+int ret = 0;
+
+if ( numa_off )
+goto no_numa;
+
+ret = dt_numa_init();
+
+no_numa:
+return ret;
+}
 
 int __init arch_numa_setup(char *opt)
 {
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 049e449..b6618ca 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -753,6 +754,8 @@ void __init start_xen(unsigned long