[Xen-devel] [ovmf baseline-only test] 75014: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75014 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75014/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75013
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75013

version targeted for testing:
 ovmf 07eba7069d4c23e9b15caa1e729682a88ddf4ada
baseline version:
 ovmf 4a723ed258367471eac8b4ae32558f09ef65672e

Last test of basis75013  2018-07-26 17:20:09 Z0 days
Testing same since75014  2018-07-27 05:58:45 Z0 days1 attempts


People who touched revisions under test:
  Thomas Palmer 
  Vladimir Olovyannikiov 
  Vladimir Olovyannikov 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


commit 07eba7069d4c23e9b15caa1e729682a88ddf4ada
Author: Thomas Palmer 
Date:   Tue Jul 3 23:32:53 2018 +0800

MdeModulePkg/PciBusDxe: Fix small memory leak in FreePciDevice

When cleaning the PciIoDevice, also free the BusNumberRange

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Star Zeng 

commit b5bd3ed64898db1088a9468446a0d2d0dc7185e8
Author: Vladimir Olovyannikov 
Date:   Thu Jul 26 03:47:49 2018 +0800

MdeModulePkg FvSimpleFileSystemDxe: Fix memory leak in Read function

FvSimpleFileSystem on read always allocates a FileBuffer, and never frees
it. This causes memory leaks. It is especially bad for reading scripts
line-by-line. In some cases memory leak can exceed 1GB.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vladimir Olovyannikiov 
Reviewed-by: Star Zeng 

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

Re: [Xen-devel] Xen 4.12 release planning

[Juergen Gross]

On 27/07/18 00:13, Stefano Stabellini wrote:
> On Wed, 25 Jul 2018, Juergen Gross wrote:
>> Its time to plan the Xen 4.12 release dates.
>>
>> There have been concerns with the schedule of 6 months between releases,
>> as this scheme is leading to too many supported versions of Xen at a
>> time. The needed resources to backport bug fixes and security fixes as
>> well as doing the tests for all those releases are a limiting factor to
>> push out the current main release as well as point releases on time.
>>
>> After some discussions at the Xen developer summit, on xen-devel and
>> between the committers a slightly longer release cycle of 8 or 9 months
>> was suggested.
>>
>> With 18 months of full support and 36 months of security support the
>> number of concurrent supported releases will be the same with either 8
>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>> Having only 3 possible times in the year for a release will make it
>> easier to avoid major holiday seasons.
>>
>> In case there is no objection I'm planning Xen 4.12 with:
>>
>> * Last posting date: December 14th, 2018
>> * Hard code freeze: January 11th, 2019
>> * Release: March 7th, 2019
>>
>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>> July 2020.
> 
> Given the holdidays season (it is not just Julien going on vacation but
> pretty much everybody), wouldn't it be better to move the hard code
> freeze by a couple of weeks? For instance Jan 25th? We can still keep
> the release date as Mar 7th, there should be still enough time?

I don't think planning with a 6 week freeze period is a good idea. The
last releases took longer than 2 months.

We could slip the complete release by 2 weeks, of course. In this case
I'd move the last posting date to January. So something like:

* Last posting date: January 11th, 2019
* Hard code freeze: January 25th, 2019
* Release: March 21st, 2019

Risks for that schedule are:
- last posting date short after holiday season - is that really a
  problem?
- Chinese new year rather soon after start of freeze period
- planned release date rather close to eastern

Opinions?


Juergen

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

[Xen-devel] [qemu-upstream-4.11-testing test] 125575: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125508 pass in 
125575
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail in 125508 pass in 
125575
 test-amd64-amd64-xl-pvhv2-amd 18 guest-localmigrate/x10fail pass in 125508

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu20c76f9a5fbf16d58c6add2ace2ff0fabd785926
baseline version:
 qemuu43139135a8938de44f66333831d3a8655d07663a

Last test of basis   124797  2018-06-28 16:27:31 Z   28 days
Testing same since   125273  2018-07-17 11:38:59 Z9 days7 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alexandro Sanchez Bach 
  Anthony PERARD 
  Brijesh Singh 
  Bruce Rogers 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  David Gibson 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Geert Uytterhoeven 
  Gerd Hoffmann 
  Greg Kurz 
  Halil Pasic 
  Henry Wertz 
  Jack Schwartz 
  Jan Kiszka 
  Jason Andryuk 
  Jason Wang 
  Jeff Cody 
  Jintack Lim 
  John Snow 
  John Thomson 
  Kevin Wolf 
  KONRAD Frederic 
  Konrad Rzeszutek Wilk 
  Laszlo Ersek 
  Laurent Vivier 
  Laurent Vivier 
  linzh

Re: [Xen-devel] [xen-4.9-testing test] 125570: regressions - FAIL

[Jan Beulich]

>>> On 27.07.18 at 02:01,  wrote:
> flight 125570 xen-4.9-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/125570/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>[...]
>  test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 
> 124248

This is a problem: I think we had settled on the test being unreliable in
the first place long ago, due to it being undefined what the ACPI power
button would trigger inside the guest. Looking at the history of this test
on this branch, I see that it did succeed on exactly 3 flights (for
comparison, it has never succeeded on master, 4.11, or 4.10). I don't
think this should be used as a justification to prevent a push, but I can
see that setting up suitable rules/heuristics might be difficult. Force
push?

Jan



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

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

[Jan Beulich]

>>> On 27.07.18 at 04:29,  wrote:
> flight 125573 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/125573/ 
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 
> 125178
>  test-amd64-amd64-libvirt-xsm 10 debian-install   fail REGR. vs. 
> 125178
>  test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 
> 125178
>  test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 
> 125178

All four again ran on rimava0. In order to have a realistic chance
of getting a push over the weekend, may I suggest the machine be
taken out of the pool for closer inspection?

Jan



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

Re: [Xen-devel] [PATCH v3] firmware/shim : filter output files during Xen tree setup

[Jan Beulich]

>>> On 26.07.18 at 23:16,  wrote:
> Exclude named output files from the Xen tree setup.
> 
> The linkfarm.stamp content will differ between top level "make"
> and "make install" invocations, due to the introduction of these
> output files that are produced during the "make" build.
> 
> Filter these out to prevent an unnecessary rebuild of the shim
> during "make install", after "make" within a fresh source tree.
> 
> Excluded from consideration with this change: differences in stamp
> content when performing incremental builds in an existing tree.

I don't understand this (as well as you most recent remark on the
v2 thread): The "make install" invocation _is_ an incremental
rebuild. Hence I don't understand how excluding some but not all
generated files helps. But I'm not going to exclude that this is
simply because I don't understand well enough the logic in
xen-dir/Makefile when to trigger a rebuild.

> Signed-off-by: Christopher Clark 
> ---
> Changes in v3: added '.xen.efi.*' '.xen-syms.*' to the exclude list.
> 
> Tested with: Xen 4.10.1, 4.11.0 and staging,
> Yocto poky, OpenEmbedded meta-openembedded, meta-virtualization
> with binutils 2.3.0 with x86_64-pep target enabled.

I sincerely hope you mean 2.30 or some such (halfway recent) here.

Jan



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

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

[Wei Liu]

On Fri, Jul 27, 2018 at 02:26:22AM -0600, Jan Beulich wrote:
> >>> On 27.07.18 at 04:29,  wrote:
> > flight 125573 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/125573/ 
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 
> > 125178
> >  test-amd64-amd64-libvirt-xsm 10 debian-install   fail REGR. vs. 
> > 125178
> >  test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 
> > 125178
> >  test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 
> > 125178
> 
> All four again ran on rimava0. In order to have a realistic chance
> of getting a push over the weekend, may I suggest the machine be
> taken out of the pool for closer inspection?

I have taken it out of the pool.

Wei.

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

[Xen-devel] [distros-debian-jessie test] 75015: tolerable FAIL

[Platform Team regression test user]

flight 75015 distros-debian-jessie real [real]
http://osstest.xensource.com/osstest/logs/75015/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 10 debian-di-install fail like 
74991

baseline version:
 flight   74991

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub fail
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


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

Re: [Xen-devel] PVH dom0 creation fails - the system freezes

[Roger Pau Monné]

On Fri, Jul 27, 2018 at 08:48:32AM +, Bercaru, Gabriel wrote:
> I tried the patch and it fixes the unusable USB devices problem.
> However, I captured the boot messages and the "IOMMU mapping failed" printk
> seems to have been executed on each iteration of the loop.
> 
> I attached a small section of the boot log. As I said, the warning log was 
> displayed
> many more times, I removed a lot of them to keep the attached file short.

The patch is still a WIP, but it's good to know it solves your USB
issues :).

I think you are likely missing patch:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=173c7803592065d27bf2e60d50e08e197a0efa83

Can you try to update to latest staging or apply the patch and try
again?

I think if you have this patch applied the number of errors reported
by the IOMMU initialization should go down.

Thank, Roger.

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

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

[Jan Beulich]

>>> On 19.07.18 at 13:44,  wrote:
> It turns out that Xen has never enforced that a domain remain within the
> xstate features advertised in CPUID.
> 
> The check of new_bv against xfeature_mask ensures that a domain stays within
> the set of features that Xen has enabled in hardware (and therefore isn't a
> security problem), but this does means that attempts to level a guest for
> migration safety might not be effective if the guest ignores CPUID.
> 
> Check the CPUID policy in validate_xstate() (for incoming migration) and in
> handle_xsetbv() (for guest XSETBV instructions).  This subsumes the PKRU check
> for PV guests in handle_xsetbv() (and also demonstrates that I should have
> spotted this problem while reviewing c/s fbf9971241f).
> 
> For migration, this is correct despite the current (mis)ordering of data
> because d->arch.cpuid is the applicable max policy.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> 
> v2:
>  * Leave valid_xcr0() alone and duplicate the checks in validate_xstate() and
>handle_xsetbv().
> v3:
>  * Note the migration safety in the commit message.
> 
> Backporting notes: This is safe in the restore case, but only back as far as
> the introduction of cpuid_policy infrastructure.  Before then, a restore
> boolean needs to be plumbed down as well, and used to select between the
> hardware maximum value and calls to {hvm,pv}_cpuid() to find the
> toolstack-chosen level.

While trying to determine the exact boundary here (looks like it's
between 4.7 and 4.8, in which case the remark is relevant only for
people maintaining releases no longer fully XenProject maintained)
I've become confused by the reference to {hvm,pv}_cpuid() above:
Is this simply an ordering concern? If so, the bounding the two
functions do would need to be replicated (or better shared) I think,
if the sole reason for otherwise using the HW maximum is that
d->arch.cpuids[] isn't populated yet.

Jan



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

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

[Andrew Cooper]

On 27/07/18 10:28, Jan Beulich wrote:
 On 19.07.18 at 13:44,  wrote:
>> It turns out that Xen has never enforced that a domain remain within the
>> xstate features advertised in CPUID.
>>
>> The check of new_bv against xfeature_mask ensures that a domain stays within
>> the set of features that Xen has enabled in hardware (and therefore isn't a
>> security problem), but this does means that attempts to level a guest for
>> migration safety might not be effective if the guest ignores CPUID.
>>
>> Check the CPUID policy in validate_xstate() (for incoming migration) and in
>> handle_xsetbv() (for guest XSETBV instructions).  This subsumes the PKRU 
>> check
>> for PV guests in handle_xsetbv() (and also demonstrates that I should have
>> spotted this problem while reviewing c/s fbf9971241f).
>>
>> For migration, this is correct despite the current (mis)ordering of data
>> because d->arch.cpuid is the applicable max policy.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>>
>> v2:
>>  * Leave valid_xcr0() alone and duplicate the checks in validate_xstate() and
>>handle_xsetbv().
>> v3:
>>  * Note the migration safety in the commit message.
>>
>> Backporting notes: This is safe in the restore case, but only back as far as
>> the introduction of cpuid_policy infrastructure.  Before then, a restore
>> boolean needs to be plumbed down as well, and used to select between the
>> hardware maximum value and calls to {hvm,pv}_cpuid() to find the
>> toolstack-chosen level.
> While trying to determine the exact boundary here (looks like it's
> between 4.7 and 4.8, in which case the remark is relevant only for
> people maintaining releases no longer fully XenProject maintained)
> I've become confused by the reference to {hvm,pv}_cpuid() above:
> Is this simply an ordering concern? If so, the bounding the two
> functions do would need to be replicated (or better shared) I think,
> if the sole reason for otherwise using the HW maximum is that
> d->arch.cpuids[] isn't populated yet.

Looking over things, 4.9 is fine because that was when cpuid_policy was
introduced.

Before 4.9, the calls to {hvm,pv}_cpuid() are needed to because the
information can't be read directly out of d->arch.cpuids[].  The restore
boolean is needed because this array will be empty at the time it is
accessed on the restore path.

~Andrew

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

[Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

[Xiao Liang]

When loading module manually, after call xenbus_switch_state to initializes
the state of the netfront device, the driver state did not change so fast
that may lead no dev created in latest kernel. This patch adds wait to make
sure xenbus knows the driver is not in closed/unknown state.

Current state:
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe  xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available

With the patch installed.
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes

Signed-off-by: Xiao Liang 
---
 drivers/net/xen-netfront.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index a57daecf1d57..2d8812dd1534 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -87,6 +87,7 @@ struct netfront_cb {
 /* IRQ name is queue name with "-tx" or "-rx" appended */
 #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
 
+static DECLARE_WAIT_QUEUE_HEAD(module_load_q);
 static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
 
 struct netfront_stats {
@@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_dev(struct 
xenbus_device *dev)
netif_carrier_off(netdev);
 
xenbus_switch_state(dev, XenbusStateInitialising);
+   wait_event(module_load_q,
+  xenbus_read_driver_state(dev->otherend) !=
+  XenbusStateClosed &&
+  xenbus_read_driver_state(dev->otherend) !=
+  XenbusStateUnknown);
return netdev;
 
  exit:
-- 
2.17.1


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

[Xen-devel] [xen-4.8-testing test] 125582: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt  broken  in 125165
 build-armhf-libvirt  5 host-build-prep fail in 125165 REGR. vs. 125065
 build-i386-pvops  6 kernel-build   fail in 125512 REGR. vs. 125065

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd   6 xen-install  fail in 125165 pass in 125582
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail in 125165 pass in 125582
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail in 
125218 pass in 125582
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 125512 pass in 125582
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail pass in 125165
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail pass 
in 125218
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install   fail pass in 125365
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail pass 
in 125512

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 125165 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 125165 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 1 build-check(1) blocked in 
125512 n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked in 
125512 n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1) blocked in 125512 n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 125512 n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
125512 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-pair  1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
in 125512 n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked in 125512 n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1) blocked in 125512 n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1) blocked in 125512 n/a
 test-amd64-i386-xl1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)blocked in 125512 n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 125512 n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
125512 n/a
 test-xtf-amd64-amd64-2 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125218 like 
125040
 test-xtf-amd64-amd64-4 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125365 like 
124942
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125365 like 
125040
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 125365 like 125040
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125365 like 
125065
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125512 like 
125040
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 125512 like 
125065
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
124996
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
124996
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125065
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125065
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125065
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail l

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f413763b6b8f2798595d468cf868ae5985d3eabc
baseline version:
 ovmf 07eba7069d4c23e9b15caa1e729682a88ddf4ada

Last test of basis   125606  2018-07-27 01:10:42 Z0 days
Testing same since   125613  2018-07-27 05:46:36 Z0 days1 attempts


People who touched revisions under test:
  Yunhua Feng 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   07eba7069d..f413763b6b  f413763b6b8f2798595d468cf868ae5985d3eabc -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

[Jan Beulich]

>>> On 27.07.18 at 11:37,  wrote:
> On 27/07/18 10:28, Jan Beulich wrote:
> On 19.07.18 at 13:44,  wrote:
>>> It turns out that Xen has never enforced that a domain remain within the
>>> xstate features advertised in CPUID.
>>>
>>> The check of new_bv against xfeature_mask ensures that a domain stays within
>>> the set of features that Xen has enabled in hardware (and therefore isn't a
>>> security problem), but this does means that attempts to level a guest for
>>> migration safety might not be effective if the guest ignores CPUID.
>>>
>>> Check the CPUID policy in validate_xstate() (for incoming migration) and in
>>> handle_xsetbv() (for guest XSETBV instructions).  This subsumes the PKRU 
> check
>>> for PV guests in handle_xsetbv() (and also demonstrates that I should have
>>> spotted this problem while reviewing c/s fbf9971241f).
>>>
>>> For migration, this is correct despite the current (mis)ordering of data
>>> because d->arch.cpuid is the applicable max policy.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Jan Beulich 
>>>
>>> v2:
>>>  * Leave valid_xcr0() alone and duplicate the checks in validate_xstate() 
> and
>>>handle_xsetbv().
>>> v3:
>>>  * Note the migration safety in the commit message.
>>>
>>> Backporting notes: This is safe in the restore case, but only back as far as
>>> the introduction of cpuid_policy infrastructure.  Before then, a restore
>>> boolean needs to be plumbed down as well, and used to select between the
>>> hardware maximum value and calls to {hvm,pv}_cpuid() to find the
>>> toolstack-chosen level.
>> While trying to determine the exact boundary here (looks like it's
>> between 4.7 and 4.8, in which case the remark is relevant only for
>> people maintaining releases no longer fully XenProject maintained)
>> I've become confused by the reference to {hvm,pv}_cpuid() above:
>> Is this simply an ordering concern? If so, the bounding the two
>> functions do would need to be replicated (or better shared) I think,
>> if the sole reason for otherwise using the HW maximum is that
>> d->arch.cpuids[] isn't populated yet.
> 
> Looking over things, 4.9 is fine because that was when cpuid_policy was
> introduced.
> 
> Before 4.9, the calls to {hvm,pv}_cpuid() are needed to because the
> information can't be read directly out of d->arch.cpuids[].  The restore
> boolean is needed because this array will be empty at the time it is
> accessed on the restore path.

If at restore time we were to not obey to the restrictions {hvm,pv}_cpuid()
enforce, there's imo no point doing any checks at all - the check against
the HW maximum exists already anyway.

Jan



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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Andrii Anisov]

Hello Stefano,


On 27.07.18 01:46, Stefano Stabellini wrote:

On Tue, 24 Jul 2018, Andrii Anisov wrote:

On 07.07.18 02:13, Stefano Stabellini wrote:

Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL. They enable the required options for their hardware
platform. ALL enables all available platforms and it's the default. It
doesn't automatically select any of the related drivers, otherwise they
cannot be disabled. ALL is implemented by selecting hidden options
corresponding to QEMU, MPSOC and RCAR3.

In the case of the MPSOC that has a platform file under
arch/arm/platforms/, build the file if MPSOC.

Signed-off-by: Stefano Stabellini 
CC: artem_myga...@epam.com
CC: volodymyr_babc...@epam.com

---
Changes in v5:
- turn platform support into a choice
- add ALL

Changes in v4:
- fix GICv3/GICV3
- default y to all options
- build xilinx-zynqmp if MPSOC
---
   xen/arch/arm/Kconfig|  2 ++
   xen/arch/arm/platforms/Kconfig  | 55
+
   xen/arch/arm/platforms/Makefile |  2 +-
   3 files changed, 58 insertions(+), 1 deletion(-)
   create mode 100644 xen/arch/arm/platforms/Kconfig

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 2b87111..75cacfb 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
   config ARM32_HARDEN_BRANCH_PREDICTOR
   def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
   +source "arch/arm/platforms/Kconfig"
+
   source "common/Kconfig"
 source "drivers/Kconfig"
diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
new file mode 100644
index 000..07c5930
--- /dev/null
+++ b/xen/arch/arm/platforms/Kconfig
@@ -0,0 +1,55 @@
+choice
+   prompt "Platform Support"
+   default ALL
+   ---help---
+   Choose which hardware platform to enable in Xen.
+
+   If unsure, choose ALL.
+
+config ALL

I would suggest to separate it into ALL_ARM32 and ALL_ARM64. Then, in a
makefile use them for platforms instead of raw ARM32 and ARM64. This would
make such change really useful: disabling ALL_x will drop all odd platform
code.

Hi Andrii,

I don't understand the suggestion: ARM32 platforms cannot be enabled on
ARM64 and vice versa.

Indeed.


  So basically it is as if you always get only
ALL_ARM32 or ALL_ARM64 depending on your target architecture.

Am I missing something?
With this patch, deselecting "config ALL" does not remove all platform 
code from the build. It is because build of the most of that code 
depends directly on ARMxx.
In order to get a possibility to drop unneeded platform code, the 
platform code should be dependent on "config ALL". But here you do not 
want to mix 32bit and 64bit platforms, so you would need "config ALL_32" 
and "config ALL_64".
For sure, written above is meaningful only for the case if someone needs 
the possibility to drop odd platform code from the build.

+   bool "All Platforms"
+   select MPSOC_PLATFORM
+   select QEMU_PLATFORM
+   select RCAR3_PLATFORM
+   ---help---
+   Enable support for all available hardware platforms. It doesn't
+   automatically select any of the related drivers.
+
+config QEMU
+   bool "QEMU aarch virt machine support"
+   depends on ARM_64
+   select QEMU_PLATFORM
+   select GICV3
+   select HAS_PL011
+   ---help---
+   Enable all the required drivers for QEMU aarch64 virt emulated
+   machine.
+
+config RCAR3
+   bool "Renesas RCar3 support"
+   depends on ARM_64
+   select RCAR3_PLATFORM
+   select HAS_SCIF
+   ---help---
+   Enable all the required drivers for Renesas RCar3
+
+config MPSOC
+   bool "Xilinx Ultrascale+ MPSoC support"
+   depends on ARM_64
+   select MPSOC_PLATFORM
+   select HAS_CADENCE_UART
+   select ARM_SMMU
+   ---help---
+   Enable all the required drivers for Xilinx Ultrascale+ MPSoC
+
+endchoice
+
+config QEMU_PLATFORM
+   bool
+
+config RCAR3_PLATFORM
+   bool
+
+config MPSOC_PLATFORM

Shouldn't MPSOC_PLATFORM be dependent on ARM64?

Yes, and it is, see "config MPSOC" few lines above.
Few lines above, only "config MPSOC" is dependent on ARM64. But 
MPSOC_PLATFORM is selected by "config ALL" at the beginning of the 
patch. And it will be selected for ARM32 as well.



+   bool
+
diff --git a/xen/arch/arm/platforms/Makefile
b/xen/arch/arm/platforms/Makefile
index 80e555c..a79bdb9 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o
   obj-y += sunxi.o
   obj-$(CONFIG_ARM_64) += thunderx.o
   obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o


--

*Andrii Anisov*



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

Re: [Xen-devel] Xen 4.12 release planning

[Lars Kurth]

> On 27 Jul 2018, at 08:51, Juergen Gross  wrote:
> 
> On 27/07/18 00:13, Stefano Stabellini wrote:
>> On Wed, 25 Jul 2018, Juergen Gross wrote:
>>> Its time to plan the Xen 4.12 release dates.
>>> 
>>> There have been concerns with the schedule of 6 months between releases,
>>> as this scheme is leading to too many supported versions of Xen at a
>>> time. The needed resources to backport bug fixes and security fixes as
>>> well as doing the tests for all those releases are a limiting factor to
>>> push out the current main release as well as point releases on time.
>>> 
>>> After some discussions at the Xen developer summit, on xen-devel and
>>> between the committers a slightly longer release cycle of 8 or 9 months
>>> was suggested.
>>> 
>>> With 18 months of full support and 36 months of security support the
>>> number of concurrent supported releases will be the same with either 8
>>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>>> Having only 3 possible times in the year for a release will make it
>>> easier to avoid major holiday seasons.
>>> 
>>> In case there is no objection I'm planning Xen 4.12 with:
>>> 
>>> * Last posting date: December 14th, 2018
>>> * Hard code freeze: January 11th, 2019
>>> * Release: March 7th, 2019
>>> 
>>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>>> July 2020.
>> 
>> Given the holdidays season (it is not just Julien going on vacation but
>> pretty much everybody), wouldn't it be better to move the hard code
>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
>> the release date as Mar 7th, there should be still enough time?
> 
> I don't think planning with a 6 week freeze period is a good idea. The
> last releases took longer than 2 months.
> 
> We could slip the complete release by 2 weeks, of course. In this case
> I'd move the last posting date to January. So something like:
> 
> * Last posting date: January 11th, 2019
> * Hard code freeze: January 25th, 2019
> * Release: March 21st, 2019

Another alternative would be to move the dates backwards rather than forward. 
The 4.12 development window effectively opened 21-06-18, so a last posting data 
and hard code freeze before Xmas should be OK. Then assume that there won't be 
RC's for at last 2 (maybe 3) weeks during the winter holidays. But as long as 
someone is there to keep an eye on OSSTEST and to do a force push and build an 
RC1 before Xmas that may be OK: but it would probably still be OK if RC1 
slipped until just after New Years Eve.

> Risks for that schedule are:
> - last posting date short after holiday season - is that really a
>  problem?
> - Chinese new year rather soon after start of freeze period
> - planned release date rather close to eastern
> 
> Opinions?

With this in mind. The only problem is that there will be Chinese New Year for 
some of the late to middle RCs ... Looking at possible RC dates
RC1: wk Jan 1st 
RC2: wk Jan 8th
RC3: wk Jan 15th
RC4: wk Jan 22nd
RC5: wk Jan 29th
RC6: wk Feb 5th (Chinese New Year)
RC7: wk Feb 12th
RC8: wk Feb 19th

Lars

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

Re: [Xen-devel] [PATCH RFC] tools/kdd: avoid adversarial optimisation hazard

[Wei Liu]

On Thu, Jul 26, 2018 at 01:37:45PM +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH RFC] tools/kdd: avoid adversarial optimisation 
> hazard"):
> > There have been two attempts to fix kdd build with gcc 8.1
> > (437e00fe and 2de2b10b), but building with gcc 8.1 32 bit non-debug
> > build still yields the same error as in 437e00fe.
> > 
> > Ian wrote about adversarial optimisation in [0], one of the key points
> > is that computing an out-of-bounds pointer is UB.
> ...
> > Eliminate that UB by using uintptr_t to avoid the compiler reaching
> > the conclusion that offset <= sizeof(ctrl).
> 
> Since I wrote my complaint, the code has been rearranged so that it
> does not call memcpy if the bounds check fails.  nAt, least what I
> wrote earlier,
> 
>  |  Therefore  ((uint8_t *)&ctrl.c32) + offset
>  |  (which is caclulated unconditionally)
>  |  is within the stack object `ctrl'.   
> 
> is not true of current staging.
> 
> It's still very obscure becaause this test
> 
> if (offset > sizeof ctrl.c32 || offset + len > sizeof ctrl.c32) {
> 
> depends critically on the size of offset, etc.
> 
> Is it not still possible that this test could be fooled ?  Suppose
> offset is 0x.  Then before the test, offset is 0xfd33.

In this case, wouldn't offset > sizeof ctrl.c32 becomes true?

Wei.

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

Re: [Xen-devel] Xen 4.12 release planning

[Juergen Gross]

On 27/07/18 12:32, Lars Kurth wrote:
> 
> 
>> On 27 Jul 2018, at 08:51, Juergen Gross > > wrote:
>>
>> On 27/07/18 00:13, Stefano Stabellini wrote:
>>> On Wed, 25 Jul 2018, Juergen Gross wrote:
 Its time to plan the Xen 4.12 release dates.

 There have been concerns with the schedule of 6 months between releases,
 as this scheme is leading to too many supported versions of Xen at a
 time. The needed resources to backport bug fixes and security fixes as
 well as doing the tests for all those releases are a limiting factor to
 push out the current main release as well as point releases on time.

 After some discussions at the Xen developer summit, on xen-devel and
 between the committers a slightly longer release cycle of 8 or 9 months
 was suggested.

 With 18 months of full support and 36 months of security support the
 number of concurrent supported releases will be the same with either 8
 or 9 months release cycles, so I have chosen an 8 month cycle for now.
 Having only 3 possible times in the year for a release will make it
 easier to avoid major holiday seasons.

 In case there is no objection I'm planning Xen 4.12 with:

 * Last posting date: December 14th, 2018
 * Hard code freeze: January 11th, 2019
 * Release: March 7th, 2019

 Release of Xen 4.13 would then be early November 2019, 4.14 at early
 July 2020.
>>>
>>> Given the holdidays season (it is not just Julien going on vacation but
>>> pretty much everybody), wouldn't it be better to move the hard code
>>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
>>> the release date as Mar 7th, there should be still enough time?
>>
>> I don't think planning with a 6 week freeze period is a good idea. The
>> last releases took longer than 2 months.
>>
>> We could slip the complete release by 2 weeks, of course. In this case
>> I'd move the last posting date to January. So something like:
>>
>> * Last posting date: January 11th, 2019
>> * Hard code freeze: January 25th, 2019
>> * Release: March 21st, 2019
> 
> Another alternative would be to move the dates backwards rather than
> forward. The 4.12 development window effectively opened 21-06-18, so a
> last posting data and hard code freeze before Xmas should be OK. Then
> assume that there won't be RC's for at last 2 (maybe 3) weeks during the
> winter holidays. But as long as someone is there to keep an eye on
> OSSTEST and to do a force push and build an RC1 before Xmas that may be
> OK: but it would probably still be OK if RC1 slipped until just after
> New Years Eve.

You are neglecting that the reason for no RC directly after the freeze
is normally due to bugs. And those need to be found and fixed by
someone. So putting the freeze directly before a holiday season just
makes the freeze longer without any major advantage.


Juergen

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

Re: [Xen-devel] [PATCH v2 18/21] xen/arm: Allow vpl011 to be used by DomU

[Julien Grall]

Hi Stefano,

On 27/07/18 01:10, Stefano Stabellini wrote:

On Tue, 24 Jul 2018, Julien Grall wrote:

On 07/07/18 00:12, Stefano Stabellini wrote:

+VPL011_UNLOCK(d, flags);
+}
+
+static void vpl011_write_data_noring(struct domain *d, uint8_t data)
+{
+unsigned long flags;
+struct vpl011 *vpl011 = &d->arch.vpl011;
+
+VPL011_LOCK(d, flags);
+
+printk("%c", data);
+if (data == '\n')
+printk("DOM%u: ", d->domain_id);


You want to buffer the characters here and only print on newline or when the
buffer is full. Otherwise characters will get mangled with the Xen console
output or other domains output.


I did the implementation, but then when I type characters at the domain
prompt, I don't see them anymore one by one. Only after I press
"enter". That makes the domain console not very usable. Should we keep
it as?


I haven't thought about that case. However, if you don't implement the 
buffer solution, you will get all the domain consoles mangled during 
boot. This is not really nice for debugging. A potential solution is to 
buffer for all the domains but the one that is reading characters.



+
+vpl011->uartris |= TXI;
+vpl011->uartfr &= ~TXFE;
+vpl011_update_interrupt_status(d);
+
+VPL011_UNLOCK(d, flags);
+}
+
+static uint8_t vpl011_read_data_inring(struct domain *d)
+{


I think you can avoid the duplication here by using a macro.


I prefer to avoid MACROS for things like this. I would rather reuse the
existing function for both cases like in v1. Would you be OK to go back
to that?


I would rather keep the duplication over going back to v1.

I may have another way to keep the code common, but let's look at that 
in a latter patch. For now, I will deal with the duplication.


Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d
baseline version:
 xen  f77626453232acec475afdd982319f64de0368e8

Last test of basis   125572  2018-07-25 15:01:29 Z1 days
Testing same since   125617  2018-07-27 09:01:58 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Ian Jackson 
  Juergen Gross 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f776264532..acd00a3033  acd00a303378ce48bd6bbd8a579f1fe2f1b21a7d -> smoke

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

[Xen-devel] [freebsd-master test] 125620: regressions - trouble: blocked/fail

[osstest service owner]

flight 125620 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125620/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-freebsd   7 freebsd-buildfail REGR. vs. 125317

Tests which did not succeed, but are not blocking:
 build-amd64-freebsd-again 1 build-check(1)   blocked  n/a

version targeted for testing:
 freebsd  8a828b24a5b06cd4c742fd8dbe5484970a3485f0
baseline version:
 freebsd  bf65d05707104df94117a293327d797d71a0118d

Last test of basis   125317  2018-07-18 09:19:47 Z9 days
Failing since125467  2018-07-20 09:19:59 Z7 days4 attempts
Testing same since   125620  2018-07-27 09:19:00 Z0 days1 attempts


People who touched revisions under test:
  0mp <0...@freebsd.org>
  alc 
  allanjude 
  andrew 
  asomers 
  avg 
  bde 
  br 
  brd 
  bz 
  cem 
  cperciva 
  cy 
  dab 
  daichi 
  davidcs 
  delphij 
  dim 
  eadler 
  emaste 
  eugen 
  ganbold 
  gavin 
  gjb 
  hselasky 
  ian 
  imp 
  jhb 
  jhibbits 
  jhixson 
  kib 
  leitao 
  lwhsu 
  manu 
  marius 
  markj 
  mav 
  mmacy 
  mmel 
  np 
  oshogbo 
  pkelsey 
  pstef 
  rmacklem 
  royger 
  rpokala 
  rrs 
  sef 
  shurd 
  trasz 
  tuexen 
  uqs 
  woodsb02 
  wulf 
  zleslie 

jobs:
 build-amd64-freebsd-againblocked 
 build-amd64-freebsd  fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Julien Grall]

Hi,

On 27/07/18 11:30, Andrii Anisov wrote:

On 27.07.18 01:46, Stefano Stabellini wrote:

On 07.07.18 02:13, Stefano Stabellini wrote:
Shouldn't MPSOC_PLATFORM be dependent on ARM64?

Yes, and it is, see "config MPSOC" few lines above.
Few lines above, only "config MPSOC" is dependent on ARM64. But 
MPSOC_PLATFORM is selected by "config ALL" at the beginning of the 
patch. And it will be selected for ARM32 as well.


You don't really need to select the platform in ALL. Instead you could 
do something like:


config ALL_64
default (ALL && ARM_64)

config ALL_32
default (ALL && ARM_32)

config MPSOC_PLATFORM
bool
default (ALL_64 || MPSOC)




+    bool
+
diff --git a/xen/arch/arm/platforms/Makefile
b/xen/arch/arm/platforms/Makefile
index 80e555c..a79bdb9 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -8,4 +8,4 @@ obj-$(CONFIG_ARM_64) += seattle.o
   obj-y += sunxi.o
   obj-$(CONFIG_ARM_64) += thunderx.o
   obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o




--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Andrii Anisov]

I would suggest something like:

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 06ba4a4..794f06e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -218,6 +218,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
 config ARM32_HARDEN_BRANCH_PREDICTOR
 def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR

+source "arch/arm/platforms/Kconfig"
+
 source "common/Kconfig"

 source "drivers/Kconfig"
diff --git a/xen/arch/arm/platforms/Kconfig b/xen/arch/arm/platforms/Kconfig
new file mode 100644
index 000..badf17b
--- /dev/null
+++ b/xen/arch/arm/platforms/Kconfig
@@ -0,0 +1,72 @@
+choice
+    prompt "Platform Support"
+    depends on ARM_32
+    default ALL_32
+    ---help---
+    Choose which hardware platform to enable in Xen.
+
+    If unsure, choose ALL.
+
+config ALL_32
+    bool "All Platforms"
+    ---help---
+    Enable support for all available hardware platforms. It doesn't
+    automatically select any of the related drivers.
+
+config NONE_32
+    bool "No Platform support"
+    ---help---
+    Remove all platform code.
+
+endchoice
+
+choice
+    prompt "Platform Support"
+    depends on ARM_64
+    default ALL_64
+    ---help---
+    Choose which hardware platform to enable in Xen.
+
+    If unsure, choose ALL.
+
+config ALL_64
+    bool "All Platforms"
+    select MPSOC_PLATFORM
+    ---help---
+    Enable support for all available hardware platforms. It doesn't
+    automatically select any of the related drivers.
+
+config QEMU
+    bool "QEMU aarch virt machine support"
+    depends on ARM_64
+    select GICV3
+    select HAS_PL011
+    ---help---
+    Enable all the required drivers for QEMU aarch64 virt emulated
+    machine.
+
+config RCAR3
+    bool "Renesas RCar3 support"
+    depends on ARM_64
+    select HAS_SCIF
+    ---help---
+    Enable all the required drivers for Renesas RCar3
+
+config MPSOC
+    bool "Xilinx Ultrascale+ MPSoC support"
+    depends on ARM_64
+    select MPSOC_PLATFORM
+    select HAS_CADENCE_UART
+    select ARM_SMMU
+    ---help---
+    Enable all the required drivers for Xilinx Ultrascale+ MPSoC
+
+config NONE_64
+    bool "No Platform support"
+    ---help---
+    Remove all platform code.
+
+endchoice
+
+config MPSOC_PLATFORM
+    bool
diff --git a/xen/arch/arm/platforms/Makefile 
b/xen/arch/arm/platforms/Makefile

index 80e555c..c8e763e 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -1,11 +1,14 @@
-obj-y += vexpress.o
-obj-$(CONFIG_ARM_32) += brcm.o
-obj-$(CONFIG_ARM_32) += exynos5.o
-obj-$(CONFIG_ARM_32) += midway.o
-obj-$(CONFIG_ARM_32) += omap5.o
-obj-$(CONFIG_ARM_32) += rcar2.o
-obj-$(CONFIG_ARM_64) += seattle.o
-obj-y += sunxi.o
-obj-$(CONFIG_ARM_64) += thunderx.o
-obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_ALL_32) += vexpress.o
+obj-$(CONFIG_ALL_32) += sunxi.o
+obj-$(CONFIG_ALL_32) += brcm.o
+obj-$(CONFIG_ALL_32) += exynos5.o
+obj-$(CONFIG_ALL_32) += midway.o
+obj-$(CONFIG_ALL_32) += omap5.o
+obj-$(CONFIG_ALL_32) += rcar2.o
+
+obj-$(CONFIG_ALL_64) += vexpress.o
+obj-$(CONFIG_ALL_64) += sunxi.o
+obj-$(CONFIG_ALL_64) += seattle.o
+obj-$(CONFIG_ALL_64) += thunderx.o
+obj-$(CONFIG_ALL_64) += xgene-storm.o
+obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o


--

*Andrii Anisov*


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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Julien Grall]

Hi,

On 27/07/18 12:21, Andrii Anisov wrote:

I would suggest something like:

diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 06ba4a4..794f06e 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -218,6 +218,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
  config ARM32_HARDEN_BRANCH_PREDICTOR
  def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR

+source "arch/arm/platforms/Kconfig"
+


There are no need for duplication. You can instead do something like:

config ALL_64
default (ALL && ARM_64)

config ALL_32
default (ALL && ARM_32)

config MPSOC_PLATFORM
bool
default (ALL_64 || MPSOC)

Cheers,


  source "common/Kconfig"

  source "drivers/Kconfig"
diff --git a/xen/arch/arm/platforms/Kconfig 
b/xen/arch/arm/platforms/Kconfig

new file mode 100644
index 000..badf17b
--- /dev/null
+++ b/xen/arch/arm/platforms/Kconfig
@@ -0,0 +1,72 @@
+choice
+    prompt "Platform Support"
+    depends on ARM_32
+    default ALL_32
+    ---help---
+    Choose which hardware platform to enable in Xen.
+
+    If unsure, choose ALL.
+
+config ALL_32
+    bool "All Platforms"
+    ---help---
+    Enable support for all available hardware platforms. It doesn't
+    automatically select any of the related drivers.
+
+config NONE_32
+    bool "No Platform support"
+    ---help---
+    Remove all platform code. > +
+endchoice
+
+choice
+    prompt "Platform Support"
+    depends on ARM_64
+    default ALL_64
+    ---help---
+    Choose which hardware platform to enable in Xen.
+
+    If unsure, choose ALL.
+
+config ALL_64
+    bool "All Platforms"
+    select MPSOC_PLATFORM
+    ---help---
+    Enable support for all available hardware platforms. It doesn't
+    automatically select any of the related drivers.
+
+config QEMU
+    bool "QEMU aarch virt machine support"
+    depends on ARM_64
+    select GICV3
+    select HAS_PL011
+    ---help---
+    Enable all the required drivers for QEMU aarch64 virt emulated
+    machine.
+
+config RCAR3
+    bool "Renesas RCar3 support"
+    depends on ARM_64
+    select HAS_SCIF
+    ---help---
+    Enable all the required drivers for Renesas RCar3
+
+config MPSOC
+    bool "Xilinx Ultrascale+ MPSoC support"
+    depends on ARM_64
+    select MPSOC_PLATFORM
+    select HAS_CADENCE_UART
+    select ARM_SMMU
+    ---help---
+    Enable all the required drivers for Xilinx Ultrascale+ MPSoC
+
+config NONE_64
+    bool "No Platform support"
+    ---help---
+    Remove all platform code.
+
+endchoice
+
+config MPSOC_PLATFORM
+    bool
diff --git a/xen/arch/arm/platforms/Makefile 
b/xen/arch/arm/platforms/Makefile

index 80e555c..c8e763e 100644
--- a/xen/arch/arm/platforms/Makefile
+++ b/xen/arch/arm/platforms/Makefile
@@ -1,11 +1,14 @@
-obj-y += vexpress.o
-obj-$(CONFIG_ARM_32) += brcm.o
-obj-$(CONFIG_ARM_32) += exynos5.o
-obj-$(CONFIG_ARM_32) += midway.o
-obj-$(CONFIG_ARM_32) += omap5.o
-obj-$(CONFIG_ARM_32) += rcar2.o
-obj-$(CONFIG_ARM_64) += seattle.o
-obj-y += sunxi.o
-obj-$(CONFIG_ARM_64) += thunderx.o
-obj-$(CONFIG_ARM_64) += xgene-storm.o
-obj-$(CONFIG_ARM_64) += xilinx-zynqmp.o
+obj-$(CONFIG_ALL_32) += vexpress.o
+obj-$(CONFIG_ALL_32) += sunxi.o
+obj-$(CONFIG_ALL_32) += brcm.o
+obj-$(CONFIG_ALL_32) += exynos5.o
+obj-$(CONFIG_ALL_32) += midway.o
+obj-$(CONFIG_ALL_32) += omap5.o
+obj-$(CONFIG_ALL_32) += rcar2.o
+
+obj-$(CONFIG_ALL_64) += vexpress.o
+obj-$(CONFIG_ALL_64) += sunxi.o
+obj-$(CONFIG_ALL_64) += seattle.o
+obj-$(CONFIG_ALL_64) += thunderx.o
+obj-$(CONFIG_ALL_64) += xgene-storm.o
+obj-$(CONFIG_MPSOC_PLATFORM)  += xilinx-zynqmp.o




--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Andrii Anisov]

Hello Julien,


On 27.07.18 14:27, Julien Grall wrote:

There are no need for duplication. You can instead do something like:

config ALL_64
    default (ALL && ARM_64)

config ALL_32
    default (ALL && ARM_32)

config MPSOC_PLATFORM
    bool
    default (ALL_64 || MPSOC)

Yep, but then "config ALL" should not select MPSOC_PLATFORM by itself.


--

*Andrii Anisov*


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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Julien Grall]

On 27/07/18 12:34, Andrii Anisov wrote:

Hello Julien,


On 27.07.18 14:27, Julien Grall wrote:

There are no need for duplication. You can instead do something like:

config ALL_64
    default (ALL && ARM_64)

config ALL_32
    default (ALL && ARM_32)

config MPSOC_PLATFORM
    bool
    default (ALL_64 || MPSOC)

Yep, but then "config ALL" should not select MPSOC_PLATFORM by itself.


I know... See my answer on your reply.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 2/2] x86/xstate: Make errors in xstate calculations more obvious by crashing the domain

[Jan Beulich]

>>> On 19.07.18 at 13:44,  wrote:
> --- a/xen/arch/x86/xstate.c
> +++ b/xen/arch/x86/xstate.c
> @@ -707,12 +707,32 @@ int handle_xsetbv(u32 index, u64 new_bv)
>  if ( index != XCR_XFEATURE_ENABLED_MASK )
>  return -EOPNOTSUPP;
>  
> -if ( (new_bv & ~xcr0_max) ||
> - (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) )
> +/*
> + * The CPUID logic shouldn't be able to hand out an XCR0 exceeding Xen's
> + * maximum features, but keep the check for robustness.
> + */
> +if ( unlikely(xcr0_max & ~xfeature_mask) )
> +{
> +gprintk(XENLOG_ERR,
> +"xcr0_max %016" PRIx64 " exceeds hardware max %016" PRIx64 
> "\n",
> +new_bv, xfeature_mask);

I've only noticed this while doing the 4.8 backport: I don't think you've
meant to log new_bv here, rather than xcr0_max.

Jan



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

Re: [Xen-devel] [PATCH v3 2/2] x86/xstate: Make errors in xstate calculations more obvious by crashing the domain

[Andrew Cooper]

On 27/07/18 14:24, Jan Beulich wrote:
 On 19.07.18 at 13:44,  wrote:
>> --- a/xen/arch/x86/xstate.c
>> +++ b/xen/arch/x86/xstate.c
>> @@ -707,12 +707,32 @@ int handle_xsetbv(u32 index, u64 new_bv)
>>  if ( index != XCR_XFEATURE_ENABLED_MASK )
>>  return -EOPNOTSUPP;
>>  
>> -if ( (new_bv & ~xcr0_max) ||
>> - (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) )
>> +/*
>> + * The CPUID logic shouldn't be able to hand out an XCR0 exceeding Xen's
>> + * maximum features, but keep the check for robustness.
>> + */
>> +if ( unlikely(xcr0_max & ~xfeature_mask) )
>> +{
>> +gprintk(XENLOG_ERR,
>> +"xcr0_max %016" PRIx64 " exceeds hardware max %016" PRIx64 
>> "\n",
>> +new_bv, xfeature_mask);
> I've only noticed this while doing the 4.8 backport: I don't think you've
> meant to log new_bv here, rather than xcr0_max.

Oops - you're completely correct.

That is an oversight from rearranging the logic.

~Andrew

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8d7aef3d1e57ea494ba9ca3c2fbbb44efffed676
baseline version:
 ovmf f413763b6b8f2798595d468cf868ae5985d3eabc

Last test of basis   125613  2018-07-27 05:46:36 Z0 days
Testing same since   125625  2018-07-27 10:10:46 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ruiyu Ni 
  Star Zeng 
  Yunhua Feng 
  Zhang Chao B 
  Zhang, Chao B 

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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f413763b6b..8d7aef3d1e  8d7aef3d1e57ea494ba9ca3c2fbbb44efffed676 -> 
xen-tested-master

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 123814
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 123814

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  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-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  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-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  2eb748d2599c6e9f8081e372a803f621fc7d0649
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z   52 days
Failing since123840  2018-06-06 04:19:28 Z   51 days   38 attempts
Testing same since   125586  2018-07-26 07:52:53 Z1 days1 attempts


People who touched revisions under test:
Ales Musil 
  Andrea Bolognani 
  Anya Harter 
  Bjoern Walk 
  Bobo Du 
  Boris Fiuczynski 
  Brijesh Singh 
  Changkuo Shi 
  Chen Hanxiao 
  Christian Ehrhardt 
  Cole Robinson 
  Daniel Nicoletti 
  Daniel P. Berrangé 
  Daniel Veillard 
  Eric Blake 
  Erik Skultety 
  Fabiano Fidêncio 
  Filip Alac 
  Han Han 
  intrigeri 
  intrigeri 
  Jamie Strandboge 
  Jie Wang 
  Jiri Denemark 
  John Ferlan 
  Julio Faracco 
  Ján Tomko 
  Kashyap Chamarthy 
  Katerina Koukiou 
  Laine Stump 
  Laszlo Ersek 
  Luyao Huang 
  Marc Hartmayer 
  Marc Hartmayer 
  Marcos Paulo de Souza 
  Martin Kletzander 
  Michal Privoznik 
  Michal Prívozník 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 
  Pino Toscano 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shi Lei 
  Shichangkuo 
  Simon Kobyda 
  Stefan Bader 
  Stefan Berger 
  Sukrit Bhatnagar 
  Tomáš Golembiovský 
  w00251574 
  Weilun Zhu 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blo

[Xen-devel] [PATCH v4 00/32] libxl: Enable save/restore/migration of a restricted QEMU + libxl__ev_qmp_*

[Anthony PERARD]

In order for libxl to be able to manage QEMU while it is restricted, a few
changes are needed. We need a new way to get a startup notification from QEMU
as xenstore may not be accessible when QEMU is ready. We also need to a
different way to have QEMU save it's state and to insert cdrom as a restricted
QEMU doesn't have access to the file system.

For both, we can use QMP, we can use it to query QEMU's status, and we can use
it to send a file descriptor through which QEMU can save its state, or it can
be a cdrom.

We take this opportunity to rewrite the QMP client, and this time been
asynchronous, the result is libxl__ev_qmp_*.

The plat de résistance in this patch series start with patch
"libxl: Design of an async API to issue QMP commands to QEMU"
which implement libxl__ev_qmp_* functions to turn the QMP client into
asynchronous mode.

This comes with changes that uses the new interface.
* "libxl: QEMU startup sync based on QMP"
  which can use QMP to find out when QEMU as started.
  this requires: "libxl_dm: Pre-open QMP socket for QEMU"
  But that only works with dm_restrict=1 as explain in the patch.
* "libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp"
  Which rewrite libxl__qmp_save(), and adds the ability to have QEMU save
  its state to a file descriptor which libxl will have openned.
* "libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp"
  Which rewrites libxl__qmp_insert_cdrom() and adds the ability for libxl
  to open the cdrom on behalf of QEMU.

The first few patches do some cleanup and fixes of the current qmp client
implementation, mostly because it bothered me as I think we should remove the
current implementation. They could be commited ahead of libxl__ev_qmp.

Changes in v4:
Better API which meant a lot of other changes.

Patches series available in a git tag:
git fetch https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git 
libxl-migration-fdset-v4
git checkout -b libxl-migration-fdset-v4 FETCH_HEAD

Cheers,

Anthony PERARD (32):
  libxl_event: Fix DEBUG prints
  libxl_qmp: Documentation of the logic of the QMP client
  libxl_qmp: Fix use of DEBUG_RECEIVED
  libxl_json: fix build with DEBUG_ANSWER
  libxl_qmp: Move the buffer realloc to the same scope level as read
  libxl_qmp: Add a warning to not trust QEMU
  libxl_qmp: Move struct sockaddr_un variable to qmp_open()
  libxl: Add libxl__prepare_sockaddr_un() helper
  libxl_qmp: Remove unused yajl_ctx from handler
  libxl_json: constify libxl__json_object_to_yajl_gen arguments
  libxl_dm: Add libxl__qemu_qmp_path()
  libxl: Design of an async API to issue QMP commands to QEMU
  libxl_qmp: Connect to QMP socket
  libxl_qmp: Implement fd callback and read data
  libxl_json: Enable yajl_allow_trailing_garbage
  libxl_json: libxl__json_object_to_json
  libxl_qmp: Parse JSON input from QMP
  libxl_qmp: Separate QMP message generation from qmp_send_prepare
  libxl_qmp: Prepare the command to be sent
  libxl_qmp: Handle write to QMP socket
  libxl_qmp: Simplify qmp_response_type() prototype
  libxl_qmp: Handle messages from QEMU
  libxl_qmp: Respond to QMP greeting
  libxl_qmp: Disable beautify for QMP generated cmd
  libxl_exec: Add libxl__spawn_initiate_failure
  libxl_dm: Pre-open QMP socket for QEMU
  libxl: QEMU startup sync based on QMP
  libxl_qmp: Store advertised QEMU version in libxl__ev_qmp
  libxl: Change libxl__domain_suspend_device_model() to be async.
  libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp
  libxl_disk: Cut libxl_cdrom_insert into step
  libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp

 tools/libxl/libxl_create.c   |  30 +-
 tools/libxl/libxl_disk.c | 214 +--
 tools/libxl/libxl_dm.c   | 143 -
 tools/libxl/libxl_dom_suspend.c  |  22 +-
 tools/libxl/libxl_event.c|   8 +-
 tools/libxl/libxl_exec.c |   7 +
 tools/libxl/libxl_internal.h | 166 -
 tools/libxl/libxl_json.c |  42 +-
 tools/libxl/libxl_json.h |   5 +-
 tools/libxl/libxl_qmp.c  | 922 ---
 tools/libxl/libxl_types.idl  |   4 +
 tools/libxl/libxl_types_internal.idl |   8 +
 tools/libxl/libxl_utils.c|  14 +
 13 files changed, 1385 insertions(+), 200 deletions(-)

-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 02/32] libxl_qmp: Documentation of the logic of the QMP client

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---

Notes:
v3:
- Add documentation of the qmp_callback_t type.

New in RFC v2

 tools/libxl/libxl_qmp.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 0fe42813bf..4555d6ae36 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -18,6 +18,42 @@
  * Specification, see in the QEMU repository.
  */
 
+/*
+ * Logic used to send command to QEMU
+ *
+ * qmp_open():
+ *  Will open a socket and connect to QEMU.
+ *
+ * qmp_next():
+ *  Will read data sent by QEMU and then call qmp_handle_response() once a
+ *  complete QMP message is received.
+ *  The function return on timeout/error or once every data received as been
+ *  processed.
+ *
+ * qmp_handle_response()
+ *  This process json messages received from QEMU and update different list and
+ *  may call callback function.
+ *  `libxl__qmp_handler.wait_for_id` is reset once a message with this ID is
+ *processed.
+ *  `libxl__qmp_handler.callback_list`: list with ID of command sent and
+ *optional assotiated callback function. The return value of a callback is
+ *set in context.
+ *
+ * qmp_send():
+ *  Simply prepare a QMP command and send it to QEMU.
+ *  It also add a `struct callback_id_pair` on the
+ *  `libxl__qmp_handler.callback_list` via qmp_send_prepare().
+ *
+ * qmp_synchronous_send():
+ *  This function calls qmp_send(), then wait for QEMU to reply to the command.
+ *  The wait is done by calling qmp_next() over and over again until either
+ *  there is a response for the command or there is an error.
+ *
+ *  An ID can be set for each QMP command, this is set into
+ *  `libxl__qmp_handler.wait_for_id`. qmp_next will check every response's ID
+ *  again this field and change the value of the field once the ID is found.
+ */
+
 #include "libxl_osdeps.h" /* must come before any other headers */
 
 #include 
@@ -43,6 +79,12 @@
 #define QMP_RECEIVE_BUFFER_SIZE 4096
 #define PCI_PT_QDEV_ID "pci-pt-%02x_%02x.%01x"
 
+/*
+ * qmp_callback_t is call whenever a message from QMP contain the "id"
+ * associated with the callback.
+ * "tree" contain the JSON tree that is in "return" of a QMP message. If QMP
+ * sent an error message, "tree" will be NULL.
+ */
 typedef int (*qmp_callback_t)(libxl__qmp_handler *qmp,
   const libxl__json_object *tree,
   void *opaque);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 06/32] libxl_qmp: Add a warning to not trust QEMU

[Anthony PERARD]

... even if it is not the case for the current code.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_qmp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 5b608f47e5..987bf0232e 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -16,6 +16,9 @@
 /*
  * This file implement a client for QMP (QEMU Monitor Protocol). For the
  * Specification, see in the QEMU repository.
+ *
+ * WARNING - Do not trust QEMU when writing codes for new commands or when
+ *   improving the client code.
  */
 
 /*
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 04/32] libxl_json: fix build with DEBUG_ANSWER

[Anthony PERARD]

Also replace LIBXL__LOG_DEBUG by XTL_DEBUG, because it's shorter and
more often used in libxl.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---

Notes:
v4:
explain s/LIBXL__LOG_DEBUG/XTL_DEBUG/.
acked

 tools/libxl/libxl_json.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index 0823b8cfd2..dc93a88ef1 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -59,8 +59,8 @@ struct libxl__yajl_ctx {
 const unsigned char *buf = NULL; \
 size_t len = 0; \
 yajl_gen_get_buf((yajl_ctx)->g, &buf, &len); \
-LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), LIBXL__LOG_DEBUG,
-  "response:\n", buf); \
+LIBXL__LOG(libxl__gc_owner((yajl_ctx)->gc), XTL_DEBUG, \
+  "response: %s\n", buf); \
 yajl_gen_free((yajl_ctx)->g); \
 (yajl_ctx)->g = NULL; \
 } while (0)
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 03/32] libxl_qmp: Fix use of DEBUG_RECEIVED

[Anthony PERARD]

This patch fix complilation error with #define DEBUG_RECEIVED of the
macro DEBUG_REPORT_RECEIVED.

  error: field precision specifier ‘.*’ expects argument of type ‘int’, but 
argument 9 has type ‘ssize_t {aka long int}’

Signed-off-by: Anthony PERARD 
Acked-by: Wei Liu 
Acked-by: Ian Jackson 
---

Notes:
New in RFC v2

 tools/libxl/libxl_qmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 4555d6ae36..27227802e4 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -528,7 +528,7 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler *qmp)
 }
 qmp->buffer[rd] = '\0';
 
-DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, rd);
+DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
 
 do {
 char *end = NULL;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 09/32] libxl_qmp: Remove unused yajl_ctx from handler

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---

Notes:
v4:
- Acked
- Fix subject s/form/from/

 tools/libxl/libxl_qmp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 7965ee37b9..c5e05e5679 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -112,7 +112,6 @@ struct libxl__qmp_handler {
 int wait_for_id;
 
 char buffer[QMP_RECEIVE_BUFFER_SIZE + 1];
-libxl__yajl_ctx *yajl_ctx;
 
 libxl_ctx *ctx;
 uint32_t domid;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 07/32] libxl_qmp: Move struct sockaddr_un variable to qmp_open()

[Anthony PERARD]

This variable is only used once, no need to keep it in the handler.

Also fix coding style (remove space after sizeof).
And allow strncpy to use all the space in sun_path.

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
actually allow strncpy to use all the space in sun_path.

 tools/libxl/libxl_qmp.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 987bf0232e..1ffa17b632 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -105,7 +105,6 @@ typedef struct callback_id_pair {
 } callback_id_pair;
 
 struct libxl__qmp_handler {
-struct sockaddr_un addr;
 int qmp_fd;
 bool connected;
 time_t timeout;
@@ -431,6 +430,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char 
*qmp_socket_path,
 {
 int ret = -1;
 int i = 0;
+struct sockaddr_un addr;
 
 qmp->qmp_fd = socket(AF_UNIX, SOCK_STREAM, 0);
 if (qmp->qmp_fd < 0) {
@@ -447,18 +447,16 @@ static int qmp_open(libxl__qmp_handler *qmp, const char 
*qmp_socket_path,
 goto out;
 }
 
-if (sizeof (qmp->addr.sun_path) <= strlen(qmp_socket_path)) {
+if (sizeof(addr.sun_path) <= strlen(qmp_socket_path)) {
 ret = -1;
 goto out;
 }
-memset(&qmp->addr, 0, sizeof (qmp->addr));
-qmp->addr.sun_family = AF_UNIX;
-strncpy(qmp->addr.sun_path, qmp_socket_path,
-sizeof (qmp->addr.sun_path)-1);
+memset(&addr, 0, sizeof(addr));
+addr.sun_family = AF_UNIX;
+strncpy(addr.sun_path, qmp_socket_path, sizeof(addr.sun_path));
 
 do {
-ret = connect(qmp->qmp_fd, (struct sockaddr *) &qmp->addr,
-  sizeof (qmp->addr));
+ret = connect(qmp->qmp_fd, (struct sockaddr *) &addr, sizeof(addr));
 if (ret == 0)
 break;
 if (errno == ENOENT || errno == ECONNREFUSED) {
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 05/32] libxl_qmp: Move the buffer realloc to the same scope level as read

[Anthony PERARD]

In qmp_next(), the inner loop should only try to parse messages from
QMP, if there is more than one.

The handling of the receive buffer ('incomplete'), should be done at the
same scope level as read(). It doesn't need to be handle more that once
after a read.

Before this patch, when on message what handled, the inner loop would
restart by adding the 'buffer' into 'incomplete' (after reallocation).
Since 'rd' was not reset, the buffer would be strcat a second time.
After that, the stream from the QMP server would have syntax error, and
the parsor would throw errors.

This is unlikely to happen as the receive buffer is very large. And
receiving two messages in a row is unlikely. In the current case, this
could be an event and a response to a command.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---

Notes:
New in RFC v2

 tools/libxl/libxl_qmp.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 27227802e4..5b608f47e5 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -530,23 +530,24 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
*qmp)
 
 DEBUG_REPORT_RECEIVED(qmp->domid, qmp->buffer, (int)rd);
 
+if (incomplete) {
+size_t current_pos = s - incomplete;
+incomplete = libxl__realloc(gc, incomplete,
+incomplete_size + rd + 1);
+strncat(incomplete + incomplete_size, qmp->buffer, rd);
+s = incomplete + current_pos;
+incomplete_size += rd;
+s_end = incomplete + incomplete_size;
+} else {
+incomplete = libxl__strndup(gc, qmp->buffer, rd);
+incomplete_size = rd;
+s = incomplete;
+s_end = s + rd;
+rd = 0;
+}
+
 do {
 char *end = NULL;
-if (incomplete) {
-size_t current_pos = s - incomplete;
-incomplete = libxl__realloc(gc, incomplete,
-incomplete_size + rd + 1);
-strncat(incomplete + incomplete_size, qmp->buffer, rd);
-s = incomplete + current_pos;
-incomplete_size += rd;
-s_end = incomplete + incomplete_size;
-} else {
-incomplete = libxl__strndup(gc, qmp->buffer, rd);
-incomplete_size = rd;
-s = incomplete;
-s_end = s + rd;
-rd = 0;
-}
 
 end = strstr(s, "\r\n");
 if (end) {
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCH v3 1/2] x86/xstate: Use a guests CPUID policy, rather than allowing all features

[Jan Beulich]

>>> On 27.07.18 at 11:37,  wrote:
> Before 4.9, the calls to {hvm,pv}_cpuid() are needed to because the
> information can't be read directly out of d->arch.cpuids[].  The restore
> boolean is needed because this array will be empty at the time it is
> accessed on the restore path.

Would you mind looking over the 4.8 backport below, where I think I've
got away without such a boolean?

Thanks, Jan

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -1177,7 +1177,7 @@ long arch_do_domctl(
 if ( _xcr0_accum )
 {
 if ( evc->size >= PV_XSAVE_HDR_SIZE + XSTATE_AREA_MIN_SIZE )
-ret = validate_xstate(_xcr0, _xcr0_accum,
+ret = validate_xstate(d, _xcr0, _xcr0_accum,
   &_xsave_area->xsave_hdr);
 }
 else if ( !_xcr0 )
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1356,7 +1356,7 @@ static int hvm_load_cpu_xsave_states(str
 ctxt = (struct hvm_hw_cpu_xsave *)&h->data[h->cur];
 h->cur += desc->length;
 
-err = validate_xstate(ctxt->xcr0, ctxt->xcr0_accum,
+err = validate_xstate(d, ctxt->xcr0, ctxt->xcr0_accum,
   (const void *)&ctxt->save_area.xsave_hdr);
 if ( err )
 {
--- a/xen/arch/x86/xstate.c
+++ b/xen/arch/x86/xstate.c
@@ -652,12 +652,47 @@ static bool_t valid_xcr0(u64 xcr0)
 return !(xcr0 & XSTATE_BNDREGS) == !(xcr0 & XSTATE_BNDCSR);
 }
 
-int validate_xstate(u64 xcr0, u64 xcr0_accum, const struct xsave_hdr *hdr)
+static uint64_t guest_xcr0_max(const struct domain *d)
 {
+if ( has_hvm_container_domain(d) )
+{
+uint32_t eax, ecx = 0, edx;
+
+hvm_cpuid(XSTATE_CPUID, &eax, NULL, &ecx, &edx);
+
+return ((uint64_t)edx << 32) | eax;
+}
+else
+{
+struct cpu_user_regs regs = { };
+
+regs._eax = XSTATE_CPUID;
+regs._ecx = 0;
+pv_cpuid(®s);
+
+return (regs.rdx << 32) | regs._eax;
+}
+}
+
+int validate_xstate(const struct domain *d, uint64_t xcr0, uint64_t xcr0_accum,
+const struct xsave_hdr *hdr)
+{
+uint64_t xcr0_max;
 unsigned int i;
 
+if ( d == current->domain )
+xcr0_max = guest_xcr0_max(d);
+else
+{
+xcr0_max = xfeature_mask;
+if ( !has_hvm_container_domain(d) )
+xcr0_max &= ~(XSTATE_BNDREGS | XSTATE_BNDCSR |
+  XSTATE_PKRU | XSTATE_LWP);
+}
+
 if ( (hdr->xstate_bv & ~xcr0_accum) ||
  (xcr0 & ~xcr0_accum) ||
+ (xcr0_accum & ~xcr0_max) ||
  !valid_xcr0(xcr0) ||
  !valid_xcr0(xcr0_accum) )
 return -EINVAL;
@@ -676,18 +711,16 @@ int validate_xstate(u64 xcr0, u64 xcr0_a
 int handle_xsetbv(u32 index, u64 new_bv)
 {
 struct vcpu *curr = current;
+uint64_t xcr0_max = guest_xcr0_max(curr->domain);
 u64 mask;
 
 if ( index != XCR_XFEATURE_ENABLED_MASK )
 return -EOPNOTSUPP;
 
-if ( (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) )
+if ( (new_bv & ~xcr0_max) ||
+ (new_bv & ~xfeature_mask) || !valid_xcr0(new_bv) )
 return -EINVAL;
 
-/* XCR0.PKRU is disabled on PV mode. */
-if ( is_pv_vcpu(curr) && (new_bv & XSTATE_PKRU) )
-return -EOPNOTSUPP;
-
 if ( !set_xcr0(new_bv) )
 return -EFAULT;
 
--- a/xen/include/asm-x86/xstate.h
+++ b/xen/include/asm-x86/xstate.h
@@ -107,8 +107,9 @@ uint64_t get_msr_xss(void);
 void xsave(struct vcpu *v, uint64_t mask);
 void xrstor(struct vcpu *v, uint64_t mask);
 bool_t xsave_enabled(const struct vcpu *v);
-int __must_check validate_xstate(u64 xcr0, u64 xcr0_accum,
- const struct xsave_hdr *);
+int __must_check validate_xstate(const struct domain *d,
+ uint64_t xcr0, uint64_t xcr0_accum,
+ const struct xsave_hdr *hdr);
 int __must_check handle_xsetbv(u32 index, u64 new_bv);
 void expand_xsave_states(struct vcpu *v, void *dest, unsigned int size);
 void compress_xsave_states(struct vcpu *v, const void *src, unsigned int size);



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

[Xen-devel] [PATCH v4 08/32] libxl: Add libxl__prepare_sockaddr_un() helper

[Anthony PERARD]

There is going to be a few more users that want to use UNIX socket, this
helper is to prepare the `struct sockaddr_un` and check that the path
isn't too long.

Also start to use it in libxl_qmp.c.

Signed-off-by: Anthony PERARD 
---

Notes:
New in v4.

 tools/libxl/libxl_internal.h |  4 
 tools/libxl/libxl_qmp.c  | 10 --
 tools/libxl/libxl_utils.c| 14 ++
 3 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 843c625142..ab1de80522 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -47,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -4420,6 +4421,9 @@ static inline bool libxl__string_is_default(char **s)
 {
 return *s == NULL;
 }
+
+_hidden int libxl__prepare_sockaddr_un(libxl__gc *gc, struct sockaddr_un *un,
+   const char *path, const char *what);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 1ffa17b632..7965ee37b9 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -428,6 +428,7 @@ static libxl__qmp_handler *qmp_init_handler(libxl__gc *gc, 
uint32_t domid)
 static int qmp_open(libxl__qmp_handler *qmp, const char *qmp_socket_path,
 int timeout)
 {
+GC_INIT(qmp->ctx);
 int ret = -1;
 int i = 0;
 struct sockaddr_un addr;
@@ -447,13 +448,9 @@ static int qmp_open(libxl__qmp_handler *qmp, const char 
*qmp_socket_path,
 goto out;
 }
 
-if (sizeof(addr.sun_path) <= strlen(qmp_socket_path)) {
-ret = -1;
+ret = libxl__prepare_sockaddr_un(gc, &addr, qmp_socket_path, "QMP socket");
+if (ret)
 goto out;
-}
-memset(&addr, 0, sizeof(addr));
-addr.sun_family = AF_UNIX;
-strncpy(addr.sun_path, qmp_socket_path, sizeof(addr.sun_path));
 
 do {
 ret = connect(qmp->qmp_fd, (struct sockaddr *) &addr, sizeof(addr));
@@ -471,6 +468,7 @@ static int qmp_open(libxl__qmp_handler *qmp, const char 
*qmp_socket_path,
 out:
 if (ret == -1 && qmp->qmp_fd > -1) close(qmp->qmp_fd);
 
+GC_FREE;
 return ret;
 }
 
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index 507ee56c7c..7907e20672 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -1234,6 +1234,20 @@ int libxl__random_bytes(libxl__gc *gc, uint8_t *buf, 
size_t len)
 return ret;
 }
 
+int libxl__prepare_sockaddr_un(libxl__gc *gc,
+   struct sockaddr_un *un, const char *path,
+   const char *what) {
+if (sizeof(un->sun_path) <= strlen(path)) {
+LOG(ERROR, "UNIX socket path '%s' is too long for %s", path, what);
+LOG(DEBUG, "Path must be less than %zu bytes", sizeof(un->sun_path));
+return ERROR_INVAL;
+}
+memset(un, 0, sizeof(struct sockaddr_un));
+un->sun_family = AF_UNIX;
+strncpy(un->sun_path, path, sizeof(un->sun_path));
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 01/32] libxl_event: Fix DEBUG prints

[Anthony PERARD]

The libxl__log() call was missing the domid.

The macro DBG is using LIBXL__LOG which rely on a "gc". Add a GC where
needed.

Signed-off-by: Anthony PERARD 
Reviewed-by: Wei Liu 
Acked-by: Ian Jackson 
---

Notes:
v3:
- Add a commit message.

New in RFC v2

 tools/libxl/libxl_event.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_event.c b/tools/libxl/libxl_event.c
index 484f9bab4d..0370b6acdd 100644
--- a/tools/libxl/libxl_event.c
+++ b/tools/libxl/libxl_event.c
@@ -248,6 +248,7 @@ void libxl__ev_fd_deregister(libxl__gc *gc, libxl__ev_fd 
*ev)
 short libxl__fd_poll_recheck(libxl__egc *egc, int fd, short events) {
 struct pollfd check;
 int r;
+EGC_GC;
 
 for (;;) {
 check.fd = fd;
@@ -336,7 +337,7 @@ static void time_done_debug(libxl__gc *gc, const char *func,
 libxl__ev_time *ev, int rc)
 {
 #ifdef DEBUG
-libxl__log(CTX, XTL_DEBUG, -1,__FILE__,0,func,
+libxl__log(CTX, XTL_DEBUG, -1, __FILE__, 0, func, INVALID_DOMID,
"ev_time=%p done rc=%d .func=%p infinite=%d abs=%lu.%06lu",
ev, rc, ev->func, ev->infinite,
(unsigned long)ev->abs.tv_sec, (unsigned long)ev->abs.tv_usec);
@@ -445,6 +446,8 @@ void libxl__ev_time_deregister(libxl__gc *gc, 
libxl__ev_time *ev)
 
 static void time_occurs(libxl__egc *egc, libxl__ev_time *etime, int rc)
 {
+EGC_GC;
+
 DBG("ev_time=%p occurs abs=%lu.%06lu",
 etime, (unsigned long)etime->abs.tv_sec,
 (unsigned long)etime->abs.tv_usec);
@@ -1192,6 +1195,7 @@ static int afterpoll_check_fd(libxl__poller *poller,
 static void fd_occurs(libxl__egc *egc, libxl__ev_fd *efd, short revents_ign)
 {
 short revents_current = libxl__fd_poll_recheck(egc, efd->fd, efd->events);
+EGC_GC;
 
 DBG("ev_fd=%p occurs fd=%d events=%x revents_ign=%x revents_current=%x",
 efd, efd->fd, efd->events, revents_ign, revents_current);
@@ -2117,6 +2121,8 @@ int libxl_ao_abort(libxl_ctx *ctx, const 
libxl_asyncop_how *how)
 int libxl__ao_aborting(libxl__ao *ao)
 {
 libxl__ao *root = ao_nested_root(ao);
+AO_GC;
+
 if (root->aborting) {
 DBG("ao=%p: aborting at explicit check (root=%p)", ao, root);
 return ERROR_ABORTED;
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCH RFC] tools/kdd: avoid adversarial optimisation hazard

[Wei Liu]

One interesting observation is that if I revert 2de2b10b225 which turns
the type of offset from uint32_t back to uint64_t, kdd.c will build with
32 bit, but then of course 64 bit build is broken. :-/

Wei.

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

[Xen-devel] [PATCH RFC] x86/HVM: also stuff RSB upon exit to guest

[Jan Beulich]

In order to mostly eliminate abuse of what Xen leaves in the RSB by
guest level attackers, fill the RSB with almost-NULL pointers right
before entering guest context.

The placement of the initialization code is intentional: If it was put
in e.g. hvm_enable(), we'd have to be more careful wrt. changing the
low L4 entry of the idle page tables (I didn't check whether boot time
low mappings have disappeared by then), and get_random() couldn't be
used either. Furthermore this way, if no HVM guest gets ever started,
no setup would ever occur.

Signed-off-by: Jan Beulich 
---
TBD: In the end I'm not sure the (pseudo-)randomness is worth it.
 Placing the stub uniformly at a fixed address would allow to get
 rid of the variable, slightly streamlining the call sites.
TBD: Obviously using NULL here has the downside of reads through NULL
 not going to fault anymore.

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -85,6 +85,10 @@ integer_param("hvm_debug", opt_hvm_debug
 
 struct hvm_function_table hvm_funcs __read_mostly;
 
+extern void do_overwrite_rsb(void);
+extern const char do_overwrite_rsb_end[];
+void (* __read_mostly hvm_overwrite_rsb)(void) = do_overwrite_rsb;
+
 /*
  * The I/O permission bitmap is globally shared by all HVM guests except
  * the hardware domain which needs a more permissive one.
@@ -583,6 +587,49 @@ int hvm_domain_initialise(struct domain
 return -EINVAL;
 }
 
+if ( boot_cpu_has(X86_FEATURE_SC_RSB_HVM) &&
+ unlikely((unsigned long)hvm_overwrite_rsb >= PAGE_SIZE) )
+{
+/*
+ * Map an RSB stuffing routine at a random, 16-byte aligned address
+ * in the first linear page, to allow filling the RSB with almost-NULL
+ * pointers before entering HVM guest context.  This builds on the
+ * assumption that no sane OS will place anything there which could be
+ * abused as an exploit gadget.
+ */
+unsigned long addr = (get_random() << 4) & ~PAGE_MASK;
+unsigned int size = do_overwrite_rsb_end -
+(const char *)do_overwrite_rsb;
+struct page_info *pg = alloc_domheap_page(NULL, 0);
+void *ptr;
+
+if ( !pg ||
+ map_pages_to_xen(0, page_to_mfn(pg), 1, PAGE_HYPERVISOR_RX) )
+{
+if ( pg )
+free_domheap_page(pg);
+return -ENOMEM;
+}
+
+/*
+ * Avoid NULL itself, so that branches there will hit the all-ones
+ * pattern installed below.
+ */
+if ( !addr )
+addr = 0x10;
+while ( addr + size > PAGE_SIZE )
+addr -= 0x10;
+
+ptr = __map_domain_page(pg);
+memset(ptr, -1, PAGE_SIZE);
+memcpy(ptr + addr, do_overwrite_rsb, size);
+unmap_domain_page(ptr);
+
+smp_wmb();
+hvm_overwrite_rsb = (void *)addr;
+printk(XENLOG_INFO "RSB stuffing stub at %p\n", hvm_overwrite_rsb);
+}
+
 spin_lock_init(&d->arch.hvm_domain.irq_lock);
 spin_lock_init(&d->arch.hvm_domain.uc_lock);
 spin_lock_init(&d->arch.hvm_domain.write_map.lock);
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1661,6 +1661,10 @@ void init_xen_l4_slots(l4_pgentry_t *l4t
(ROOT_PAGETABLE_FIRST_XEN_SLOT + slots -
 l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t));
 }
+
+/* Make sure the RSB stuffing stub is accessible. */
+if ( is_hvm_domain(d) )
+l4t[0] = idle_pg_table[0];
 }
 
 bool fill_ro_mpt(mfn_t mfn)
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -552,6 +552,13 @@ ENTRY(dom_crash_sync_extable)
 jmp   asm_domain_crash_synchronous /* Does not return */
 .popsection
 
+#ifdef CONFIG_HVM
+ENTRY(do_overwrite_rsb)
+DO_OVERWRITE_RSB tmp=rdx
+ret
+GLOBAL(do_overwrite_rsb_end)
+#endif
+
 .section .text.entry, "ax", @progbits
 
 ENTRY(common_interrupt)
--- a/xen/include/asm-x86/spec_ctrl_asm.h
+++ b/xen/include/asm-x86/spec_ctrl_asm.h
@@ -249,6 +249,8 @@
 
 /* Use when exiting to HVM guest context. */
 #define SPEC_CTRL_EXIT_TO_HVM   \
+mov hvm_overwrite_rsb(%rip), %rcx;  \
+ALTERNATIVE "", "INDIRECT_CALL %rcx", X86_FEATURE_SC_RSB_HVM;   \
 ALTERNATIVE "", \
 DO_SPEC_CTRL_EXIT_TO_GUEST, X86_FEATURE_SC_MSR_HVM
 




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

[Xen-devel] [PATCH v4 22/32] libxl_qmp: Handle messages from QEMU

[Anthony PERARD]

This will handles messages received, and calls callbacks associated with
the libxl__ev_qmp when the expected response is received.

This also print error messages from QMP on behalf of the callback.

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
Provide an libxl error code to callbacks on error instead of a
qmp_error_class

 tools/libxl/libxl_qmp.c  | 116 +++
 tools/libxl/libxl_types.idl  |   4 +
 tools/libxl/libxl_types_internal.idl |   8 ++
 3 files changed, 128 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index aabf9ad5e7..e649b8054d 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1330,6 +1330,118 @@ static int qmp_ev_prepare_cmd(libxl__gc *gc,
 return 0;
 }
 
+/*
+ * Handle messages received from QMP server
+ */
+
+static int qmp_error_class_to_libxl_error_code(const libxl__qmp_error_class c)
+{
+switch (c) {
+case LIBXL__QMP_ERROR_CLASS_GENERICERROR:
+return ERROR_QMP_GENERIC_ERROR;
+case LIBXL__QMP_ERROR_CLASS_COMMANDNOTFOUND:
+return ERROR_QMP_COMMAND_NOT_FOUND;
+case LIBXL__QMP_ERROR_CLASS_DEVICENOTACTIVE:
+return ERROR_QMP_DEVICE_NOT_ACTIVE;
+case LIBXL__QMP_ERROR_CLASS_DEVICENOTFOUND:
+return ERROR_QMP_DEVICE_NOT_FOUND;
+default:
+abort();
+}
+}
+
+/* return 1 when a user callback as been called */
+static int qmp_ev_handle_response(libxl__egc *egc,
+  libxl__ev_qmp *ev,
+  const libxl__json_object *resp,
+  libxl__qmp_message_type type)
+{
+EGC_GC;
+const libxl__json_object *response;
+const libxl__json_object *o;
+int rc;
+int id;
+
+o = libxl__json_map_get("id", resp, JSON_INTEGER);
+if (!o) {
+const char *error_desc;
+
+/* unexpected message, attempt to find an error description */
+o = libxl__json_map_get("error", resp, JSON_MAP);
+o = libxl__json_map_get("desc", o, JSON_STRING);
+error_desc = libxl__json_object_get_string(o);
+if (error_desc)
+LOGD(ERROR, ev->domid, "%s", error_desc);
+else
+LOGD(ERROR, ev->domid, "Received unexpected message: %s",
+ libxl__json_object_to_json(gc, resp));
+return 0;
+}
+
+id = libxl__json_object_get_integer(o);
+if (id != ev->id)
+return 0;
+
+switch (type) {
+case LIBXL__QMP_MESSAGE_TYPE_RETURN: {
+response = libxl__json_map_get("return", resp, JSON_ANY);
+rc = 0;
+break;
+}
+case LIBXL__QMP_MESSAGE_TYPE_ERROR: {
+const char *s;
+const libxl__json_object *err;
+libxl__qmp_error_class error_class;
+
+rc = ERROR_FAIL;
+response = NULL;
+
+err = libxl__json_map_get("error", resp, JSON_MAP);
+o = libxl__json_map_get("class", err, JSON_STRING);
+s = libxl__json_object_get_string(o);
+if (s && !libxl__qmp_error_class_from_string(s, &error_class))
+rc = qmp_error_class_to_libxl_error_code(error_class);
+
+o = libxl__json_map_get("desc", err, JSON_STRING);
+s = libxl__json_object_get_string(o);
+if (s)
+LOGD(ERROR, ev->domid, "%s", s);
+
+break;
+}
+default:
+abort();
+}
+
+ev->id = -1;
+ev->callback(egc, ev, response, rc); /* must be last */
+return 1;
+}
+
+/* return 1 when a user callback as been called */
+static int qmp_ev_handle_message(libxl__egc *egc,
+ libxl__ev_qmp *ev,
+ const libxl__json_object *resp)
+{
+EGC_GC;
+libxl__qmp_message_type type = qmp_response_type(resp);
+
+switch (type) {
+case LIBXL__QMP_MESSAGE_TYPE_QMP:
+/* greeting message */
+return 0;
+case LIBXL__QMP_MESSAGE_TYPE_RETURN:
+case LIBXL__QMP_MESSAGE_TYPE_ERROR:
+return qmp_ev_handle_response(egc, ev, resp, type);
+case LIBXL__QMP_MESSAGE_TYPE_EVENT:
+/* Event are ignored */
+return 0;
+case LIBXL__QMP_MESSAGE_TYPE_INVALID:
+return 0;
+}
+return 0;
+}
+
 /*
  * QMP FD callbacks
  */
@@ -1432,6 +1544,10 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
libxl__ev_qmp *ev, int fd)
 end = NULL;
 
 LOG_QMP("JSON object received: %s", libxl__json_object_to_json(gc, o));
+
+/* Must be last and return when the user callback is called */
+if (qmp_ev_handle_message(egc, ev, o) == 1)
+return 0;
 }
 return 0;
 }
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 4a385801ba..e104fea941 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -69,6 +69,10 @@ libxl_error = Enumeration("error", [
 (-23, "NOTFOUND"),
 (-24, "DOMAIN_DESTROYED"), # Target domain ceased to exist during op
 (-25, "FEATURE_RE

[Xen-devel] [PATCH v4 31/32] libxl_disk: Cut libxl_cdrom_insert into step

[Anthony PERARD]

This is to prepare libxl_cdrom_insert to be able to send commands to
QEMU via the libxl__ev_qmp. The next patch is going to make use of it.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_disk.c | 194 +++
 1 file changed, 137 insertions(+), 57 deletions(-)

diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index e9eceb65e3..c759179628 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -661,31 +661,55 @@ int libxl_device_disk_getinfo(libxl_ctx *ctx, uint32_t 
domid,
 return rc;
 }
 
+typedef struct {
+libxl__ao *ao;
+libxl_domain_config d_config;
+const char *be_path;
+const char *libxl_path;
+libxl_device_disk *disk;
+libxl_device_disk disk_empty;
+libxl_device_disk disk_saved;
+int dm_ver;
+int domid;
+libxl__domain_userdata_lock *lock;
+} libxl__cdrom_insert_state;
+static void cdrom_insert_ejected(libxl__egc *egc,
+ libxl__cdrom_insert_state *cis);
+static void cdrom_insert_inserted(libxl__egc *egc,
+  libxl__cdrom_insert_state *cis);
+static void cdrom_insert_done(libxl__egc *egc,
+  libxl__cdrom_insert_state *cis,
+  int rc);
+
 int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, libxl_device_disk *disk,
const libxl_asyncop_how *ao_how)
 {
 AO_CREATE(ctx, domid, ao_how);
 int num = 0, i;
-libxl_device_disk *disks = NULL, disk_saved, disk_empty;
-libxl_domain_config d_config;
-int rc, dm_ver;
+libxl_device_disk *disks = NULL, *disk_saved, *disk_empty;
+int rc;
 libxl__device device;
-const char *be_path, *libxl_path;
-char * tmp;
-libxl__domain_userdata_lock *lock = NULL;
-xs_transaction_t t = XBT_NULL;
-flexarray_t *insert = NULL, *empty = NULL;
+libxl__cdrom_insert_state *cis;
 
-libxl_domain_config_init(&d_config);
-libxl_device_disk_init(&disk_empty);
-libxl_device_disk_init(&disk_saved);
-libxl_device_disk_copy(ctx, &disk_saved, disk);
+GCNEW(cis);
+cis->ao = ao;
+cis->domid = domid;
+cis->disk = disk;
 
-disk_empty.format = LIBXL_DISK_FORMAT_EMPTY;
-disk_empty.vdev = libxl__strdup(NOGC, disk->vdev);
-disk_empty.pdev_path = libxl__strdup(NOGC, "");
-disk_empty.is_cdrom = 1;
-libxl__device_disk_setdefault(gc, domid, &disk_empty, false);
+disk_empty = &cis->disk_empty;
+disk_saved = &cis->disk_saved;
+
+
+libxl_domain_config_init(&cis->d_config);
+libxl_device_disk_init(disk_empty);
+libxl_device_disk_init(disk_saved);
+libxl_device_disk_copy(ctx, disk_saved, disk);
+
+disk_empty->format = LIBXL_DISK_FORMAT_EMPTY;
+disk_empty->vdev = libxl__strdup(NOGC, disk->vdev);
+disk_empty->pdev_path = libxl__strdup(NOGC, "");
+disk_empty->is_cdrom = 1;
+libxl__device_disk_setdefault(gc, domid, disk_empty, false);
 
 libxl_domain_type type = libxl__domain_type(gc, domid);
 if (type == LIBXL_DOMAIN_TYPE_INVALID) {
@@ -704,8 +728,8 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
 goto out;
 }
 
-dm_ver = libxl__device_model_version_running(gc, domid);
-if (dm_ver == -1) {
+cis->dm_ver = libxl__device_model_version_running(gc, domid);
+if (cis->dm_ver == -1) {
 LOGD(ERROR, domid, "Cannot determine device model version");
 rc = ERROR_FAIL;
 goto out;
@@ -737,31 +761,14 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
 rc = libxl__device_from_disk(gc, domid, disk, &device);
 if (rc) goto out;
 
-be_path = libxl__device_backend_path(gc, &device);
-libxl_path = libxl__device_libxl_path(gc, &device);
-
-insert = flexarray_make(gc, 4, 1);
-
-flexarray_append_pair(insert, "type",
-  libxl__device_disk_string_of_backend(disk->backend));
-if (disk->format != LIBXL_DISK_FORMAT_EMPTY)
-flexarray_append_pair(insert, "params",
-GCSPRINTF("%s:%s",
-libxl__device_disk_string_of_format(disk->format),
-disk->pdev_path));
-else
-flexarray_append_pair(insert, "params", "");
-
-empty = flexarray_make(gc, 4, 1);
-flexarray_append_pair(empty, "type",
-  libxl__device_disk_string_of_backend(disk->backend));
-flexarray_append_pair(empty, "params", "");
+cis->be_path = libxl__device_backend_path(gc, &device);
+cis->libxl_path = libxl__device_libxl_path(gc, &device);
 
 /* Note: CTX lock is already held at this point so lock hierarchy
  * is maintained.
  */
-lock = libxl__lock_domain_userdata(gc, domid);
-if (!lock) {
+cis->lock = libxl__lock_domain_userdata(gc, domid);
+if (!cis->lock) {
 rc = ERROR_LOCK_FAIL;
 goto out;
 }
@@ -769,11 +776,46 @@ int libxl_

[Xen-devel] [PATCH v4 30/32] libxl: Re-implement domain_suspend_device_model using libxl__ev_qmp

[Anthony PERARD]

The re-implementation is done because we want to be able to send the
file description that QEMU can use to save its state. When QEMU is
restricted, it would not be able to write to a path.

This replace both libxl__qmp_stop() and libxl__qmp_save().

qmp_qemu_check_version() was only used by libxl__qmp_save(), so it is
replace by a version using libxl__ev_qmp instead.

Coding style fixed in libxl__domain_suspend_device_model() for the
return value.

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
This patch replace the patch "libxl_qmp: Have QEMU save its state to a 
file
descriptor" from previous version of the serie.
It uses libxl__ev_qmp instead.

 tools/libxl/libxl_dom_suspend.c |  16 ++--
 tools/libxl/libxl_internal.h|   9 +-
 tools/libxl/libxl_qmp.c | 152 +---
 3 files changed, 129 insertions(+), 48 deletions(-)

diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 51c432a00a..0f4e1be115 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -34,6 +34,7 @@ int libxl__domain_suspend_init(libxl__egc *egc,
 libxl__ev_evtchn_init(&dsps->guest_evtchn);
 libxl__ev_xswatch_init(&dsps->guest_watch);
 libxl__ev_time_init(&dsps->guest_timeout);
+libxl__ev_qmp_init(&dsps->qmp);
 
 if (type == LIBXL_DOMAIN_TYPE_INVALID) goto out;
 dsps->type = type;
@@ -72,7 +73,7 @@ int libxl__domain_suspend_device_model(libxl__egc *egc,
libxl__domain_suspend_state *dsps)
 {
 STATE_AO_GC(dsps->ao);
-int ret = 0;
+int rc;
 uint32_t const domid = dsps->domid;
 const char *const filename = dsps->dm_savefile;
 
@@ -81,22 +82,18 @@ int libxl__domain_suspend_device_model(libxl__egc *egc,
 LOGD(DEBUG, domid, "Saving device model state to %s", filename);
 libxl__qemu_traditional_cmd(gc, domid, "save");
 libxl__wait_for_device_model_deprecated(gc, domid, "paused", NULL, 
NULL, NULL);
+dsps->callback_device_model_done(egc, dsps, 0);
+rc = 0;
 break;
 }
 case LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN:
-if (libxl__qmp_stop(gc, domid))
-return ERROR_FAIL;
-/* Save DM state into filename */
-ret = libxl__qmp_save(gc, domid, filename, dsps->live);
-if (ret)
-unlink(filename);
+rc = libxl__qmp_suspend_save(gc, dsps);
 break;
 default:
 return ERROR_INVAL;
 }
 
-dsps->callback_device_model_done(egc, dsps, ret);
-return ret;
+return rc;
 }
 
 static void domain_suspend_common_wait_guest(libxl__egc *egc,
@@ -402,6 +399,7 @@ static void domain_suspend_common_done(libxl__egc *egc,
 libxl__ev_evtchn_cancel(gc, &dsps->guest_evtchn);
 libxl__ev_xswatch_deregister(gc, &dsps->guest_watch);
 libxl__ev_time_deregister(gc, &dsps->guest_timeout);
+libxl__ev_qmp_dispose(gc, &dsps->qmp);
 dsps->callback_common_done(egc, dsps, rc);
 }
 
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5b65cdbe40..cafe8b5733 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1942,13 +1942,8 @@ _hidden int libxl__qmp_pci_del(libxl__gc *gc, int domid,
libxl_device_pci *pcidev);
 /* Resume hvm domain */
 _hidden int libxl__qmp_system_wakeup(libxl__gc *gc, int domid);
-/* Suspend QEMU. */
-_hidden int libxl__qmp_stop(libxl__gc *gc, int domid);
 /* Resume QEMU. */
 _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
-/* Save current QEMU state into fd. */
-_hidden int libxl__qmp_save(libxl__gc *gc, int domid, const char *filename,
-bool live);
 /* Load current QEMU state from file. */
 _hidden int libxl__qmp_restore(libxl__gc *gc, int domid, const char *filename);
 /* Set dirty bitmap logging status */
@@ -3406,6 +3401,7 @@ struct libxl__domain_suspend_state {
 libxl__xswait_state pvcontrol;
 libxl__ev_xswatch guest_watch;
 libxl__ev_time guest_timeout;
+libxl__ev_qmp qmp;
 
 const char *dm_savefile;
 void (*callback_device_model_done)(libxl__egc*,
@@ -3417,6 +3413,9 @@ int libxl__domain_suspend_init(libxl__egc *egc,
libxl__domain_suspend_state *dsps,
libxl_domain_type type);
 
+_hidden int libxl__qmp_suspend_save(libxl__gc *gc,
+libxl__domain_suspend_state *dsps);
+
 struct libxl__domain_save_state {
 /* set by caller of libxl__domain_save */
 libxl__ao *ao;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 332dcf2069..07203a6fe6 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -398,13 +398,14 @@ static int qmp_handle_response(libxl__gc *gc, 
libxl__qmp_handler *qmp,
 return 0;
 }
 
-static bool qmp_qemu_check_version(libxl__qmp_handler *qmp, int major,
-   int minor, int micro)

[Xen-devel] [PATCH v4 29/32] libxl: Change libxl__domain_suspend_device_model() to be async.

[Anthony PERARD]

This create an extra step for the two calls sites of the function.

Signed-off-by: Anthony PERARD 

---
libxl_domain_soft_reset() haven't been tested, as it doesn't appear to
possible to call the function from xl.
---
 tools/libxl/libxl_create.c  | 30 ++
 tools/libxl/libxl_dom_suspend.c |  8 ++--
 tools/libxl/libxl_internal.h|  4 +++-
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1ccb3e35d3..3181c57c30 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1755,6 +1755,9 @@ error:
 domcreate_complete(egc, &cdcs->dcs, rc);
 }
 
+static void soft_reset_dm_suspended(libxl__egc *egc,
+libxl__domain_suspend_state *dsps,
+int rc);
 static int do_domain_soft_reset(libxl_ctx *ctx,
 libxl_domain_config *d_config,
 uint32_t domid_soft_reset,
@@ -1837,30 +1840,41 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
 goto out;
 }
 
-rc = libxl__domain_suspend_device_model(gc, &dss->dsps);
+dss->dsps.ao = ao;
+dss->dsps.callback_device_model_done = soft_reset_dm_suspended;
+rc = libxl__domain_suspend_device_model(egc, &dss->dsps);
 if (rc) {
 LOGD(ERROR, domid_soft_reset, "failed to suspend device model.");
 goto out;
 }
 
+return AO_INPROGRESS;
+
+ out:
+return AO_CREATE_FAIL(rc);
+}
+
+static void soft_reset_dm_suspended(libxl__egc *egc,
+libxl__domain_suspend_state *dsps,
+int rc)
+{
+STATE_AO_GC(dsps->ao);
+libxl__domain_soft_reset_state *srs = CONTAINER_OF(dsps, *srs, dss.dsps);
+libxl__app_domain_create_state *cdcs = &srs->cdcs;
+
 /*
  * Ask all backends to disconnect by removing the domain from
  * xenstore. On the creation path the domain will be introduced to
  * xenstore again with probably different store/console/...
  * channels.
  */
-xs_release_domain(ctx->xsh, cdcs->dcs.domid_soft_reset);
+xs_release_domain(CTX->xsh, cdcs->dcs.domid_soft_reset);
 
 srs->dds.ao = ao;
-srs->dds.domid = domid_soft_reset;
+srs->dds.domid = cdcs->dcs.domid_soft_reset;
 srs->dds.callback = domain_soft_reset_cb;
 srs->dds.soft_reset = true;
 libxl__domain_destroy(egc, &srs->dds);
-
-return AO_INPROGRESS;
-
- out:
-return AO_CREATE_FAIL(rc);
 }
 
 static void domain_create_cb(libxl__egc *egc,
diff --git a/tools/libxl/libxl_dom_suspend.c b/tools/libxl/libxl_dom_suspend.c
index 1e904bae8a..51c432a00a 100644
--- a/tools/libxl/libxl_dom_suspend.c
+++ b/tools/libxl/libxl_dom_suspend.c
@@ -68,9 +68,10 @@ out:
 
 /*- callbacks, called by xc_domain_save -*/
 
-int libxl__domain_suspend_device_model(libxl__gc *gc,
+int libxl__domain_suspend_device_model(libxl__egc *egc,
libxl__domain_suspend_state *dsps)
 {
+STATE_AO_GC(dsps->ao);
 int ret = 0;
 uint32_t const domid = dsps->domid;
 const char *const filename = dsps->dm_savefile;
@@ -94,6 +95,7 @@ int libxl__domain_suspend_device_model(libxl__gc *gc,
 return ERROR_INVAL;
 }
 
+dsps->callback_device_model_done(egc, dsps, ret);
 return ret;
 }
 
@@ -378,13 +380,15 @@ static void 
domain_suspend_common_guest_suspended(libxl__egc *egc,
 libxl__ev_time_deregister(gc, &dsps->guest_timeout);
 
 if (dsps->type == LIBXL_DOMAIN_TYPE_HVM) {
-rc = libxl__domain_suspend_device_model(gc, dsps);
+dsps->callback_device_model_done = domain_suspend_common_done;
+rc = libxl__domain_suspend_device_model(egc, dsps);
 if (rc) {
 LOGD(ERROR, dsps->domid,
  "libxl__domain_suspend_device_model failed ret=%d", rc);
 domain_suspend_common_done(egc, dsps, rc);
 return;
 }
+return;
 }
 domain_suspend_common_done(egc, dsps, 0);
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4fa54cdb6a..5b65cdbe40 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3408,6 +3408,8 @@ struct libxl__domain_suspend_state {
 libxl__ev_time guest_timeout;
 
 const char *dm_savefile;
+void (*callback_device_model_done)(libxl__egc*,
+ struct libxl__domain_suspend_state*, int ok);
 void (*callback_common_done)(libxl__egc*,
  struct libxl__domain_suspend_state*, int ok);
 };
@@ -4025,7 +4027,7 @@ static inline bool libxl__save_helper_inuse(const 
libxl__save_helper_state *shs)
 }
 
 /* Each time the dm needs to be saved, we must call suspend and then save */
-_hidden int libxl__domain_suspend_device_model(libxl__gc *gc,
+_hidden int libxl__domain_suspend_device_model(libxl__egc *egc,
   

[Xen-devel] [PATCH v4 11/32] libxl_dm: Add libxl__qemu_qmp_path()

[Anthony PERARD]

... which generate the path to a QMP socket that libxl uses.

Signed-off-by: Anthony PERARD 
---

Notes:
New in v4.

 tools/libxl/libxl_dm.c   | 9 +++--
 tools/libxl/libxl_internal.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index fdd7fa3ba4..5c28a0ced4 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -910,6 +910,11 @@ static char *qemu_disk_ide_drive_string(libxl__gc *gc, 
const char *target_path,
 return drive;
 }
 
+const char *libxl__qemu_qmp_path(libxl__gc *gc, int domid)
+{
+return GCSPRINTF("%s/qmp-libxl-%d", libxl__run_dir_path(), domid);
+}
+
 static int libxl__build_device_model_args_new(libxl__gc *gc,
 const char *dm, int guest_domid,
 const libxl_domain_config 
*guest_config,
@@ -946,8 +951,8 @@ static int libxl__build_device_model_args_new(libxl__gc *gc,
 flexarray_append(dm_args, "-chardev");
 flexarray_append(dm_args,
  GCSPRINTF("socket,id=libxl-cmd,"
-"path=%s/qmp-libxl-%d,server,nowait",
-libxl__run_dir_path(), guest_domid));
+   "path=%s,server,nowait",
+   libxl__qemu_qmp_path(gc, guest_domid)));
 
 flexarray_append(dm_args, "-no-shutdown");
 flexarray_append(dm_args, "-mon");
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 72ab177ce5..5b71a23d23 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4424,6 +4424,7 @@ static inline bool libxl__string_is_default(char **s)
 
 _hidden int libxl__prepare_sockaddr_un(libxl__gc *gc, struct sockaddr_un *un,
const char *path, const char *what);
+_hidden const char *libxl__qemu_qmp_path(libxl__gc *gc, int guest_domid);
 #endif
 
 /*
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 28/32] libxl_qmp: Store advertised QEMU version in libxl__ev_qmp

[Anthony PERARD]

This will be used in a later patch.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h |  7 +++
 tools/libxl/libxl_qmp.c  | 16 
 2 files changed, 23 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 01c3868748..4fa54cdb6a 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -432,6 +432,13 @@ struct libxl__ev_qmp {
 libxl__ev_qmp_callback *callback;
 libxl__carefd *cfd; /* set to send a fd with the command, NULL otherwise */
 
+/* read-only when Connected */
+struct {
+int major;
+int minor;
+int micro;
+} qemu_version;
+
 /* remaining fields are private to libxl_ev_qmp_* */
 
 int id;
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index d7aedb56a8..332dcf2069 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1444,12 +1444,28 @@ static int qmp_ev_handle_message(libxl__egc *egc,
  const libxl__json_object *resp)
 {
 EGC_GC;
+const libxl__json_object *o;
 libxl__qmp_message_type type = qmp_response_type(resp);
 
 switch (type) {
 case LIBXL__QMP_MESSAGE_TYPE_QMP:
 /* greeting message */
 assert(ev->qmp_state == qmp_state_connecting);
+
+/* Store advertised QEMU version */
+o = libxl__json_map_get("QMP", resp, JSON_MAP);
+o = libxl__json_map_get("version", o, JSON_MAP);
+o = libxl__json_map_get("qemu", o, JSON_MAP);
+ev->qemu_version.major = libxl__json_object_get_integer(
+libxl__json_map_get("major", o, JSON_INTEGER));
+ev->qemu_version.minor = libxl__json_object_get_integer(
+libxl__json_map_get("minor", o, JSON_INTEGER));
+ev->qemu_version.micro = libxl__json_object_get_integer(
+libxl__json_map_get("micro", o, JSON_INTEGER));
+LOGD(DEBUG, ev->domid, "QEMU version: %d.%d.%d",
+ ev->qemu_version.major, ev->qemu_version.minor,
+ ev->qemu_version.micro);
+
 ev->qmp_state = qmp_state_greeting;
 /* Allow qmp_ev_callback_writable to be called in order to send
  * qmp_capabilities */
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 14/32] libxl_qmp: Implement fd callback and read data

[Anthony PERARD]

First step into taking care of the input from QEMU's QMP socket. For
now, we read data and store them in a buffer.

Parsing of the data will be done in the following patches.

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
remove use of a linked list of receive buffer, and use realloc instead.

 tools/libxl/libxl_internal.h |   9 
 tools/libxl/libxl_qmp.c  | 101 +++
 2 files changed, 110 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 90ac48a659..8c3625a243 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -438,6 +438,15 @@ struct libxl__ev_qmp {
 libxl__carefd *qmp_cfd;
 libxl__ev_fd qmp_efd;
 libxl__qmp_state qmp_state;
+
+/* receive buffer, with:
+ * buf_size: current allocated size,
+ * buf_used: actual data in the buffer,
+ * buf_consumed: data already parsed.  */
+char *rx_buf;
+size_t buf_size;
+size_t buf_used;
+size_t buf_consumed;
 };
 
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 96a347dd3b..b0554df843 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -75,6 +75,12 @@
 #  define DEBUG_REPORT_RECEIVED(dom, buf, len) ((void)0)
 #endif
 
+#ifdef DEBUG_QMP_CLIENT
+#  define LOG_QMP(f, ...) LOGD(DEBUG, ev->domid, f, ##__VA_ARGS__)
+#else
+#  define LOG_QMP(f, ...)
+#endif
+
 /*
  * QMP types & constant
  */
@@ -1278,9 +1284,99 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
domid,
 
 /*  Implementation of libxl__ev_qmp  */
 
+/*
+ * QMP FD callbacks
+ */
+
+static int qmp_ev_callback_readable(libxl__egc *egc, libxl__ev_qmp *ev, int fd)
+{
+EGC_GC;
+ssize_t r;
+
+if (!ev->rx_buf) {
+ev->rx_buf = libxl__malloc(NOGC, QMP_RECEIVE_BUFFER_SIZE);
+ev->buf_size = QMP_RECEIVE_BUFFER_SIZE;
+ev->buf_used = 0;
+ev->buf_consumed = 0;
+}
+
+/* Check if last buffer still have space, or increase size */
+/* The -1 is because there is always space for a NUL character */
+if (ev->buf_used == ev->buf_size - 1) {
+ev->buf_size += QMP_RECEIVE_BUFFER_SIZE;
+ev->rx_buf = libxl__realloc(NOGC, ev->rx_buf, ev->buf_size);
+}
+
+for (;;) {
+/* The -1 is because there is always space for a NUL character */
+r = read(fd, ev->rx_buf + ev->buf_used,
+ ev->buf_size - ev->buf_used - 1);
+if (r < 0) {
+if (errno == EINTR) continue;
+assert(errno);
+if (errno == EWOULDBLOCK) {
+return 0;
+}
+LOGED(ERROR, ev->domid, "error reading QMP socket");
+return ERROR_FAIL;
+}
+break;
+}
+
+if (r == 0) {
+LOGD(ERROR, ev->domid, "No data read on QMP socket");
+return 0;
+}
+
+LOG_QMP("received %ldB: '%.*s'", r, (int)r, ev->rx_buf + ev->buf_used);
+
+ev->buf_used += r;
+assert(ev->buf_used < ev->buf_size);
+
+return 0;
+}
+
+static void qmp_ev_callback_error(libxl__egc *egc, libxl__ev_qmp *ev)
+{
+EGC_GC;
+
+LOGD(ERROR, ev->domid, "Error happend with the QMP connection to QEMU");
+
+/* On error, deallocate all private ressources */
+libxl__ev_qmp_dispose(gc, ev);
+}
+
 static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
int fd, short events, short revents)
 {
+EGC_GC;
+int rc;
+
+libxl__ev_qmp *ev = CONTAINER_OF(ev_fd, *ev, qmp_efd);
+
+if (revents & (POLLHUP)) {
+LOGD(DEBUG, ev->domid, "received POLLHUP from QMP socket");
+qmp_ev_callback_error(egc, ev);
+return;
+}
+if (revents & ~(POLLIN|POLLOUT)) {
+LOGD(ERROR, ev->domid,
+ "unexpected poll event 0x%x on QMP socket (expected POLLIN "
+ "and/or POLLOUT)",
+revents);
+qmp_ev_callback_error(egc, ev);
+return;
+}
+
+if (revents & POLLIN) {
+rc = qmp_ev_callback_readable(egc, ev, fd);
+if (rc)
+goto out;
+}
+out:
+if (rc) {
+qmp_ev_callback_error(egc, ev);
+}
 }
 
 static int qmp_ev_connect(libxl__gc *gc, libxl__ev_qmp *ev)
@@ -1346,6 +1442,8 @@ void libxl__ev_qmp_init(libxl__ev_qmp *ev)
 ev->qmp_cfd = NULL;
 libxl__ev_fd_init(&ev->qmp_efd);
 ev->qmp_state = qmp_state_disconnected;
+
+ev->rx_buf = NULL;
 }
 
 int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
@@ -1365,6 +1463,9 @@ void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp 
*ev)
 {
 LOGD(DEBUG, ev->domid, " ev %p", ev);
 
+free(ev->rx_buf);
+ev->rx_buf = NULL;
+
 libxl__ev_fd_deregister(gc, &ev->qmp_efd);
 libxl__carefd_close(ev->qmp_cfd);
 ev->qmp_cfd = NULL;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 16/32] libxl_json: libxl__json_object_to_json

[Anthony PERARD]

Allow to generate a JSON string from a libxl__json_object,
usefull for debugging.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h |  3 +++
 tools/libxl/libxl_json.c | 36 
 2 files changed, 39 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 8c3625a243..7f200e7a46 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2129,6 +2129,9 @@ _hidden void libxl__json_object_free(libxl__gc *gc_opt,
 
 _hidden libxl__json_object *libxl__json_parse(libxl__gc *gc_opt, const char 
*s);
 
+_hidden char *libxl__json_object_to_json(libxl__gc *gc,
+ const libxl__json_object *args);
+
   /* Based on /local/domain/$domid/dm-version xenstore key
* default is qemu xen traditional */
 _hidden int libxl__device_model_version_running(libxl__gc *gc, uint32_t domid);
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index b7f9077f0d..16cdd5bda3 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -1017,6 +1017,42 @@ out:
 return ret;
 }
 
+char *libxl__json_object_to_json(libxl__gc *gc,
+ const libxl__json_object *args)
+{
+const unsigned char *buf;
+libxl_yajl_length len;
+yajl_gen_status s;
+yajl_gen hand;
+char *ret = NULL;
+int rc;
+
+if (!args)
+return NULL;
+
+hand = libxl_yajl_gen_alloc(NULL);
+
+if (!hand) {
+return NULL;
+}
+
+rc = libxl__json_object_to_yajl_gen(gc, hand, args);
+if (rc)
+goto out;
+
+s = yajl_gen_get_buf(hand, &buf, &len);
+
+if (s) {
+goto out;
+}
+
+ret = libxl__strndup(gc, (const char *)buf, len);
+
+out:
+yajl_gen_free(hand);
+return ret;
+}
+
 yajl_gen_status libxl__uint64_gen_json(yajl_gen hand, uint64_t val)
 {
 char *num;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 17/32] libxl_qmp: Parse JSON input from QMP

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
simplification of the patch due to use of a single allocated space for 
the
receive buffer.

 tools/libxl/libxl_qmp.c | 54 +
 1 file changed, 54 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index b0554df843..665b6f5d05 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1292,6 +1292,7 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
libxl__ev_qmp *ev, int fd)
 {
 EGC_GC;
 ssize_t r;
+char *end = NULL;
 
 if (!ev->rx_buf) {
 ev->rx_buf = libxl__malloc(NOGC, QMP_RECEIVE_BUFFER_SIZE);
@@ -1333,6 +1334,59 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
libxl__ev_qmp *ev, int fd)
 ev->buf_used += r;
 assert(ev->buf_used < ev->buf_size);
 
+/* workaround strstr limitation */
+ev->rx_buf[ev->buf_used] = '\0';
+
+/*
+ * Search for the end of a QMP message: "\r\n" in the newly received
+ * bytes + the last byte on the previous read() if any
+ *
+ * end: This will point to the byte right after \r\n
+ */
+end = strstr(ev->rx_buf + ev->buf_used - r
+ + (ev->buf_used - r == 0 ? 0 : -1),
+ "\r\n");
+if (end)
+end += 2;
+
+while (end) {
+libxl__json_object *o;
+size_t len;
+char *s;
+
+/* Start parsing from s */
+s = ev->rx_buf + ev->buf_consumed;
+/* Findout how much can be parsed */
+len = end - s;
+
+LOG_QMP("parsing %luB: '%.*s'", len, (int)len, s);
+
+/* Replace \n by \0 so that libxl__json_parse can use strlen */
+s[len - 1] = '\0';
+o = libxl__json_parse(gc, s); //, len);
+
+if (!o) {
+LOGD(ERROR, ev->domid, "Parse error");
+return ERROR_FAIL;
+}
+
+ev->buf_consumed += len;
+
+if (ev->buf_consumed >= ev->buf_used) {
+free(ev->rx_buf);
+ev->rx_buf = NULL;
+}
+
+/* check if there is another message received at the same time */
+if (ev->rx_buf) {
+end = strstr(ev->rx_buf + ev->buf_consumed, "\r\n");
+if (end)
+end += 2;
+} else
+end = NULL;
+
+LOG_QMP("JSON object received: %s", libxl__json_object_to_json(gc, o));
+}
 return 0;
 }
 
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 19/32] libxl_qmp: Prepare the command to be sent

[Anthony PERARD]

The actual sent will be done in a separate patch.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h |  4 
 tools/libxl/libxl_qmp.c  | 37 
 2 files changed, 41 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 7f200e7a46..110b951bbe 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -438,6 +438,7 @@ struct libxl__ev_qmp {
 libxl__carefd *qmp_cfd;
 libxl__ev_fd qmp_efd;
 libxl__qmp_state qmp_state;
+unsigned int last_id_used;
 
 /* receive buffer, with:
  * buf_size: current allocated size,
@@ -447,6 +448,9 @@ struct libxl__ev_qmp {
 size_t buf_size;
 size_t buf_used;
 size_t buf_consumed;
+
+char *tx_buf;
+size_t tx_buf_len;
 };
 
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 38a4395266..2792f35912 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1310,6 +1310,25 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
domid,
 
 /*  Implementation of libxl__ev_qmp  */
 
+static int qmp_ev_prepare_cmd(libxl__gc *gc,
+  libxl__ev_qmp *ev,
+  const char *cmd,
+  const libxl__json_object *args)
+{
+char *buf = NULL;
+size_t len;
+
+buf = qmp_prepare_qmp_cmd(gc, cmd, args, ++ev->last_id_used, &len);
+if (!buf)
+return ERROR_FAIL;
+
+ev->id = ev->last_id_used;
+ev->tx_buf = buf;
+ev->tx_buf_len = len;
+
+return 0;
+}
+
 /*
  * QMP FD callbacks
  */
@@ -1424,6 +1443,9 @@ static void qmp_ev_callback_error(libxl__egc *egc, 
libxl__ev_qmp *ev)
 
 /* On error, deallocate all private ressources */
 libxl__ev_qmp_dispose(gc, ev);
+
+ev->id = -1;
+ev->callback(egc, ev, NULL, ERROR_FAIL);
 }
 
 static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
@@ -1522,8 +1544,10 @@ void libxl__ev_qmp_init(libxl__ev_qmp *ev)
 ev->qmp_cfd = NULL;
 libxl__ev_fd_init(&ev->qmp_efd);
 ev->qmp_state = qmp_state_disconnected;
+ev->last_id_used = 0;
 
 ev->rx_buf = NULL;
+ev->tx_buf = NULL;
 }
 
 int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
@@ -1535,7 +1559,17 @@ int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
 
 /* Connect to QEMU if not already connected */
 rc = qmp_ev_connect(gc, ev);
+if (rc)
+goto out;
+
+rc = qmp_ev_prepare_cmd(gc, ev, cmd, args);
+if (rc)
+goto out;
+
 
+out:
+if (rc)
+libxl__ev_qmp_dispose(gc, ev);
 return rc;
 }
 
@@ -1546,6 +1580,9 @@ void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp 
*ev)
 free(ev->rx_buf);
 ev->rx_buf = NULL;
 
+free(ev->tx_buf);
+ev->tx_buf = NULL;
+
 libxl__ev_fd_deregister(gc, &ev->qmp_efd);
 libxl__carefd_close(ev->qmp_cfd);
 ev->qmp_cfd = NULL;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 18/32] libxl_qmp: Separate QMP message generation from qmp_send_prepare

[Anthony PERARD]

To be able to re-use qmp_prepare_qmp_cmd with libxl__ev_qmp.

Also, add the QMP end of command '\r\n' into the generated string.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_qmp.c | 62 +
 1 file changed, 44 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 665b6f5d05..38a4395266 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -578,17 +578,17 @@ static int qmp_next(libxl__gc *gc, libxl__qmp_handler 
*qmp)
 return rc;
 }
 
-static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
-  const char *cmd, libxl__json_object *args,
-  qmp_callback_t callback, void *opaque,
-  qmp_request_context *context)
-{
-const unsigned char *buf = NULL;
-char *ret = NULL;
-libxl_yajl_length len = 0;
+static char *qmp_prepare_qmp_cmd(libxl__gc *gc,
+ const char *cmd,
+ const libxl__json_object *args,
+ int id,
+ size_t *len_r)
+{
+const unsigned char *buf;
+libxl_yajl_length len;
 yajl_gen_status s;
 yajl_gen hand;
-callback_id_pair *elm = NULL;
+char *ret = NULL;
 
 hand = libxl_yajl_gen_alloc(NULL);
 
@@ -600,7 +600,7 @@ static char *qmp_send_prepare(libxl__gc *gc, 
libxl__qmp_handler *qmp,
 libxl__yajl_gen_asciiz(hand, "execute");
 libxl__yajl_gen_asciiz(hand, cmd);
 libxl__yajl_gen_asciiz(hand, "id");
-yajl_gen_integer(hand, ++qmp->last_id_used);
+yajl_gen_integer(hand, id);
 if (args) {
 libxl__yajl_gen_asciiz(hand, "arguments");
 libxl__json_object_to_yajl_gen(gc, hand, args);
@@ -610,6 +610,36 @@ static char *qmp_send_prepare(libxl__gc *gc, 
libxl__qmp_handler *qmp,
 s = yajl_gen_get_buf(hand, &buf, &len);
 
 if (s) {
+goto out;
+}
+
+ret = libxl__malloc(NOGC, len + 3);
+strncpy(ret, (const char *)buf, len + 3);
+strncpy(ret + len, "\r\n", 3);
+len += 2;
+
+if (len_r)
+*len_r = len;
+
+out:
+yajl_gen_free(hand);
+return ret;
+}
+
+static char *qmp_send_prepare(libxl__gc *gc, libxl__qmp_handler *qmp,
+  const char *cmd, libxl__json_object *args,
+  qmp_callback_t callback, void *opaque,
+  qmp_request_context *context,
+  size_t *len_r)
+{
+char *buf;
+callback_id_pair *elm;
+
+buf = qmp_prepare_qmp_cmd(gc,
+  cmd, args, ++qmp->last_id_used,
+  NULL);
+
+if (!buf) {
 LOGD(ERROR, qmp->domid, "Failed to generate a qmp command");
 goto out;
 }
@@ -625,13 +655,10 @@ static char *qmp_send_prepare(libxl__gc *gc, 
libxl__qmp_handler *qmp,
 elm->context = context;
 LIBXL_STAILQ_INSERT_TAIL(&qmp->callback_list, elm, next);
 
-ret = libxl__strndup(gc, (const char*)buf, len);
-
 LOGD(DEBUG, qmp->domid, "next qmp command: '%s'", buf);
 
 out:
-yajl_gen_free(hand);
-return ret;
+return buf;
 }
 
 static int qmp_send(libxl__qmp_handler *qmp,
@@ -643,7 +670,8 @@ static int qmp_send(libxl__qmp_handler *qmp,
 int rc = -1;
 GC_INIT(qmp->ctx);
 
-buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context);
+buf = qmp_send_prepare(gc, qmp, cmd, args, callback, opaque, context,
+   NULL);
 
 if (buf == NULL) {
 goto out;
@@ -652,12 +680,10 @@ static int qmp_send(libxl__qmp_handler *qmp,
 if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, buf, strlen(buf),
 "QMP command", "QMP socket"))
 goto out;
-if (libxl_write_exactly(qmp->ctx, qmp->qmp_fd, "\r\n", 2,
-"CRLF", "QMP socket"))
-goto out;
 
 rc = qmp->last_id_used;
 out:
+free(buf);
 GC_FREE;
 return rc;
 }
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 27/32] libxl: QEMU startup sync based on QMP

[Anthony PERARD]

This is only activated when dm_restrict=1, as explained in the previous
patch "libxl_dm: Pre-open QMP socket for QEMU"

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
moved to libxl__dm_spawn_* from libxl__spawn_*

 tools/libxl/libxl_dm.c   | 52 
 tools/libxl/libxl_internal.h |  1 +
 2 files changed, 53 insertions(+)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 9e3e501457..0c11e96a5d 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -2290,6 +2290,8 @@ static void device_model_startup_failed(libxl__egc *egc,
 int rc);
 static void device_model_detached(libxl__egc *egc,
   libxl__spawn_state *spawn);
+static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response, int rc);
 
 /* our "next step" function, called from those callbacks and elsewhere */
 static void device_model_spawn_outcome(libxl__egc *egc,
@@ -2421,6 +2423,17 @@ retry_transaction:
 spawn->failure_cb = device_model_startup_failed;
 spawn->detached_cb = device_model_detached;
 
+libxl__ev_qmp_init(&dmss->qmp);
+if (dm_monitor_fd >= 0) {
+/* There is a valid QMP socket available now,
+ * use it to find out when QEMU is ready */
+dmss->qmp.callback = device_model_qmp_cb;
+dmss->qmp.domid = domid;
+dmss->qmp.cfd = NULL;
+rc = libxl__ev_qmp_send(gc, &dmss->qmp, "query-status", NULL);
+if (rc) goto out_close;
+}
+
 rc = libxl__spawn_spawn(egc, spawn);
 if (rc < 0)
 goto out_close;
@@ -2490,6 +2503,43 @@ static void device_model_detached(libxl__egc *egc,
 device_model_spawn_outcome(egc, dmss, 0);
 }
 
+static void device_model_qmp_cb(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+int rc)
+{
+EGC_GC;
+libxl__dm_spawn_state *dmss = CONTAINER_OF(ev, *dmss, qmp);
+const libxl__json_object *o;
+const char *status;
+
+libxl__ev_qmp_dispose(gc, ev);
+
+if (rc)
+goto failed;
+
+o = libxl__json_map_get("status", response, JSON_STRING);
+if (!o) {
+LOGD(DEBUG, ev->domid, "QMP unexpected response");
+rc = ERROR_FAIL;
+goto failed;
+}
+status = libxl__json_object_get_string(o);
+if (!strcmp(status, "running")) {
+/* success */
+} else {
+LOGD(DEBUG, ev->domid, "Unexpected QEMU status: %s", status);
+rc = ERROR_FAIL;
+goto failed;
+}
+
+libxl__spawn_initiate_detach(gc, &dmss->spawn);
+return;
+
+failed:
+LOGD(ERROR, ev->domid, "QEMU did not start properly, rc=%d", rc);
+libxl__spawn_initiate_failure(gc, &dmss->spawn, rc);
+}
+
 static void device_model_spawn_outcome(libxl__egc *egc,
libxl__dm_spawn_state *dmss,
int rc)
@@ -2513,6 +2563,8 @@ static void device_model_spawn_outcome(libxl__egc *egc,
 }
 }
 
+libxl__ev_qmp_dispose(gc, &dmss->qmp);
+
  out:
 dmss->callback(egc, dmss, rc);
 }
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index b94657a7f0..01c3868748 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3893,6 +3893,7 @@ struct libxl__dm_spawn_state {
 libxl_domain_config *guest_config;
 libxl__domain_build_state *build_state; /* relates to guest_domid */
 libxl__dm_spawn_cb *callback;
+libxl__ev_qmp qmp;
 };
 
 _hidden void libxl__spawn_local_dm(libxl__egc *egc, libxl__dm_spawn_state*);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 15/32] libxl_json: Enable yajl_allow_trailing_garbage

[Anthony PERARD]

This allow to parse a string that is not NUL-terminated. With that
options disabled, YAJL v2 would look ahead on completion to find out if
there is more to parse.

YAJL v1 doesn't have this behavior.

Any function function that allocate a yajl_handle via this function
either parse a NUL-terminated string, or do provide proper length. So
change the default and allow garbage (like a different JSON document)
after the end of the data to parse.

This is importand for the QMP client, as there could be more than one
message to parse, and YAJL would consider the next message to be
garbage and throw an error.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_json.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_json.h b/tools/libxl/libxl_json.h
index af26e7885d..260783bfde 100644
--- a/tools/libxl/libxl_json.h
+++ b/tools/libxl/libxl_json.h
@@ -50,7 +50,10 @@ static inline yajl_handle libxl__yajl_alloc(const 
yajl_callbacks *callbacks,
 yajl_alloc_funcs *allocFuncs,
 void *ctx)
 {
-return yajl_alloc(callbacks, allocFuncs, ctx);
+yajl_handle hand = yajl_alloc(callbacks, allocFuncs, ctx);
+if (hand)
+yajl_config(hand, yajl_allow_trailing_garbage, 1);
+return hand;
 }
 
 static inline yajl_gen libxl_yajl_gen_alloc(const yajl_alloc_funcs *allocFuncs)
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 26/32] libxl_dm: Pre-open QMP socket for QEMU

[Anthony PERARD]

When starting QEMU with dm_restrict=1, pre-open the QMP socket before
exec QEMU. That socket will be usefull to findout if QEMU is ready, and
pre-opening it means that libxl can connect to it without waiting for
QEMU to create it.

The pre-openning is conditionnal, based on the use of dm_restrict
because it is using a new command line option of QEMU, and dm_restrict
support in QEMU is newer.

-chardev socket,fd=X is available with QEMU 2.12, since commit:
> char: allow passing pre-opened socket file descriptor at startup
> 0935700f8544033ebbd41e1f13cd528f8a58d24d

dm_restrict will be available in QEMU 3.0.

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
separate the logic to open a socket into a function.
Use libxl__prepare_sockaddr_un() to check path size

 tools/libxl/libxl_dm.c | 86 +-
 1 file changed, 77 insertions(+), 9 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 5c28a0ced4..9e3e501457 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -24,6 +24,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
@@ -915,12 +917,58 @@ const char *libxl__qemu_qmp_path(libxl__gc *gc, int domid)
 return GCSPRINTF("%s/qmp-libxl-%d", libxl__run_dir_path(), domid);
 }
 
+static int libxl__pre_open_qmp_socket(libxl__gc *gc, int domid, int *fd_r)
+{
+int rc;
+int fd = -1;
+struct sockaddr_un un;
+const char *path;
+
+path = libxl__qemu_qmp_path(gc, domid);
+
+fd = socket(AF_UNIX, SOCK_STREAM, 0);
+if (fd < 0) {
+LOGED(ERROR, domid, "socket() failed");
+return ERROR_FAIL;
+}
+
+rc = libxl__prepare_sockaddr_un(gc, &un, path, "QEMU's QMP socket");
+if (rc)
+goto out;
+
+if (unlink(path) < 0 && errno != ENOENT) {
+LOGED(ERROR, domid, "unlink('%s') failed", path);
+rc = ERROR_FAIL;
+goto out;
+}
+
+if (bind(fd, (struct sockaddr*) &un, sizeof(un)) < 0) {
+LOGED(ERROR, domid, "bind('%s') failed", path);
+rc = ERROR_FAIL;
+goto out;
+}
+
+if (listen(fd, 1) < 0) {
+LOGED(ERROR, domid, "listen() failed");
+rc = ERROR_FAIL;
+goto out;
+}
+
+*fd_r = fd;
+rc = 0;
+
+out:
+if (rc && fd >= 0)
+close(fd);
+return rc;
+}
+
 static int libxl__build_device_model_args_new(libxl__gc *gc,
 const char *dm, int guest_domid,
 const libxl_domain_config 
*guest_config,
 char ***args, char ***envs,
 const libxl__domain_build_state *state,
-int *dm_state_fd)
+int *dm_state_fd, int *dm_monitor_fd)
 {
 const libxl_domain_create_info *c_info = &guest_config->c_info;
 const libxl_domain_build_info *b_info = &guest_config->b_info;
@@ -949,10 +997,25 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
   GCSPRINTF("%d", guest_domid), NULL);
 
 flexarray_append(dm_args, "-chardev");
-flexarray_append(dm_args,
- GCSPRINTF("socket,id=libxl-cmd,"
-   "path=%s,server,nowait",
-   libxl__qemu_qmp_path(gc, guest_domid)));
+/* If we have to use dm_restrict, QEMU need to be new enough and will have
+ * the new interface where we can pre-open the QMP socket. */
+if (libxl_defbool_val(b_info->dm_restrict))
+{
+int rc;
+
+rc = libxl__pre_open_qmp_socket(gc, guest_domid, dm_monitor_fd);
+if (rc)
+return rc;
+
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,fd=%d,server,nowait",
+   *dm_monitor_fd));
+} else {
+flexarray_append(dm_args,
+ GCSPRINTF("socket,id=libxl-cmd,"
+   "path=%s,server,nowait",
+   libxl__qemu_qmp_path(gc, guest_domid)));
+}
 
 flexarray_append(dm_args, "-no-shutdown");
 flexarray_append(dm_args, "-mon");
@@ -1731,7 +1794,8 @@ static int libxl__build_device_model_args(libxl__gc *gc,
 const libxl_domain_config 
*guest_config,
 char ***args, char ***envs,
 const libxl__domain_build_state *state,
-int *dm_state_fd)
+int *dm_state_fd,
+int *dm_monitor_fd)
 /* dm_state_fd may be NULL iff caller knows we are using old stubdom
  * and therefore will be passing a filename rather than a fd. */
 {
@@ -1744,10 +1808,11 @@ static int libxl__build_device_model_args(libxl__gc

[Xen-devel] [PATCH v4 23/32] libxl_qmp: Respond to QMP greeting

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_qmp.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index e649b8054d..83afce3192 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1309,6 +1309,9 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
domid,
 
 /*  Implementation of libxl__ev_qmp  */
 
+/* hard coded message ID used for capability negociation */
+static int qmp_capability_negociation_msgid = 1;
+
 static int qmp_ev_prepare_cmd(libxl__gc *gc,
   libxl__ev_qmp *ev,
   const char *cmd,
@@ -1379,7 +1382,7 @@ static int qmp_ev_handle_response(libxl__egc *egc,
 }
 
 id = libxl__json_object_get_integer(o);
-if (id != ev->id)
+if (id != ev->id && id != qmp_capability_negociation_msgid)
 return 0;
 
 switch (type) {
@@ -1413,9 +1416,21 @@ static int qmp_ev_handle_response(libxl__egc *egc,
 abort();
 }
 
-ev->id = -1;
-ev->callback(egc, ev, response, rc); /* must be last */
-return 1;
+/*
+ * Even if the current state is capability_negociation and the correct ID
+ * as been received, call the callback on error.
+ */
+if (ev->qmp_state == qmp_state_capability_negociation &&
+id == qmp_capability_negociation_msgid &&
+rc == 0) {
+ev->qmp_state = qmp_state_connected;
+libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events | POLLOUT);
+return 0;
+} else {
+ev->id = -1;
+ev->callback(egc, ev, response, rc); /* must be last */
+return 1;
+}
 }
 
 /* return 1 when a user callback as been called */
@@ -1429,6 +1444,11 @@ static int qmp_ev_handle_message(libxl__egc *egc,
 switch (type) {
 case LIBXL__QMP_MESSAGE_TYPE_QMP:
 /* greeting message */
+assert(ev->qmp_state == qmp_state_connecting);
+ev->qmp_state = qmp_state_greeting;
+/* Allow qmp_ev_callback_writable to be called in order to send
+ * qmp_capabilities */
+libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events | POLLOUT);
 return 0;
 case LIBXL__QMP_MESSAGE_TYPE_RETURN:
 case LIBXL__QMP_MESSAGE_TYPE_ERROR:
@@ -1563,7 +1583,11 @@ static int qmp_ev_callback_writable(libxl__gc *gc, 
libxl__ev_qmp *ev, int fd)
  * be send for now will be in this call. */
 libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events & ~POLLOUT);
 
-if (ev->qmp_state == qmp_state_connected) {
+if (ev->qmp_state == qmp_state_greeting) {
+buf = qmp_prepare_qmp_cmd(gc, "qmp_capabilities", NULL,
+  qmp_capability_negociation_msgid, &len);
+ev->qmp_state = qmp_state_capability_negociation;
+} else if (ev->qmp_state == qmp_state_connected) {
 if (!ev->tx_buf)
 return 0;
 
@@ -1703,7 +1727,7 @@ void libxl__ev_qmp_init(libxl__ev_qmp *ev)
 ev->qmp_cfd = NULL;
 libxl__ev_fd_init(&ev->qmp_efd);
 ev->qmp_state = qmp_state_disconnected;
-ev->last_id_used = 0;
+ev->last_id_used = qmp_capability_negociation_msgid + 1;
 
 ev->rx_buf = NULL;
 ev->tx_buf = NULL;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 32/32] libxl_disk: Have libxl_cdrom_insert use libxl__ev_qmp

[Anthony PERARD]

So when QEMU is involve, the operation will be asynchrone and will
finish later.

This path reimplement libxl__qmp_insert_cdrom to make use of the new
libxl__ev_qmp API.  It also open the cdrom in libxl and send the FD via
QMP, so QEMU doesn't need access permition on the cdrom file.

libxl__qmp_insert_cdrom() is now async, libxl_cdrom_insert() is updated
to make use of it.

Signed-off-by: Anthony PERARD 
---

Notes:
v4:
switch to the updated libxl__ev_qmp API

 tools/libxl/libxl_disk.c |  42 +
 tools/libxl/libxl_internal.h |  14 -
 tools/libxl/libxl_qmp.c  | 117 +--
 3 files changed, 142 insertions(+), 31 deletions(-)

diff --git a/tools/libxl/libxl_disk.c b/tools/libxl/libxl_disk.c
index c759179628..eb086ed909 100644
--- a/tools/libxl/libxl_disk.c
+++ b/tools/libxl/libxl_disk.c
@@ -672,11 +672,14 @@ typedef struct {
 int dm_ver;
 int domid;
 libxl__domain_userdata_lock *lock;
+libxl__qmp_insert_cdrom_state qics;
 } libxl__cdrom_insert_state;
 static void cdrom_insert_ejected(libxl__egc *egc,
- libxl__cdrom_insert_state *cis);
+ libxl__qmp_insert_cdrom_state  *qics,
+ int rc);
 static void cdrom_insert_inserted(libxl__egc *egc,
-  libxl__cdrom_insert_state *cis);
+  libxl__qmp_insert_cdrom_state *qics,
+  int rc);
 static void cdrom_insert_done(libxl__egc *egc,
   libxl__cdrom_insert_state *cis,
   int rc);
@@ -777,12 +780,16 @@ int libxl_cdrom_insert(libxl_ctx *ctx, uint32_t domid, 
libxl_device_disk *disk,
  * by inserting empty media. JSON is not updated.
  */
 if (cis->dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-rc = libxl__qmp_insert_cdrom(gc, domid, disk_empty);
+libxl__qmp_insert_cdrom_state *qics = &cis->qics;
+qics->domid = domid;
+qics->disk = disk_empty;
+qics->callback = cdrom_insert_ejected;
+rc = libxl__qmp_insert_cdrom(gc, qics);
 if (rc) goto out;
+} else {
+cdrom_insert_ejected(egc, &cis->qics, 0);
 }
 
-cdrom_insert_ejected(egc, cis);
-
 return AO_INPROGRESS;
 
 out:
@@ -794,11 +801,12 @@ out:
 }
 
 static void cdrom_insert_ejected(libxl__egc *egc,
- libxl__cdrom_insert_state *cis)
+ libxl__qmp_insert_cdrom_state *qics,
+ int rc)
 {
+libxl__cdrom_insert_state *cis = CONTAINER_OF(qics, *cis, qics);
 STATE_AO_GC(cis->ao);
 uint32_t domid = cis->domid;
-int rc;
 const char *be_path, *libxl_path;
 char * tmp;
 xs_transaction_t t = XBT_NULL;
@@ -808,6 +816,9 @@ static void cdrom_insert_ejected(libxl__egc *egc,
 libxl_device_disk *disk = cis->disk;
 libxl_device_disk *disk_saved = &cis->disk_saved;
 
+if (rc)
+goto out;
+
 be_path = cis->be_path;
 libxl_path = cis->libxl_path;
 
@@ -851,12 +862,15 @@ static void cdrom_insert_ejected(libxl__egc *egc,
 if (rc) goto out;
 
 if (cis->dm_ver == LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN) {
-rc = libxl__qmp_insert_cdrom(gc, domid, disk);
+qics->domid = domid;
+qics->disk = disk;
+qics->callback = cdrom_insert_inserted;
+rc = libxl__qmp_insert_cdrom(gc, qics);
 if (rc) goto out;
+} else {
+cdrom_insert_inserted(egc, qics, 0);
 }
 
-cdrom_insert_inserted(egc, cis);
-
 return;
 
 out:
@@ -865,11 +879,12 @@ out:
 }
 
 static void cdrom_insert_inserted(libxl__egc *egc,
-  libxl__cdrom_insert_state *cis)
+  libxl__qmp_insert_cdrom_state *qics,
+  int rc)
 {
+libxl__cdrom_insert_state *cis = CONTAINER_OF(qics, *cis, qics);
 STATE_AO_GC(cis->ao);
 uint32_t domid = cis->domid;
-int rc;
 const char *be_path, *libxl_path;
 char * tmp;
 xs_transaction_t t = XBT_NULL;
@@ -880,6 +895,9 @@ static void cdrom_insert_inserted(libxl__egc *egc,
 be_path = cis->be_path;
 libxl_path = cis->libxl_path;
 
+if (rc)
+goto out;
+
 insert = flexarray_make(gc, 4, 1);
 flexarray_append_pair(insert, "type",
   libxl__device_disk_string_of_backend(disk->backend));
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index cafe8b5733..6b6ac65d00 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1948,7 +1948,19 @@ _hidden int libxl__qmp_resume(libxl__gc *gc, int domid);
 _hidden int libxl__qmp_restore(libxl__gc *gc, int domid, const char *filename);
 /* Set dirty bitmap logging status */
 _hidden int libxl__qmp_set_global_dirty_log(libxl__gc *gc, int domid, bool 
enable);
-_hidden int libxl__qmp_insert_cdrom(libxl__gc

[Xen-devel] [PATCH v4 24/32] libxl_qmp: Disable beautify for QMP generated cmd

[Anthony PERARD]

There is no need for it.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_qmp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 83afce3192..d7aedb56a8 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -595,6 +595,11 @@ static char *qmp_prepare_qmp_cmd(libxl__gc *gc,
 return NULL;
 }
 
+#if HAVE_YAJL_V2
+/* Disable beautify for data sent to QEMU */
+yajl_gen_config(hand, yajl_gen_beautify, 0);
+#endif
+
 yajl_gen_map_open(hand);
 libxl__yajl_gen_asciiz(hand, "execute");
 libxl__yajl_gen_asciiz(hand, cmd);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 21/32] libxl_qmp: Simplify qmp_response_type() prototype

[Anthony PERARD]

Remove the libxl__qmp_handler* argument so the function can be reused
later in a different context.

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_qmp.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 75f953d521..aabf9ad5e7 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -279,8 +279,7 @@ static int enable_qmp_capabilities(libxl__qmp_handler *qmp)
  * Helpers
  */
 
-static libxl__qmp_message_type qmp_response_type(libxl__qmp_handler *qmp,
- const libxl__json_object *o)
+static libxl__qmp_message_type qmp_response_type(const libxl__json_object *o)
 {
 libxl__qmp_message_type type;
 libxl__json_map_node *node = NULL;
@@ -346,7 +345,7 @@ static int qmp_handle_response(libxl__gc *gc, 
libxl__qmp_handler *qmp,
 {
 libxl__qmp_message_type type = LIBXL__QMP_MESSAGE_TYPE_INVALID;
 
-type = qmp_response_type(qmp, resp);
+type = qmp_response_type(resp);
 LOGD(DEBUG, qmp->domid, "message type: %s", 
libxl__qmp_message_type_to_string(type));
 
 switch (type) {
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 10/32] libxl_json: constify libxl__json_object_to_yajl_gen arguments

[Anthony PERARD]

Signed-off-by: Anthony PERARD 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h | 2 +-
 tools/libxl/libxl_json.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index ab1de80522..72ab177ce5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -2031,7 +2031,7 @@ _hidden const libxl__json_object 
*libxl__json_map_get(const char *key,
   libxl__json_node_type expected_type);
 _hidden yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc_opt,
yajl_gen hand,
-   libxl__json_object *param);
+   const libxl__json_object 
*param);
 _hidden void libxl__json_object_free(libxl__gc *gc_opt,
  libxl__json_object *obj);
 
diff --git a/tools/libxl/libxl_json.c b/tools/libxl/libxl_json.c
index dc93a88ef1..b7f9077f0d 100644
--- a/tools/libxl/libxl_json.c
+++ b/tools/libxl/libxl_json.c
@@ -612,7 +612,7 @@ const libxl__json_object *libxl__json_map_get(const char 
*key,
 
 yajl_status libxl__json_object_to_yajl_gen(libxl__gc *gc,
yajl_gen hand,
-   libxl__json_object *obj)
+   const libxl__json_object *obj)
 {
 int idx = 0;
 yajl_status rc;
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 25/32] libxl_exec: Add libxl__spawn_initiate_failure

[Anthony PERARD]

This function can be use by user libxl__spawn_* when they setup a
notification other than xenstore. The parent can already called success
via libxl__spawn_initiate_detach(), this new function can be used for
failure instead of waiting for the timeout.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_exec.c |  7 +++
 tools/libxl/libxl_internal.h | 21 -
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_exec.c b/tools/libxl/libxl_exec.c
index 02e6c917f0..fb9621b10a 100644
--- a/tools/libxl/libxl_exec.c
+++ b/tools/libxl/libxl_exec.c
@@ -373,6 +373,13 @@ void libxl__spawn_initiate_detach(libxl__gc *gc, 
libxl__spawn_state *ss)
 spawn_detach(gc, ss);
 }
 
+void libxl__spawn_initiate_failure(libxl__gc *gc, libxl__spawn_state *ss, int 
rc)
+{
+assert(rc);
+ss->rc = rc;
+spawn_detach(gc, ss);
+}
+
 static void spawn_fail(libxl__egc *egc, libxl__spawn_state *ss, int rc)
 /* Caller must have logged.  Must be last thing in calling function,
  * as it may make the callback.  Precondition: Attached or Detaching. */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 110b951bbe..b94657a7f0 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1551,7 +1551,8 @@ _hidden void libxl__spawn_init(libxl__spawn_state*);
  *
  * The inner child must soon exit or exec.  It must also soon exit or
  * notify the parent of its successful startup by writing to the
- * xenstore path xspath.
+ * xenstore path xspath OR via other mean that the parent will have
+ * to setup.
  *
  * The user (in the parent) will be called back (confirm_cb) every
  * time that xenstore path is modified.
@@ -1607,6 +1608,24 @@ _hidden int libxl__spawn_spawn(libxl__egc *egc, 
libxl__spawn_state *spawn);
  */
 _hidden void libxl__spawn_initiate_detach(libxl__gc *gc, libxl__spawn_state*);
 
+/*
+ * libxl__spawn_initiate_failure - Propagate failure from the caller to the
+ * callee.
+ *
+ * Works by killing the intermediate process from spawn_spawn.
+ * After this function returns, failures will be reported via failure_cb.
+ *
+ * This is not synchronous: there will be a further callback when
+ * the detach is complete.
+ *
+ * Logs errors.
+ *
+ * The spawn state must be Attached entry and will be Attached Failed
+ * on return.
+ */
+_hidden void libxl__spawn_initiate_failure(libxl__gc *gc,
+   libxl__spawn_state *ss, int rc);
+
 /*
  * If successful, this should return 0.
  *
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 20/32] libxl_qmp: Handle write to QMP socket

[Anthony PERARD]

The libxl__ev_qmp_* will now send the command to QEMU when the socket is
ready for writes.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_qmp.c | 44 +
 1 file changed, 44 insertions(+)

diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index 2792f35912..75f953d521 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1326,6 +1326,8 @@ static int qmp_ev_prepare_cmd(libxl__gc *gc,
 ev->tx_buf = buf;
 ev->tx_buf_len = len;
 
+libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events | POLLOUT);
+
 return 0;
 }
 
@@ -1435,6 +1437,43 @@ static int qmp_ev_callback_readable(libxl__egc *egc, 
libxl__ev_qmp *ev, int fd)
 return 0;
 }
 
+static int qmp_ev_callback_writable(libxl__gc *gc, libxl__ev_qmp *ev, int fd)
+{
+int rc;
+char *buf;
+size_t len;
+int buf_fd = -1;
+
+/* No need to call qmp_ev_callback_writable again, everything that needs to
+ * be send for now will be in this call. */
+libxl__ev_fd_modify(gc, &ev->qmp_efd, ev->qmp_efd.events & ~POLLOUT);
+
+if (ev->qmp_state == qmp_state_connected) {
+if (!ev->tx_buf)
+return 0;
+
+buf = ev->tx_buf;
+len = ev->tx_buf_len;
+buf_fd = libxl__carefd_fd(ev->cfd);
+
+ev->tx_buf = NULL;
+} else {
+return 0;
+}
+
+LOG_QMP("sending: '%.*s'", (int)len, buf);
+
+if (buf_fd >= 0) {
+rc = libxl__sendmsg_fds(gc, fd, buf, len, 1, &buf_fd, "QMP socket");
+} else {
+rc = libxl_write_exactly(CTX, fd, buf, len,
+ "QMP command", "QMP socket");
+}
+
+free(buf);
+return rc;
+}
+
 static void qmp_ev_callback_error(libxl__egc *egc, libxl__ev_qmp *ev)
 {
 EGC_GC;
@@ -1470,6 +1509,11 @@ static void qmp_ev_fd_callback(libxl__egc *egc, 
libxl__ev_fd *ev_fd,
 return;
 }
 
+if (revents & POLLOUT) {
+rc = qmp_ev_callback_writable(gc, ev, fd);
+if (rc)
+goto out;
+}
 if (revents & POLLIN) {
 rc = qmp_ev_callback_readable(egc, ev, fd);
 if (rc)
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 13/32] libxl_qmp: Connect to QMP socket

[Anthony PERARD]

This is a first patch to implement libxl__ev_qmp, it only connect to the
QMP socket of QEMU and register a fd callback that does nothing.

Callback functions will be implemented in following patches.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h | 11 +
 tools/libxl/libxl_qmp.c  | 96 
 2 files changed, 107 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index c453ac10a5..90ac48a659 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -417,6 +417,14 @@ _hidden int libxl__ev_qmp_send(libxl__gc *gc, 
libxl__ev_qmp *ev,
const char *cmd, libxl__json_object *args);
 _hidden void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev);
 
+typedef enum {
+qmp_state_disconnected = 1,
+qmp_state_connecting,
+qmp_state_greeting,
+qmp_state_capability_negociation,
+qmp_state_connected,
+} libxl__qmp_state;
+
 struct libxl__ev_qmp {
 /* caller should include this in their own struct */
 /* caller must fill these in, and they must all remain valid */
@@ -427,6 +435,9 @@ struct libxl__ev_qmp {
 /* remaining fields are private to libxl_ev_qmp_* */
 
 int id;
+libxl__carefd *qmp_cfd;
+libxl__ev_fd qmp_efd;
+libxl__qmp_state qmp_state;
 };
 
 
diff --git a/tools/libxl/libxl_qmp.c b/tools/libxl/libxl_qmp.c
index c5e05e5679..96a347dd3b 100644
--- a/tools/libxl/libxl_qmp.c
+++ b/tools/libxl/libxl_qmp.c
@@ -1276,6 +1276,102 @@ int libxl__qmp_initializations(libxl__gc *gc, uint32_t 
domid,
 return ret;
 }
 
+/*  Implementation of libxl__ev_qmp  */
+
+static void qmp_ev_fd_callback(libxl__egc *egc, libxl__ev_fd *ev_fd,
+   int fd, short events, short revents)
+{
+}
+
+static int qmp_ev_connect(libxl__gc *gc, libxl__ev_qmp *ev)
+{
+int rc, r;
+struct sockaddr_un un;
+const char *qmp_socket_path;
+
+if (ev->qmp_state != qmp_state_disconnected)
+return 0;
+
+qmp_socket_path = libxl__qemu_qmp_path(gc, ev->domid);
+
+LOGD(DEBUG, ev->domid, "Connecting to %s", qmp_socket_path);
+
+libxl__carefd_begin();
+ev->qmp_cfd = libxl__carefd_opened(CTX, socket(AF_UNIX, SOCK_STREAM, 0));
+if (!ev->qmp_cfd) {
+LOGED(ERROR, ev->domid, "socket() failed");
+rc = ERROR_FAIL;
+goto out;
+}
+rc = libxl_fd_set_nonblock(CTX, libxl__carefd_fd(ev->qmp_cfd), 1);
+if (rc)
+goto out;
+
+rc = libxl__prepare_sockaddr_un(gc, &un, qmp_socket_path, "QMP socket");
+if (rc)
+goto out;
+
+r = connect(libxl__carefd_fd(ev->qmp_cfd),
+(struct sockaddr *) &un, sizeof(un));
+if (r) {
+LOGED(ERROR, ev->domid, "Failed to connect to QMP socket %s",
+  qmp_socket_path);
+rc = ERROR_FAIL;
+goto out;
+}
+
+rc = libxl__ev_fd_register(gc, &ev->qmp_efd, qmp_ev_fd_callback,
+   libxl__carefd_fd(ev->qmp_cfd), POLLIN);
+if (rc)
+goto out;
+
+ev->qmp_state = qmp_state_connecting;
+return 0;
+
+out:
+libxl__carefd_close(ev->qmp_cfd);
+ev->qmp_cfd = NULL;
+return rc;
+}
+
+
+/*
+ * libxl__ev_qmp_*
+ */
+
+void libxl__ev_qmp_init(libxl__ev_qmp *ev)
+{
+ev->id = -1;
+
+ev->qmp_cfd = NULL;
+libxl__ev_fd_init(&ev->qmp_efd);
+ev->qmp_state = qmp_state_disconnected;
+}
+
+int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
+   const char *cmd, libxl__json_object *args)
+{
+int rc;
+
+LOGD(DEBUG, ev->domid, " ev %p, cmd '%s'", ev, cmd);
+
+/* Connect to QEMU if not already connected */
+rc = qmp_ev_connect(gc, ev);
+
+return rc;
+}
+
+void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev)
+{
+LOGD(DEBUG, ev->domid, " ev %p", ev);
+
+libxl__ev_fd_deregister(gc, &ev->qmp_efd);
+libxl__carefd_close(ev->qmp_cfd);
+ev->qmp_cfd = NULL;
+
+libxl__ev_qmp_init(ev);
+}
+
 /*
  * Local variables:
  * mode: C
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v4 12/32] libxl: Design of an async API to issue QMP commands to QEMU

[Anthony PERARD]

All the functions will be implemented in later patches.

This patch includes the API that libxl can use to send QMP commands to
QEMU.

Signed-off-by: Anthony PERARD 
---
 tools/libxl/libxl_internal.h | 76 +++-
 1 file changed, 74 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5b71a23d23..c453ac10a5 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -202,6 +202,8 @@ typedef struct libxl__ao libxl__ao;
 typedef struct libxl__aop_occurred libxl__aop_occurred;
 typedef struct libxl__osevent_hook_nexus libxl__osevent_hook_nexus;
 typedef struct libxl__osevent_hook_nexi libxl__osevent_hook_nexi;
+typedef struct libxl__json_object libxl__json_object;
+typedef struct libxl__carefd libxl__carefd;
 
 typedef struct libxl__domain_create_state libxl__domain_create_state;
 typedef void libxl__domain_create_cb(struct libxl__egc *egc,
@@ -357,6 +359,76 @@ struct libxl__ev_child {
 LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
 };
 
+/*
+ * QMP asynchronous calls
+ */
+
+/*
+ * This facility allows a command to be sent to QEMU, and the response to be
+ * handed to a callback function.  Each libxl__ev_qmp handles zero or one
+ * outstanding command.
+ *
+ * Commands can be chained, with a same connection. (e.g. "add-fd" will need to
+ * be chained to the next command). A libxl__ev_qmp can be reused when the
+ * callback is been called in order to use the same connection.
+ *
+ * Only one connection at a time can be made to one QEMU, so avoid keeping a
+ * libxl__ev_qmp Connected for to long and call libxl__ev_qmp_dispose as soon
+ * as it is not needed anymore.
+ *
+ * Possible states of a libxl__ev_qmp:
+ *  Undefined
+ *Might contain anything.
+ *  Idle
+ *Struct contents are defined enough to pass to any libxl__ev_qmp_*
+ *functions.
+ *The struct does not contain references to any allocated private resources
+ *so can be thrown away.
+ *  Active
+ *Currently waiting for the callback to be called.
+ *_dispose must be called to reclaim resources.
+ *  Connected
+ *Struct contain allocated ressources.
+ *Calling _send() with this same ev will use the same QMP connection.
+ *_dispose() must be called to reclaim resources.
+ *
+ * libxl__ev_qmp_init: Undefined/Idle -> Idle
+ *
+ * libxl__ev_qmp_send: Idle/Connected -> Active (on error: Idle)
+ *Sends a command to QEMU.
+ *callback will be called when a response is received or when an error
+ *as occured.
+ *
+ * libxl__ev_qmp_dispose: Connected/Active/Idle -> Idle
+ *
+ * callback: When called: Active -> Connected
+ *When called, ev is Connected and can be reused or disposed of.
+ *When an error occured, it is called with response == NULL and the error
+ *code in rc.
+ *The callback is only called once.
+ */
+typedef struct libxl__ev_qmp libxl__ev_qmp;
+typedef void libxl__ev_qmp_callback(libxl__egc *egc, libxl__ev_qmp *ev,
+const libxl__json_object *response,
+int rc);
+
+_hidden void libxl__ev_qmp_init(libxl__ev_qmp *ev);
+_hidden int libxl__ev_qmp_send(libxl__gc *gc, libxl__ev_qmp *ev,
+   const char *cmd, libxl__json_object *args);
+_hidden void libxl__ev_qmp_dispose(libxl__gc *gc, libxl__ev_qmp *ev);
+
+struct libxl__ev_qmp {
+/* caller should include this in their own struct */
+/* caller must fill these in, and they must all remain valid */
+uint32_t domid;
+libxl__ev_qmp_callback *callback;
+libxl__carefd *cfd; /* set to send a fd with the command, NULL otherwise */
+
+/* remaining fields are private to libxl_ev_qmp_* */
+
+int id;
+};
+
 
 /*
  * evgen structures, which are the state we use for generating
@@ -1902,7 +1974,7 @@ typedef enum {
 JSON_ANY = 255 /* this is a mask of all values above, adjust as needed 
*/
 } libxl__json_node_type;
 
-typedef struct libxl__json_object {
+struct libxl__json_object {
 libxl__json_node_type type;
 union {
 bool b;
@@ -1915,7 +1987,7 @@ typedef struct libxl__json_object {
 flexarray_t *map;
 } u;
 struct libxl__json_object *parent;
-} libxl__json_object;
+};
 
 typedef int (*libxl__json_parse_callback)(libxl__gc *gc,
   libxl__json_object *o,
-- 
Anthony PERARD


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

[Xen-devel] [PATCH 4/4] x86/iommu: add PVH support to the inclusive options

[Roger Pau Monne]

Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults. Those faults are caused by
missing RMRR (VTd) or IRVS (AMD-Vi) entries in the ACPI tables. Those
can be worked around on VTd hardware by manually adding RMRR entries
on the command line, this is however limited to Intel hardware and
quite cumbersome to do.

In order to solve those issues add PVH support to the inclusive option
that identity maps all regions marked as reserved in the memory map.
Note that regions used by devices emulated by Xen (LAPIC, IO-APIC or
PCIe MCFG regions) are specifically avoided. Note that this option
currently relies on no MSIX MMIO areas residing in a reserved region,
or else Xen won't be able to trap those accesses.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 docs/misc/xen-command-line.markdown | 16 --
 xen/drivers/passthrough/x86/iommu.c | 82 +++--
 2 files changed, 77 insertions(+), 21 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 91a8bfc9a6..c7c9a38c19 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1203,11 +1203,17 @@ detection of systems known to misbehave upon accesses 
to that port.
 > Default: `true`
 
 >> Use this to work around firmware issues providing incorrect RMRR or IVMD
->> entries. Rather than only mapping RAM pages for IOMMU accesses for Dom0,
->> with this option all pages up to 4GB, not marked as unusable in the E820
->> table, will get a mapping established. Note that this option is only
->> applicable to a PV dom0. Also note that if `dom0-strict` mode is enabled
->> then conventional RAM pages not assigned to dom0 will not be mapped.
+>> entries. The behaviour of this option is slightly different between a PV and
+>> a PVH Dom0:
+>>
+>> * For a PV Dom0 all pages up to 4GB not marked as unusable in the memory
+>>   map will get a mapping established. Note that if `dom0-strict` mode is
+>>   enabled then conventional RAM pages not assigned to dom0 will not be
+>>   mapped.
+>>
+>> * For a PVH Dom0 all memory regions marked as reserved in the memory map
+>>   that don't overlap with any MMIO region from emulated devices will be
+>>   identity mapped.
 
 ### iommu\_dev\_iotlb\_timeout
 > `= `
diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index 24cc591aa5..cfafe1b572 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 
 void iommu_update_ire_from_apic(
@@ -134,11 +136,62 @@ void arch_iommu_domain_destroy(struct domain *d)
 {
 }
 
+static bool __hwdom_init pv_inclusive_map(unsigned long pfn,
+  unsigned long max_pfn)
+{
+/*
+ * If dom0-strict mode is enabled then exclude conventional RAM
+ * and let the common code map dom0's pages.
+ */
+if ( iommu_dom0_strict && page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) )
+return false;
+if ( iommu_inclusive && pfn <= max_pfn )
+return !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE);
+
+return page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL);
+}
+
+static bool __hwdom_init pvh_inclusive_map(const struct domain *d,
+   unsigned long pfn)
+{
+unsigned int i;
+
+/*
+ * Ignore any address below 1MB, that's already identity mapped by the
+ * domain builder.
+ */
+if ( pfn < PFN_DOWN(MB(1)) )
+return false;
+
+/* Only add reserved regions. */
+if ( !page_is_ram_type(pfn, RAM_TYPE_RESERVED) )
+return false;
+
+/* Check that it doesn't overlap with the LAPIC */
+if ( pfn == PFN_DOWN(APIC_DEFAULT_PHYS_BASE) )
+return false;
+/* ... or the IO-APIC */
+for ( i = 0; i < nr_ioapics; i++ )
+if ( pfn == PFN_DOWN(domain_vioapic(d, i)->base_address) )
+return false;
+/* ... or the PCIe MCFG regions. */
+for ( i = 0; i < pci_mmcfg_config_num; i++ )
+{
+unsigned long addr = PFN_DOWN(pci_mmcfg_config[i].address);
+
+if ( pfn >= addr + (pci_mmcfg_config[i].start_bus_number << 8) &&
+ pfn < addr + (pci_mmcfg_config[i].end_bus_number << 8) )
+return false;
+}
+
+return true;
+}
+
 void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
 {
 unsigned long i, j, tmp, top, max_pfn;
 
-if ( iommu_passthrough || !is_pv_domain(d) )
+if ( iommu_passthrough )
 return;
 
 BUG_ON(!is_hardware_domain(d));
@@ -149,7 +202,6 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
 for ( i = 0; i < top; i++ )
 {
 unsigned long pfn = pdx_to_pfn(i);
-bool map;
 int rc = 0;
 
 /

[Xen-devel] [PATCH 3/4] x86/iommu: reorder conditions used in the inclusive iommu mappings

[Roger Pau Monne]

In order to place all the map conditions in a single if ... else
conditional.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
 xen/drivers/passthrough/x86/iommu.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/drivers/passthrough/x86/iommu.c 
b/xen/drivers/passthrough/x86/iommu.c
index ba0bbd9a15..24cc591aa5 100644
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -158,19 +158,9 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
  * regions. When set, the inclusive mapping additionally maps in
  * every pfn up to 4GB except those that fall in unusable ranges.
  */
-if ( pfn > max_pfn && !mfn_valid(_mfn(pfn)) )
-continue;
-
-if ( iommu_inclusive && pfn <= max_pfn )
-map = !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE);
-else
-map = page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL);
-
-if ( !map )
-continue;
-
-/* Exclude Xen bits */
-if ( xen_in_range(pfn) )
+if ( (pfn > max_pfn && !mfn_valid(_mfn(pfn))) ||
+ /* Exclude Xen bits */
+ xen_in_range(pfn) )
 continue;
 
 /*
@@ -179,6 +169,13 @@ void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
  */
 if ( iommu_dom0_strict &&
  page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) )
+map = false;
+else if ( iommu_inclusive && pfn <= max_pfn )
+map = !page_is_ram_type(pfn, RAM_TYPE_UNUSABLE);
+else
+map = page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL);
+
+if ( !map )
 continue;
 
 tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
-- 
2.18.0


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

[Xen-devel] [PATCH 2/4] iommu: generalize iommu_inclusive_mapping

[Roger Pau Monne]

Introduce a new iommu=inclusive generic option that supersedes
iommu_inclusive_mapping. This should be a non-functional change on
Intel hardware, while AMD hardware will gain the same functionality of
mapping almost everything below the 4GB boundary.

Note that is a noop for ARM hardware.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Kevin Tian 
---
 docs/misc/xen-command-line.markdown   | 14 ++
 xen/drivers/passthrough/arm/iommu.c   |  4 ++
 xen/drivers/passthrough/iommu.c   |  6 +++
 xen/drivers/passthrough/vtd/extern.h  |  2 -
 xen/drivers/passthrough/vtd/iommu.c   |  6 ---
 xen/drivers/passthrough/vtd/x86/vtd.c | 66 +
 xen/drivers/passthrough/x86/iommu.c   | 70 +++
 xen/include/xen/iommu.h   |  2 +
 8 files changed, 97 insertions(+), 73 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 65b4754418..91a8bfc9a6 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1198,6 +1198,17 @@ detection of systems known to misbehave upon accesses to 
that port.
 
 >> Enable IOMMU debugging code (implies `verbose`).
 
+> `inclusive`
+
+> Default: `true`
+
+>> Use this to work around firmware issues providing incorrect RMRR or IVMD
+>> entries. Rather than only mapping RAM pages for IOMMU accesses for Dom0,
+>> with this option all pages up to 4GB, not marked as unusable in the E820
+>> table, will get a mapping established. Note that this option is only
+>> applicable to a PV dom0. Also note that if `dom0-strict` mode is enabled
+>> then conventional RAM pages not assigned to dom0 will not be mapped.
+
 ### iommu\_dev\_iotlb\_timeout
 > `= `
 
@@ -1212,6 +1223,9 @@ wait descriptor timed out', try increasing this value.
 
 > Default: `true`
 
+**WARNING: This command line option is deprecated, and superseded by
+_iommu=inclusive_ - using both options in combination is undefined.**
+
 Use this to work around firmware issues providing incorrect RMRR entries.
 Rather than only mapping RAM pages for IOMMU accesses for Dom0, with this
 option all pages up to 4GB, not marked as unusable in the E820 table, will
diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c
index 95b1abb972..325997b19f 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -73,3 +73,7 @@ int arch_iommu_populate_page_table(struct domain *d)
 /* The IOMMU shares the p2m with the CPU */
 return -ENOSYS;
 }
+
+void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
+{
+}
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 70d218f910..3f3aa71b2c 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -47,6 +47,9 @@ integer_param("iommu_dev_iotlb_timeout", 
iommu_dev_iotlb_timeout);
  *   no-igfxDisable VT-d for IGD devices (insecure)
  *   no-amd-iommu-perdev-intremap Don't use per-device interrupt remapping
  *  tables (insecure)
+ *   inclusive  Map additional regions into the IOMMU page
+ *  tables in order to workaround bugs in ACPI
+ *  tables.
  */
 custom_param("iommu", parse_iommu_param);
 bool_t __initdata iommu_enable = 1;
@@ -60,6 +63,7 @@ bool_t __read_mostly iommu_passthrough;
 bool_t __read_mostly iommu_snoop = 1;
 bool_t __read_mostly iommu_qinval = 1;
 bool_t __read_mostly iommu_intremap = 1;
+bool __hwdom_initdata iommu_inclusive = true;
 
 /*
  * In the current implementation of VT-d posted interrupts, in some extreme
@@ -208,6 +212,8 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
 }
 
 hd->platform_ops->hwdom_init(d);
+
+arch_iommu_hwdom_init(d);
 }
 
 void iommu_teardown(struct domain *d)
diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index fb7edfaef9..91cadc602e 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -99,6 +99,4 @@ void pci_vtd_quirk(const struct pci_dev *);
 bool_t platform_supports_intremap(void);
 bool_t platform_supports_x2apic(void);
 
-void vtd_set_hwdom_mapping(struct domain *d);
-
 #endif // _VTD_EXTERN_H_
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 1710256823..569ec4aec2 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1304,12 +1304,6 @@ static void __hwdom_init intel_iommu_hwdom_init(struct 
domain *d)
 {
 struct acpi_drhd_unit *drhd;
 
-if ( !iommu_passthrough && is_pv_domain(d) )
-{
-/* Set up 1:1 page table for hardware domain. */
-vtd_set_hwdom_mapping(d);
-}
-
 setup_hwdom_pci_devices(d

[Xen-devel] [PATCH 1/4] iommu: remove unneeded return from iommu_hwdom_init

[Roger Pau Monne]

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
 xen/drivers/passthrough/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 2c44fabf99..70d218f910 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -207,7 +207,7 @@ void __hwdom_init iommu_hwdom_init(struct domain *d)
d->domain_id, rc);
 }
 
-return hd->platform_ops->hwdom_init(d);
+hd->platform_ops->hwdom_init(d);
 }
 
 void iommu_teardown(struct domain *d)
-- 
2.18.0


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

[Xen-devel] [PATCH 0/4] x86/iommu: PVH Dom0 workarounds for missing RMRR/IRSV entries

[Roger Pau Monne]

Hello,

The following series implement a workaround for missing RMRR/IRSV
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option, which is generalized to be used by both VTd and AMD-Vi
hardware.

The PVH workaround identity maps all regions marked as reserved in the
memory map.

The series can be found at:

git://xenbits.xen.org/people/royger/xen.git iommu_inclusive_v1

Thanks, Roger.

Roger Pau Monne (4):
  iommu: remove unneeded return from iommu_hwdom_init
  iommu: generalize iommu_inclusive_mapping
  x86/iommu: reorder conditions used in the inclusive iommu mappings
  x86/iommu: add PVH support to the inclusive options

 docs/misc/xen-command-line.markdown   |  20 +
 xen/drivers/passthrough/arm/iommu.c   |   4 +
 xen/drivers/passthrough/iommu.c   |   8 +-
 xen/drivers/passthrough/vtd/extern.h  |   2 -
 xen/drivers/passthrough/vtd/iommu.c   |   6 --
 xen/drivers/passthrough/vtd/x86/vtd.c |  66 +--
 xen/drivers/passthrough/x86/iommu.c   | 117 ++
 xen/include/xen/iommu.h   |   2 +
 8 files changed, 151 insertions(+), 74 deletions(-)

-- 
2.18.0


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

Re: [Xen-devel] Xen 4.12 release planning

[Stefano Stabellini]

On Fri, 27 Jul 2018, Juergen Gross wrote:
> On 27/07/18 12:32, Lars Kurth wrote:
> > 
> > 
> >> On 27 Jul 2018, at 08:51, Juergen Gross  >> > wrote:
> >>
> >> On 27/07/18 00:13, Stefano Stabellini wrote:
> >>> On Wed, 25 Jul 2018, Juergen Gross wrote:
>  Its time to plan the Xen 4.12 release dates.
> 
>  There have been concerns with the schedule of 6 months between releases,
>  as this scheme is leading to too many supported versions of Xen at a
>  time. The needed resources to backport bug fixes and security fixes as
>  well as doing the tests for all those releases are a limiting factor to
>  push out the current main release as well as point releases on time.
> 
>  After some discussions at the Xen developer summit, on xen-devel and
>  between the committers a slightly longer release cycle of 8 or 9 months
>  was suggested.
> 
>  With 18 months of full support and 36 months of security support the
>  number of concurrent supported releases will be the same with either 8
>  or 9 months release cycles, so I have chosen an 8 month cycle for now.
>  Having only 3 possible times in the year for a release will make it
>  easier to avoid major holiday seasons.
> 
>  In case there is no objection I'm planning Xen 4.12 with:
> 
>  * Last posting date: December 14th, 2018
>  * Hard code freeze: January 11th, 2019
>  * Release: March 7th, 2019
> 
>  Release of Xen 4.13 would then be early November 2019, 4.14 at early
>  July 2020.
> >>>
> >>> Given the holdidays season (it is not just Julien going on vacation but
> >>> pretty much everybody), wouldn't it be better to move the hard code
> >>> freeze by a couple of weeks? For instance Jan 25th? We can still keep
> >>> the release date as Mar 7th, there should be still enough time?
> >>
> >> I don't think planning with a 6 week freeze period is a good idea. The
> >> last releases took longer than 2 months.
> >>
> >> We could slip the complete release by 2 weeks, of course. In this case
> >> I'd move the last posting date to January. So something like:
> >>
> >> * Last posting date: January 11th, 2019
> >> * Hard code freeze: January 25th, 2019
> >> * Release: March 21st, 2019
> > 
> > Another alternative would be to move the dates backwards rather than
> > forward. The 4.12 development window effectively opened 21-06-18, so a
> > last posting data and hard code freeze before Xmas should be OK. Then
> > assume that there won't be RC's for at last 2 (maybe 3) weeks during the
> > winter holidays. But as long as someone is there to keep an eye on
> > OSSTEST and to do a force push and build an RC1 before Xmas that may be
> > OK: but it would probably still be OK if RC1 slipped until just after
> > New Years Eve.
> 
> You are neglecting that the reason for no RC directly after the freeze
> is normally due to bugs. And those need to be found and fixed by
> someone. So putting the freeze directly before a holiday season just
> makes the freeze longer without any major advantage.

There is no silver bullet here, it is up to you. I'd say that given the
current set of maintainers that we have, I think that overlapping with
Chinese New Year is less damaging than overlapping with Christmas. So
I'd move the dates backward by 2 weeks.

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

Re: [Xen-devel] Xen 4.12 release planning

[Juergen Gross]

On 27/07/18 17:50, Stefano Stabellini wrote:
> On Fri, 27 Jul 2018, Juergen Gross wrote:
>> On 27/07/18 12:32, Lars Kurth wrote:
>>>
>>>
 On 27 Jul 2018, at 08:51, Juergen Gross >>> > wrote:

 On 27/07/18 00:13, Stefano Stabellini wrote:
> On Wed, 25 Jul 2018, Juergen Gross wrote:
>> Its time to plan the Xen 4.12 release dates.
>>
>> There have been concerns with the schedule of 6 months between releases,
>> as this scheme is leading to too many supported versions of Xen at a
>> time. The needed resources to backport bug fixes and security fixes as
>> well as doing the tests for all those releases are a limiting factor to
>> push out the current main release as well as point releases on time.
>>
>> After some discussions at the Xen developer summit, on xen-devel and
>> between the committers a slightly longer release cycle of 8 or 9 months
>> was suggested.
>>
>> With 18 months of full support and 36 months of security support the
>> number of concurrent supported releases will be the same with either 8
>> or 9 months release cycles, so I have chosen an 8 month cycle for now.
>> Having only 3 possible times in the year for a release will make it
>> easier to avoid major holiday seasons.
>>
>> In case there is no objection I'm planning Xen 4.12 with:
>>
>> * Last posting date: December 14th, 2018
>> * Hard code freeze: January 11th, 2019
>> * Release: March 7th, 2019
>>
>> Release of Xen 4.13 would then be early November 2019, 4.14 at early
>> July 2020.
>
> Given the holdidays season (it is not just Julien going on vacation but
> pretty much everybody), wouldn't it be better to move the hard code
> freeze by a couple of weeks? For instance Jan 25th? We can still keep
> the release date as Mar 7th, there should be still enough time?

 I don't think planning with a 6 week freeze period is a good idea. The
 last releases took longer than 2 months.

 We could slip the complete release by 2 weeks, of course. In this case
 I'd move the last posting date to January. So something like:

 * Last posting date: January 11th, 2019
 * Hard code freeze: January 25th, 2019
 * Release: March 21st, 2019
>>>
>>> Another alternative would be to move the dates backwards rather than
>>> forward. The 4.12 development window effectively opened 21-06-18, so a
>>> last posting data and hard code freeze before Xmas should be OK. Then
>>> assume that there won't be RC's for at last 2 (maybe 3) weeks during the
>>> winter holidays. But as long as someone is there to keep an eye on
>>> OSSTEST and to do a force push and build an RC1 before Xmas that may be
>>> OK: but it would probably still be OK if RC1 slipped until just after
>>> New Years Eve.
>>
>> You are neglecting that the reason for no RC directly after the freeze
>> is normally due to bugs. And those need to be found and fixed by
>> someone. So putting the freeze directly before a holiday season just
>> makes the freeze longer without any major advantage.
> 
> There is no silver bullet here, it is up to you. I'd say that given the
> current set of maintainers that we have, I think that overlapping with
> Chinese New Year is less damaging than overlapping with Christmas. So
> I'd move the dates backward by 2 weeks.

Just for the records:

Via IRC we (Stefano and me) discussed the release schedule and now he is
fine with my initial proposal:

* Last posting date: December 14th, 2018
* Hard code freeze: January 11th, 2019
* Release: March 7th, 2019

with the addendum that depending on vacation plans over Christmas e.g.
patch series needing an Ack from arm maintainers might have an earlier
last posting date.


Juergen

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

[Xen-devel] Xen 4.12 Development Update

[Juergen Gross]

This email only tracks big items for xen.git tree. Please reply for items you
would like to see in 4.12 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release about every 8 months.
The upcoming 4.12 timeline are as followed:

* Last posting date: December 14th, 2018
  [ as this is just before Christmas some maintainers might ask for an
earlier last posting date if their Ack is needed. ]
* Hard code freeze: January 11th, 2019
* RC1: TBD
* Release: March 7th, 2019

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.12 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

We recently introduced a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Most of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

I have started to include the version number of series associated to each
feature. Can each owner send an update on the version number if the series
was posted upstream?

= Projects =

== Hypervisor == 

*  Per-cpu tasklet
  -  XEN-28
  -  Konrad Rzeszutek Wilk

=== x86 === 

*  guest resource mapping (v18)
  -  Paul Durrant

*  vNVDIMM support for HVM guest (RFC v4)
  -  XEN-45
  -  Haozhong Zhang

*  hypervisor x86 instruction emulator additions (v4)
  -  Jan Beulich

*  PV-IOMMU
  -  Paul Durrant

*  HVM guest CPU topology support (RFC)
  -  Chao Gao

*  Intel Processor Trace virtualization enabling (v1)
  -  Luwei Kang

=== ARM === 

*  SMMUv3 driver (RFC v4)
  -  Sameer Goel

*  IORT support (RFC)
  -  Manish Jaggi

== Grub2 == 

*  Support PVH guest boot (v1)
  -  Juergen Gross

== Completed == 


Juergen Gross

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

[Xen-devel] [ovmf baseline-only test] 75017: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75017 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75017/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75014
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75014

version targeted for testing:
 ovmf f413763b6b8f2798595d468cf868ae5985d3eabc
baseline version:
 ovmf 07eba7069d4c23e9b15caa1e729682a88ddf4ada

Last test of basis75014  2018-07-27 05:58:45 Z0 days
Testing same since75017  2018-07-27 10:24:04 Z0 days1 attempts


People who touched revisions under test:
  Yunhua Feng 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


commit f413763b6b8f2798595d468cf868ae5985d3eabc
Author: Yunhua Feng 
Date:   Wed Jul 25 11:21:07 2018 +0800

BaseTools: Parse decimal format INF_VERSION incorrect

hex number 0x00010019, the major number is 0001, the
minor number is 0019.
the decimal number 1.25, the major number is 1, and the
minor number is 25

Fix https://bugzilla.tianocore.org/show_bug.cgi?id=921

Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
Reviewed-by: Yonghong Zhu 

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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Stefano Stabellini]

On Fri, 27 Jul 2018, Andrii Anisov wrote:
> On 27.07.18 01:46, Stefano Stabellini wrote:
> > On Tue, 24 Jul 2018, Andrii Anisov wrote:
> > > On 07.07.18 02:13, Stefano Stabellini wrote:
> > > > Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
> > > > MPSOC and ALL. They enable the required options for their hardware
> > > > platform. ALL enables all available platforms and it's the default. It
> > > > doesn't automatically select any of the related drivers, otherwise they
> > > > cannot be disabled. ALL is implemented by selecting hidden options
> > > > corresponding to QEMU, MPSOC and RCAR3.
> > > > 
> > > > In the case of the MPSOC that has a platform file under
> > > > arch/arm/platforms/, build the file if MPSOC.
> > > > 
> > > > Signed-off-by: Stefano Stabellini 
> > > > CC: artem_myga...@epam.com
> > > > CC: volodymyr_babc...@epam.com
> > > > 
> > > > ---
> > > > Changes in v5:
> > > > - turn platform support into a choice
> > > > - add ALL
> > > > 
> > > > Changes in v4:
> > > > - fix GICv3/GICV3
> > > > - default y to all options
> > > > - build xilinx-zynqmp if MPSOC
> > > > ---
> > > >xen/arch/arm/Kconfig|  2 ++
> > > >xen/arch/arm/platforms/Kconfig  | 55
> > > > +
> > > >xen/arch/arm/platforms/Makefile |  2 +-
> > > >3 files changed, 58 insertions(+), 1 deletion(-)
> > > >create mode 100644 xen/arch/arm/platforms/Kconfig
> > > > 
> > > > diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> > > > index 2b87111..75cacfb 100644
> > > > --- a/xen/arch/arm/Kconfig
> > > > +++ b/xen/arch/arm/Kconfig
> > > > @@ -213,6 +213,8 @@ config ARM64_HARDEN_BRANCH_PREDICTOR
> > > >config ARM32_HARDEN_BRANCH_PREDICTOR
> > > >def_bool y if ARM_32 && HARDEN_BRANCH_PREDICTOR
> > > >+source "arch/arm/platforms/Kconfig"
> > > > +
> > > >source "common/Kconfig"
> > > >  source "drivers/Kconfig"
> > > > diff --git a/xen/arch/arm/platforms/Kconfig
> > > > b/xen/arch/arm/platforms/Kconfig
> > > > new file mode 100644
> > > > index 000..07c5930
> > > > --- /dev/null
> > > > +++ b/xen/arch/arm/platforms/Kconfig
> > > > @@ -0,0 +1,55 @@
> > > > +choice
> > > > +   prompt "Platform Support"
> > > > +   default ALL
> > > > +   ---help---
> > > > +   Choose which hardware platform to enable in Xen.
> > > > +
> > > > +   If unsure, choose ALL.
> > > > +
> > > > +config ALL
> > > I would suggest to separate it into ALL_ARM32 and ALL_ARM64. Then, in a
> > > makefile use them for platforms instead of raw ARM32 and ARM64. This would
> > > make such change really useful: disabling ALL_x will drop all odd platform
> > > code.
> > Hi Andrii,
> > 
> > I don't understand the suggestion: ARM32 platforms cannot be enabled on
> > ARM64 and vice versa.
> Indeed.
> 
> >   So basically it is as if you always get only
> > ALL_ARM32 or ALL_ARM64 depending on your target architecture.
> > 
> > Am I missing something?
> With this patch, deselecting "config ALL" does not remove all platform code
> from the build.

Yes, it does.

Let's say that you chose ALL at the menu choice. MPSOC_PLATFORM gets
selected, that trigger the build of the MPSOC platform file.

If you do "make menuconfig" again and select RCAR3 instead,
MPSOC_PLATFORM is removed from the .config. Next time you type "make"
the MPSOC platform files will not be built.

Sorry if I am still misunderstanding your suggestion.


> It is because build of the most of that code depends directly
> on ARMxx.
> In order to get a possibility to drop unneeded platform code, the platform
> code should be dependent on "config ALL". But here you do not want to mix
> 32bit and 64bit platforms, so you would need "config ALL_32" and "config
> ALL_64".
> For sure, written above is meaningful only for the case if someone needs the
> possibility to drop odd platform code from the build.
>
> > > > +   bool "All Platforms"
> > > > +   select MPSOC_PLATFORM
> > > > +   select QEMU_PLATFORM
> > > > +   select RCAR3_PLATFORM
> > > > +   ---help---
> > > > +   Enable support for all available hardware platforms. It doesn't
> > > > +   automatically select any of the related drivers.
> > > > +
> > > > +config QEMU
> > > > +   bool "QEMU aarch virt machine support"
> > > > +   depends on ARM_64
> > > > +   select QEMU_PLATFORM
> > > > +   select GICV3
> > > > +   select HAS_PL011
> > > > +   ---help---
> > > > +   Enable all the required drivers for QEMU aarch64 virt emulated
> > > > +   machine.
> > > > +
> > > > +config RCAR3
> > > > +   bool "Renesas RCar3 support"
> > > > +   depends on ARM_64
> > > > +   select RCAR3_PLATFORM
> > > > +   select HAS_SCIF
> > > > +   ---help---
> > > > +   Enable all the required drivers for Renesas RCar3
> > > > +
> > > > +config MPSOC
> > > > +   bool "Xilinx Ultrascale+ MPSoC support"
> > > > +   depends on ARM_64
> > > > +   select MPSOC

[Xen-devel] [qemu-upstream-4.11-testing baseline-only test] 75016: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75016 qemu-upstream-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/75016/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-armhf-armhf-xl  12 guest-start  fail   never pass
 test-armhf-armhf-libvirt 12 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 12 guest-start  fail  never pass
 test-armhf-armhf-xl-credit2  12 guest-start  fail   never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 guest-start  fail   never pass
 test-armhf-armhf-xl-midway   12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  10 debian-di-installfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass

version targeted for testing:
 qemuu20c76f9a5fbf16d58c6add2ace2ff0fabd785926
baseline version:
 qemuu43139135a8938de44f66333831d3a8655d07663a

Last test of basis74923  2018-06-29 03:50:41 Z   28 days
Testing same since75016  2018-07-27 08:52:29 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alexandro Sanchez Bach 
  Anthony PERARD 
  Brijesh Singh 
  Bruce Rogers 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Daniel P. Berrangé 
  David Gibson 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Geert Uytterhoeven 
  Gerd Hoffmann 
  Greg Kurz 
  Halil Pasic 
  Henry Wertz 
  Jack Schwartz 
  Jan Kiszka 
  Jason Andryuk 
  Jason Wang 
  Jeff Cody 
  Jintack Lim 
  John Snow 
  John Thomson 
  Kevin Wolf 
  KONRAD Frederic 
  Konrad Rzeszutek Wilk 
  Laszlo Ersek 
  Laurent Vivier 
  Laurent Vivier 
  linzhecheng 
  Marc-André Lureau 
  Mark Cave-Ayland 
  Max Filippov 
  Max Reitz 
  Michael Roth 
  Michael S. Tsirkin 
  Michael Walle 
  Michal Privoznik 
  Murilo Opsfelder Araujo 
  Nia Alarie 
  Olaf Hering 
  Paolo Bonzini 
  Peter Lieven 
  Peter Maydell 
  Peter Xu 
  Philippe Mathieu-Daudé 
  Prasad Singamsetty 
  Prasad Singamsetty 
  R. Nageswara Sastry 
  Richard Henderson 
  Ross Lagerwall 
  Shannon Zhao 
  Stefan Berger 
  Stefan Hajnoczi 
  Thomas Huth 
  Tiwei Bie 
  Victor Kamensky 
  Viktor Mihajlovski 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Andrii Anisov]

Hello Stefano,


On 27.07.18 20:11, Stefano Stabellini wrote:

Yes, it does.

Let's say that you chose ALL at the menu choice. MPSOC_PLATFORM gets
selected, that trigger the build of the MPSOC platform file.

If you do "make menuconfig" again and select RCAR3 instead,
MPSOC_PLATFORM is removed from the .config. Next time you type "make"
the MPSOC platform files will not be built.
But vexpress, sunxi, other listed in arch/arm/platforms/Makefile and 
dependent on ARM32 or ARM64 will be built anyway.



--

*Andrii Anisov*



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

Re: [Xen-devel] [PATCH] xen-netfront: wait xenbus state change when load module manually

[Boris Ostrovsky]

On 07/27/2018 05:56 AM, Xiao Liang wrote:
> When loading module manually, after call xenbus_switch_state to initializes
> the state of the netfront device, the driver state did not change so fast
> that may lead no dev created in latest kernel. This patch adds wait to make
> sure xenbus knows the driver is not in closed/unknown state.
>
> Current state:
> [vm]# ethtool eth0
> Settings for eth0:
>   Link detected: yes
> [vm]# modprobe -r xen_netfront
> [vm]# modprobe  xen_netfront
> [vm]# ethtool eth0
> Settings for eth0:
> Cannot get device settings: No such device
> Cannot get wake-on-lan settings: No such device
> Cannot get message level: No such device
> Cannot get link status: No such device
> No data available
>
> With the patch installed.
> [vm]# ethtool eth0
> Settings for eth0:
>   Link detected: yes
> [vm]# modprobe -r xen_netfront
> [vm]# modprobe xen_netfront
> [vm]# ethtool eth0
> Settings for eth0:
>   Link detected: yes
>
> Signed-off-by: Xiao Liang 
> ---
>  drivers/net/xen-netfront.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index a57daecf1d57..2d8812dd1534 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -87,6 +87,7 @@ struct netfront_cb {
>  /* IRQ name is queue name with "-tx" or "-rx" appended */
>  #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3)
>  
> +static DECLARE_WAIT_QUEUE_HEAD(module_load_q);
>  static DECLARE_WAIT_QUEUE_HEAD(module_unload_q);
>  
>  struct netfront_stats {
> @@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_dev(struct 
> xenbus_device *dev)
>   netif_carrier_off(netdev);
>  
>   xenbus_switch_state(dev, XenbusStateInitialising);
> + wait_event(module_load_q,
> +xenbus_read_driver_state(dev->otherend) !=
> +XenbusStateClosed &&
> +xenbus_read_driver_state(dev->otherend) !=
> +XenbusStateUnknown);
>   return netdev;
>  
>   exit:


Should we have a wake_up somewhere? And what about other states --- is,
for example, XenbusStateClosing a valid reason to continue?


-boris


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 123554
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 123554
 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 123554

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123554
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123554
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 123554
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123554
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123554
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 123554
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123554
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123554
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux6e77b267723c723d4717abc874e00059ab07a46a
baseline version:
 linux0512e0134582ef85dee77d51aae77dcd1edec495

Last test of basis   123554  2018-06-01 13:09:41 Z   56 days
Failing since123655  2018-06-03 01:45:35 Z   54 days   33 attempts
Testing same since   125585  2018-07-26 07:46:12 Z1 days1 attempts


2327 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm 

[Xen-devel] [ovmf baseline-only test] 75018: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 75018 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75018/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install  fail like 75017
 test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail like 75017

version targeted for testing:
 ovmf 8d7aef3d1e57ea494ba9ca3c2fbbb44efffed676
baseline version:
 ovmf f413763b6b8f2798595d468cf868ae5985d3eabc

Last test of basis75017  2018-07-27 10:24:04 Z0 days
Testing same since75018  2018-07-27 17:23:25 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ruiyu Ni 
  Star Zeng 
  Yunhua Feng 
  Zhang Chao B 
  Zhang, Chao B 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

Logs, config files, etc. are available at
http://osstest.xensource.com/osstest/logs

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


Push not applicable.


commit 8d7aef3d1e57ea494ba9ca3c2fbbb44efffed676
Author: Zhang, Chao B 
Date:   Wed Jun 6 11:24:54 2018 +0800

SecurityPkg: HashLib: Add SHA384, SHA512 HashLib

Add SHA384, 512 Hash lib support. Now only CryptoPkg support PEI/DXE
version.

Cc: Long Qin 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhang Chao B 
Reviewed-by: Long Qin 

commit fb57c30b703ee64415c43102862cfc2c2f2664be
Author: Star Zeng 
Date:   Thu Jul 26 16:59:43 2018 +0800

MdeModulePkg CapsuleApp: Check capsule header for -D and -N options

Then meaningful error message can be shown when the input image is
unexpected.

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 8b03c82d363c32f9e444cda95f2c83972c92b725
Author: Star Zeng 
Date:   Thu Jul 26 10:14:00 2018 +0800

MdeModulePkg CapsuleApp: Prompt info for -C option

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 16299ec84a6676eba7081892a497bf1b5eb9eafa
Author: Star Zeng 
Date:   Thu Jul 26 09:58:00 2018 +0800

MdeModulePkg CapsuleApp: Index need be decimal for -P GET option

Also adjust the help information to be not too long to be suitable
for different display resolutions.

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit e70d9b8c3cfa586d94d5cd1efe56305004a57ba0
Author: Star Zeng 
Date:   Wed Jul 25 19:26:40 2018 +0800

MdeModulePkg CapsuleApp: Refine -N option help information

-N option is used to append a Capsule Header to an existing
FMP capsule image with its ImageTypeId supported by the system.

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 23d083341764b5645b86e14d0451a2e012ded357
Author: Star Zeng 
Date:   Thu Jul 19 11:03:25 2018 +0800

MdeModulePkg CapsuleApp: Fix -D failed to dump Nest FMP capsule

Cc: Michael D Kinney 
Cc: Jiewen Yao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

commit 4436f72220aa59eda7f811abb5ca926efc269f16
Author: Star Zeng 
Date:   Tue Jul 24 17:02:47 2018 +0800

MdeModulePkg CapsuleApp: Fix VS2012 build failure caused by 5410502

The build failure is like below.
xxx\CapsuleApp.c(868) : error C2275: 'EFI_GUID' :
  illegal use of this type as an expression
xxx/UefiBaseType.h(29) : see declaration of 'EFI_GUID'
xxx\Ca

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Stefano Stabellini]

On Fri, 27 Jul 2018, Andrii Anisov wrote:
> Hello Stefano,
> 
> On 27.07.18 20:11, Stefano Stabellini wrote:
> > Yes, it does.
> > 
> > Let's say that you chose ALL at the menu choice. MPSOC_PLATFORM gets
> > selected, that trigger the build of the MPSOC platform file.
> > 
> > If you do "make menuconfig" again and select RCAR3 instead,
> > MPSOC_PLATFORM is removed from the .config. Next time you type "make"
> > the MPSOC platform files will not be built.
> But vexpress, sunxi, other listed in arch/arm/platforms/Makefile and dependent
> on ARM32 or ARM64 will be built anyway.

Ah, yes, I understand what you mean now.

That is not a problem with this patch or with the approach taken here.
It is just a matter of adding more options like RCAR3 and MPSOC. It is
just that I haven't done it yet. Given that this patch series has been
out for a while now and has all the required acks, I would prefer to
commit it as is (with the small change requested by Julien) and make
changes for vexpress, sunxi, and others in follow-up patches.

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

Re: [Xen-devel] [PATCH v2 18/21] xen/arm: Allow vpl011 to be used by DomU

[Stefano Stabellini]

On Fri, 27 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 27/07/18 01:10, Stefano Stabellini wrote:
> > On Tue, 24 Jul 2018, Julien Grall wrote:
> > > On 07/07/18 00:12, Stefano Stabellini wrote:
> > > > +VPL011_UNLOCK(d, flags);
> > > > +}
> > > > +
> > > > +static void vpl011_write_data_noring(struct domain *d, uint8_t data)
> > > > +{
> > > > +unsigned long flags;
> > > > +struct vpl011 *vpl011 = &d->arch.vpl011;
> > > > +
> > > > +VPL011_LOCK(d, flags);
> > > > +
> > > > +printk("%c", data);
> > > > +if (data == '\n')
> > > > +printk("DOM%u: ", d->domain_id);
> > > 
> > > You want to buffer the characters here and only print on newline or when
> > > the
> > > buffer is full. Otherwise characters will get mangled with the Xen console
> > > output or other domains output.
> > 
> > I did the implementation, but then when I type characters at the domain
> > prompt, I don't see them anymore one by one. Only after I press
> > "enter". That makes the domain console not very usable. Should we keep
> > it as?
> 
> I haven't thought about that case. However, if you don't implement the buffer
> solution, you will get all the domain consoles mangled during boot. This is
> not really nice for debugging. A potential solution is to buffer for all the
> domains but the one that is reading characters.

I think I found a good way to buffer the output, unless the console is
in focus. For our future reference, it will be implemented in a separate
patch for review clarity.


> > > > +
> > > > +vpl011->uartris |= TXI;
> > > > +vpl011->uartfr &= ~TXFE;
> > > > +vpl011_update_interrupt_status(d);
> > > > +
> > > > +VPL011_UNLOCK(d, flags);
> > > > +}
> > > > +
> > > > +static uint8_t vpl011_read_data_inring(struct domain *d)
> > > > +{
> > > 
> > > I think you can avoid the duplication here by using a macro.
> > 
> > I prefer to avoid MACROS for things like this. I would rather reuse the
> > existing function for both cases like in v1. Would you be OK to go back
> > to that?
> 
> I would rather keep the duplication over going back to v1.
> 
> I may have another way to keep the code common, but let's look at that in a
> latter patch. For now, I will deal with the duplication.

OK

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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Julien Grall]

Hi Stefano,

Sorry for the top posting.

I think Andrii made a good point. With your new code MPSOC will get built
on Arm 32 bit as well.

This was not the case before this patch.

So I would like at least that to be fixed before any commit.

Cheers,

On Fri, 27 Jul 2018, 22:38 Stefano Stabellini, 
wrote:

> On Fri, 27 Jul 2018, Andrii Anisov wrote:
> > Hello Stefano,
> >
> > On 27.07.18 20:11, Stefano Stabellini wrote:
> > > Yes, it does.
> > >
> > > Let's say that you chose ALL at the menu choice. MPSOC_PLATFORM gets
> > > selected, that trigger the build of the MPSOC platform file.
> > >
> > > If you do "make menuconfig" again and select RCAR3 instead,
> > > MPSOC_PLATFORM is removed from the .config. Next time you type "make"
> > > the MPSOC platform files will not be built.
> > But vexpress, sunxi, other listed in arch/arm/platforms/Makefile and
> dependent
> > on ARM32 or ARM64 will be built anyway.
>
> Ah, yes, I understand what you mean now.
>
> That is not a problem with this patch or with the approach taken here.
> It is just a matter of adding more options like RCAR3 and MPSOC. It is
> just that I haven't done it yet. Given that this patch series has been
> out for a while now and has all the required acks, I would prefer to
> commit it as is (with the small change requested by Julien) and make
> changes for vexpress, sunxi, and others in follow-up patches.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-mainline test] 125598: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-rtds broken
 test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail REGR. vs. 125169
 test-amd64-amd64-xl  18 guest-localmigrate/x10   fail REGR. vs. 125169

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  4 host-install(4)  broken pass in 125558
 test-amd64-amd64-xl   7 xen-boot fail in 125558 pass in 125598

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 125558 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 125558 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125169
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125169
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125169
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125169
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 125169
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuu18a398f6a39df4b08ff86ac0d38384193ca5f4cc
baseline version:
 qemuu9277d81f5c2c6f4d0b5e47c8476eb7ee7e5c0beb

Last test of basis   125169  2018-07-14 20:30:43 Z   13 days
Failing since125246  2018-07-16 15:53:25 Z   11 days8 attempts
Testing same since   125558  2018-07-25 02:23:01 Z2 days2 attempts


People who touched revisions under test:
  Aleksandar Markovic 
  Alex Bennée 
  Alistair Francis 
  Andrew Jeffery 
  BALATON Zoltan 
  Calvin Lee 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrangé 
  David Gibson 
  David Hildenbrand 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Emanuele Giuseppe Esposito 
  Greg Kurz 
  Guenter Roeck 
  Igor Mammedov 
  Jan Kiszka 
  Jason Wang 
  John Arbuckle 
  John Snow 
  Jonas Schievink 
  Kevin Wolf 
  Laurent Vivier 
  Lidong Chen 
  Lidong Chen 
  Marc-André Lureau 
  Marc-André Lureau 
  

Re: [Xen-devel] [PATCH v2 17/21] xen/arm: refactor vpl011_data_avail

[Stefano Stabellini]

On Tue, 24 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 07/07/18 00:12, Stefano Stabellini wrote:
> > Move the code to calculate in_fifo_level and out_fifo_level out of
> > vpl011_data_avail, to the caller.
> > This change will make it possible to reuse vpl011_data_avail with
> > different ring structures in a later patch.
> > 
> > Signed-off-by: Stefano Stabellini 
> > 
> > ---
> > Changes in v2:
> > - new patch
> > ---
> >   xen/arch/arm/vpl011.c | 70
> > ++-
> >   1 file changed, 42 insertions(+), 28 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> > index 33fcaa0..e75957f 100644
> > --- a/xen/arch/arm/vpl011.c
> > +++ b/xen/arch/arm/vpl011.c
> > @@ -34,6 +34,12 @@
> >   #include 
> >   #include 
> >   +static void vpl011_data_avail(struct domain *d,
> > +  XENCONS_RING_IDX in_fifo_level,
> > +  XENCONS_RING_IDX in_size,
> > +  XENCONS_RING_IDX out_fifo_level,
> > +  XENCONS_RING_IDX out_size);
> > +
> 
> Looking at the end code, I think you can avoid the declaration by adding
> vpl011_rx_char somewhere else.
 
Yes, you are right. I'll do that.

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

Re: [Xen-devel] [PATCH v7 08/12] arm: add ALL, QEMU, Rcar3 and MPSoC configs

[Stefano Stabellini]

On Fri, 27 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> Sorry for the top posting.
> 
> I think Andrii made a good point. With your new code MPSOC will get built on 
> Arm 32 bit as well.
> 
> This was not the case before this patch.
> 
> So I would like at least that to be fixed before any commit.

OK, this is a problem. I'll fix it.

Looking into it I think there is a way to solve it that doesn't require
duplication, and not even the introduction of ALL_32 and ALL_64: we just
need to add "if ARM_64" for the ARM64 platforms and "if ARM_32" for the
ARM32 platforms.

So today we would have (the "if ARM_64" is new compared to this patch):

  config ALL
  bool "All Platforms"
  select MPSOC_PLATFORM if ARM_64

In the furure, assuming that we had EXYNOS5 and OMAP5 options, it would become:

  config ALL
  bool "All Platforms"
  select MPSOC_PLATFORM if ARM_64
  select EXYNOS5 if ARM_32
  select OMAP5 if ARM_32

What do you think?

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm  18 guest-localmigrate/x10   fail REGR. vs. 125138

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-examine  5 host-install broken pass in 125561
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 125561 
pass in 125600
 test-amd64-amd64-xl-xsm   7 xen-boot fail in 125561 pass in 125600
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail in 125561 pass in 
125600
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
125561
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 125561
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 125561

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 125138
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 125138
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 125138
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125138
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 125138
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 125138
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux7612025fbc7a5ab5

Re: [Xen-devel] [PATCH v2 19/21] xen/arm: introduce create_domUs

[Stefano Stabellini]

On Tue, 24 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 07/07/18 00:12, Stefano Stabellini wrote:
> > Call a new function, "create_domUs", from setup_xen to start DomU VMs.
> > 
> > Introduce support for the "xen,domU" compatible node on device tree.
> > Create new DomU VMs based on the information found on device tree under
> > "xen,domU". Calls construct_domU for each domain.
> > 
> > Introduce a simple global variable named max_init_domid to keep track of
> > the initial allocated domids.
> > 
> > Move the discard_initial_modules after DomUs have been built
> 
> Nit: Missing full stop.

OK


> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: andrew.coop...@citrix.com
> > CC: jbeul...@suse.com
> > ---
> > Changes in v2:
> > - coding style
> > - set nr_spis to 32
> > - introduce create_domUs
> > ---
> >   xen/arch/arm/domain_build.c | 38 +++---
> >   xen/arch/arm/setup.c|  8 +++-
> >   xen/include/asm-arm/setup.h |  3 +++
> >   xen/include/asm-x86/setup.h |  2 ++
> >   4 files changed, 47 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index d7e9040..9f58002 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -7,6 +7,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -2542,6 +2543,39 @@ static int __init construct_domU(struct domain *d,
> > struct dt_device_node *node)
> >   return rc;
> >   }
> >   +void __init create_domUs(void)
> > +{
> > +struct dt_device_node *node;
> > +struct dt_device_node *chosen = dt_find_node_by_name(dt_host,
> > "chosen");
> 
> newline here.

OK


> > +if ( chosen != NULL )
> > +{
> > +dt_for_each_child_node(chosen, node)
> > +{
> > +struct domain *d;
> > +struct xen_domctl_createdomain d_cfg = {};
> > +
> > +if ( !dt_device_is_compatible(node, "xen,domain") )
> > +continue;
> > +
> > +d_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> > +d_cfg.arch.nr_spis = 32;
> 
> You can set those fields directly when defining d_cfg above.

OK


> > +
> > +d = domain_create(max_init_domid++, &d_cfg);
> > +if ( IS_ERR(d) )
> > +panic("Error creating domU");
> 
> It is probably worth to add the node name in the message. So the user knows
> which guest failed.

OK


> > +
> > +d->is_privileged = 0;
> > +d->is_console = 1;
> > +d->target = NULL;
> > +
> > +if ( construct_domU(d, node) != 0 )
> > +printk("Could not set up DOMU guest OS");
> 
> Should not it be a panic here? Also, the message is a little odd "DOMU guest"
> is a bit redundant and the function will load the kernel but that's not the
> only thing done.
> 
> Lastly, you probably want to add the node name in the message, so the user
> knows which guest failed.

OK to all suggestions


> > +
> > +domain_unpause_by_systemcontroller(d);
> 
> If a domain is bound to CPU0, then it will not boot until CPU0 is done with
> creating domain. Is that what you want?

Are you suggesting to move the domain_unpause_by_systemcontroller(d) to
a second loop after the domU creation loop?


> > +}
> > +}
> > +}
> > +
> >   int __init construct_dom0(struct domain *d)
> >   {
> >   struct kernel_info kinfo = {};
> > @@ -2592,9 +2626,7 @@ int __init construct_dom0(struct domain *d)
> >   return rc;
> > -rc = __construct_domain(d, &kinfo);
> > -discard_initial_modules();
> > -return rc;
> > +return __construct_domain(d, &kinfo);
> >   }
> > /*
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 7739a80..0b08af2 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -64,6 +64,8 @@ static unsigned long opt_xenheap_megabytes __initdata;
> >   integer_param("xenheap_megabytes", opt_xenheap_megabytes);
> >   #endif
> >   +domid_t __read_mostly max_init_domid = 0;
> > +
> >   static __used void init_done(void)
> >   {
> >   free_init_memory();
> > @@ -863,7 +865,7 @@ void __init start_xen(unsigned long boot_phys_offset,
> >   dom0_cfg.arch.gic_version = XEN_DOMCTL_CONFIG_GIC_NATIVE;
> >   dom0_cfg.arch.nr_spis = gic_number_lines() - 32;
> >   -dom0 = domain_create(0, &dom0_cfg);
> > +dom0 = domain_create(max_init_domid++, &dom0_cfg);
> >   if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
> >   panic("Error creating domain 0");
> >   @@ -889,6 +891,10 @@ void __init start_xen(unsigned long boot_phys_offset,
> > domain_unpause_by_systemcontroller(dom0);
> 
> Why do you unpause Dom0 and then create the guests? It feels like to me you
> want to create all the guests and then unpause dom0. dom0 would likely get
> blocked anyway has CPU0 will be busy creating domains.

Right, I'

[Xen-devel] [xen-4.9-testing test] 125605: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail in 125253 REGR. vs. 
124248
 test-amd64-amd64-libvirt-pair 23 guest-migrate/dst_host/src_host fail in 
125253 REGR. vs. 124328

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 125253 
pass in 125605
 test-amd64-amd64-xl-qemut-debianhvm-amd64 7 xen-boot fail in 125253 pass in 
125605
 test-amd64-i386-libvirt-xsm  10 debian-install   fail in 125253 pass in 125605
 test-amd64-i386-xl-raw  10 debian-di-install fail in 125253 pass in 125605
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
125253

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
124328
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 125253 
like 124248
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 125253 
like 124328
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 125253 
like 124328
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 124248
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail like 
124248
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 124328
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 124328
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 124328
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

ver

Re: [Xen-devel] An issue in sharing the pages again in xen-memshare

[sepanta s]

Thanks.
I would be thankful if he can help me ...

On Mon, Jul 23, 2018 at 11:52 AM Razvan Cojocaru 
wrote:

> On 07/23/2018 05:37 AM, sepanta s wrote:
> > I have written a program that can share memory pages of two VMs every x
> > milliseconds. To do so, I modified xen and added an unshare event to be
> > able to capture it. However,  for some pages, when I receive the unshare
> > event that contains the information about the pages which was about to
> > be written on and put it on a buffer for sharing them again after x
> > milliseconds, I cannot nominate them again and an error occurs. So, the
> > sharing mechanism I have built can partially share pages. I guess the
> > problem might be because of internal structure of sharing mechanism in
> > the Xen but can't figure out the problem.
> > Do you  have any idea what can cause this problem? Or what should I
> > check to get closer to any solution?
>
> I've never used this feature, but Tamas might have some insight into
> this (added to Cc).
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel