[Xen-devel] [PATCH] dom_ids array implementation.

[Yi Sun]

Hi, Jan,

Please help to review this patch. Thank you!

Signed-off-by: Yi Sun 
---
 xen/arch/x86/psr.c | 135 ++---
 1 file changed, 55 insertions(+), 80 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index a85ea99..7bc212f 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -125,6 +125,8 @@ struct feat_node {
 uint32_t cos_reg_val[MAX_COS_REG_CNT];
 };
 
+#define PSR_DOM_IDS_NUM ((DOMID_IDLE + 1) / sizeof(uint32_t))
+
 /*
  * PSR features are managed per socket. Below structure defines the members
  * used to manage these features.
@@ -134,9 +136,11 @@ struct feat_node {
  * COS ID. Every entry of cos_ref corresponds to one COS ID.
  */
 struct psr_socket_info {
-struct feat_node *features[PSR_SOCKET_MAX_FEAT];
 spinlock_t ref_lock;
+spinlock_t dom_ids_lock;
+struct feat_node *features[PSR_SOCKET_MAX_FEAT];
 unsigned int cos_ref[MAX_COS_REG_CNT];
+uint32_t dom_ids[PSR_DOM_IDS_NUM];
 };
 
 struct psr_assoc {
@@ -194,26 +198,11 @@ static void free_socket_resources(unsigned int socket)
 {
 unsigned int i;
 struct psr_socket_info *info = socket_info + socket;
-struct domain *d;
+unsigned long flag;
 
 if ( !info )
 return;
 
-/* Restore domain cos id to 0 when socket is offline. */
-for_each_domain ( d )
-{
-unsigned int cos = d->arch.psr_cos_ids[socket];
-if ( cos == 0 )
-continue;
-
-spin_lock(>ref_lock);
-ASSERT(!cos || info->cos_ref[cos]);
-info->cos_ref[cos]--;
-spin_unlock(>ref_lock);
-
-d->arch.psr_cos_ids[socket] = 0;
-}
-
 /*
  * Free resources of features. The global feature object, e.g. feat_l3_cat,
  * may not be freed here if it is not added into array. It is simply being
@@ -221,12 +210,17 @@ static void free_socket_resources(unsigned int socket)
  */
 for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
 {
-if ( !info->features[i] )
-continue;
-
 xfree(info->features[i]);
 info->features[i] = NULL;
 }
+
+spin_lock(>ref_lock);
+memset(info->cos_ref, 0, MAX_COS_REG_CNT * sizeof(unsigned int));
+spin_unlock(>ref_lock);
+
+spin_lock_irqsave(>dom_ids_lock, flag);
+memset(info->dom_ids, 0, PSR_DOM_IDS_NUM * sizeof(uint32_t));
+spin_unlock_irqrestore(>dom_ids_lock, flag);
 }
 
 static bool feat_init_done(const struct psr_socket_info *info)
@@ -682,9 +676,37 @@ void psr_ctxt_switch_to(struct domain *d)
 psr_assoc_rmid(, d->arch.psr_rmid);
 
 if ( psra->cos_mask )
-psr_assoc_cos(, d->arch.psr_cos_ids ?
-  d->arch.psr_cos_ids[cpu_to_socket(smp_processor_id())] :
-  0, psra->cos_mask);
+{
+unsigned int socket = cpu_to_socket(smp_processor_id());
+struct psr_socket_info *info = socket_info + socket;
+
+if ( test_bit(d->domain_id, info->dom_ids) )
+goto set_assoc;
+
+spin_lock(>dom_ids_lock);
+
+int old_bit = test_and_set_bit(d->domain_id, info->dom_ids);
+
+/*
+ * If old_bit is 0, that means this is the first time the domain is
+ * switched to this socket or domain's COS ID has not been set since
+ * the socket is online. So, the domain's COS ID on this socket should
+ * be default value, 0. If not, that means this socket has been offline
+ * and the domain's COS ID has been set when the socket was online. So,
+ * this COS ID is invalid and we have to restore it to 0.
+ */
+if ( d->arch.psr_cos_ids &&
+ old_bit == 0 &&
+ d->arch.psr_cos_ids[socket] != 0 )
+d->arch.psr_cos_ids[socket] = 0;
+
+spin_unlock(>dom_ids_lock);
+
+ set_assoc:
+psr_assoc_cos(,
+  d->arch.psr_cos_ids ? d->arch.psr_cos_ids[socket] : 0,
+  psra->cos_mask);
+}
 
 if ( reg != psra->val )
 {
@@ -1146,40 +1168,6 @@ static int write_psr_msr(unsigned int socket, unsigned 
int cos,
 return 0;
 }
 
-static void restore_default_val(unsigned int socket, unsigned int cos,
-enum psr_feat_type feat_type)
-{
-unsigned int i, j;
-uint32_t default_val;
-const struct psr_socket_info *info = get_socket_info(socket);
-
-for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
-{
-const struct feat_node *feat = info->features[i];
-/*
- * There are four judgements:
- * 1. Input 'feat_type' is valid so we have to get feature according to
- *it. If current feature type (i) does not match 'feat_type', we
- *need skip it, so continue to check next feature.
- * 2. Input 'feat_type' is 'PSR_SOCKET_MAX_FEAT' which means we should
- *handle all features in this case. So, go to next loop.
- * 3. Do not need restore the COS 

[Xen-devel] [PATCH 00/10] block: assorted cleanup for bio splitting and cloning.

[NeilBrown]

This series contains more work towards getting rid of the bioset work
queues and generally improving the splitting and cloning of bios.

The first three patches are similar to ones that I sent previously.
They have been rebased on the current block for-next tree and improved
a little.  Specifically I no longer change all instances of
bioset_create() to bioset_create_rescued().  Instead I only change
those which cannot easily be shown to not need changing.

The next patch fixes some issues with bounce.c.  Most significantly it
used to be called after blk_queue_split(), but now it is called
before.  This means that it can no longer assume that the
bio has been split if it contained more than BIO_MAX_PAGES.

Most of the rest change a number of bio_clone() calls to
bio_clone_fast() as that is often what is needed.  bio_clone() does
not work with bios larger than BIO_MAX_PAGES, bio_clone_fast() does.

Finally we remove bio_clone() (which is no longer used) and stop
blk_bio_segment_split() from splitting after BIO_MAX_PAGES, as that
is no longer necessary.

---

NeilBrown (11):
  blk: remove bio_set arg from blk_queue_split()
  blk: make the bioset rescue_workqueue optional.
  blk: use non-rescuing bioset for q->bio_split.
  block: Improvements to bounce-buffer handling
  rbd: use bio_clone_fast() instead of bio_clone()
  drbd: use bio_clone_fast() instead of bio_clone()
  pktcdvd: use bio_clone_fast() instead of bio_clone()
  xen-blkfront: remove bio splitting.
  bcache: use kmalloc to allocate bio in bch_data_verify()
  block: remove bio_clone() and all references.
  block: don't check for BIO_MAX_PAGES in blk_bio_segment_split()


 Documentation/block/biodoc.txt |2 +
 block/bio.c|   30 +++---
 block/blk-core.c   |2 +
 block/blk-merge.c  |   31 +++
 block/blk-mq.c |2 +
 block/bounce.c |   27 +++-
 drivers/block/drbd/drbd_int.h  |3 ++
 drivers/block/drbd/drbd_main.c |9 +++
 drivers/block/drbd/drbd_req.c  |2 +
 drivers/block/drbd/drbd_req.h  |2 +
 drivers/block/pktcdvd.c|   14 --
 drivers/block/ps3vram.c|2 +
 drivers/block/rbd.c|   16 +++-
 drivers/block/rsxx/dev.c   |2 +
 drivers/block/umem.c   |2 +
 drivers/block/xen-blkfront.c   |   54 ++--
 drivers/block/zram/zram_drv.c  |2 +
 drivers/lightnvm/rrpc.c|2 +
 drivers/md/bcache/debug.c  |2 +
 drivers/md/bcache/super.c  |4 +--
 drivers/md/dm-crypt.c  |2 +
 drivers/md/dm-io.c |2 +
 drivers/md/dm.c|5 ++--
 drivers/md/md.c|4 +--
 drivers/s390/block/dcssblk.c   |2 +
 drivers/s390/block/xpram.c |2 +
 include/linux/bio.h|7 +
 include/linux/blkdev.h |3 +-
 28 files changed, 121 insertions(+), 116 deletions(-)

--
Signature


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

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

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass 
in 107531
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail pass in 107531

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

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

version targeted for testing:
 qemuuca55019dacb821cc675273237a5173fc67bf3230
baseline version:
 qemuu9c6b899f7a46893ab3b671e341a2234e9c0c060e

Last test of basis   107501  2017-04-18 13:18:16 Z1 days
Testing same since   107531  2017-04-18 23:46:16 Z1 days2 attempts


People who touched revisions under test:
  Fam Zheng 
  Jeff Cody 
  Peter Maydell 

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

[Xen-devel] [ovmf baseline-only test] 71207: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4395f82e7f81f5215e52f3dba523ca1ccf280823
baseline version:
 ovmf 33cc487c263384451aef77fa5d749fd4f3d78b7d

Last test of basis71206  2017-04-19 17:21:20 Z0 days
Testing same since71207  2017-04-20 02:17:04 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Jeff Fan 
  Leif Lindholm 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit 4395f82e7f81f5215e52f3dba523ca1ccf280823
Author: Leif Lindholm 
Date:   Wed Apr 19 12:01:55 2017 +0100

EmbeddedPkg: import Lan91x Ethernet controller driver

OpenPlatformPkg (https://git.linaro.org/uefi/OpenPlatformPkg.git) holds a
driver for the SMSC LAN91x, used (among other places) in several ARM Ltd.
software system models.

Import it to EDK2 EmbeddedPkg in preparation for migrating those model
platforms to edk2-platforms.

On the way, update the files to pass PatchCheck.py without warnings
(EFI_D_ -> DEBUG_ and purging tab characters).
Also update .inf file to current version (and sort entries within
sections).
And update copyright dates to reflect this.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Ard Biesheuvel 

commit fcf41edf2f5383f3caca257fdcbb7d3992ff7a48
Author: Ard Biesheuvel 
Date:   Mon Apr 10 17:55:34 2017 +0100

EmbeddedPkg/AndroidFastbootApp: remove dependency on deprecated BdsLib

One of the last remaining modules with a dependency on the deprecated
BdsLib implementation from ArmPkg is the Android fastboot application.

Its only dependency on BdsLib is BdsStartEfiApplication(), which is
used in the most peculiar way: the fastboot app loads the kernel image
into memory, and creates a MemoryMapped() device path for it. It then
proceeds and calls BdsStartEfiApplication(), which explicitly loads the
contents of the devicepath into memory, creating a second in-memory copy
of the kernel image, after which it invokes gBS->LoadImage() with a
buffer address and size (while it is perfectly capable of loading from
a devicepath directly)

Since we know the device path is fully qualified and connected, and does
not require any of the additional processing that BdsStartEfiApplication()
does when dereferencing a device path, we should be able to pass this
devicepath into LoadImage() directly.

So create a simplified local clone of BdsStartEfiApplication(), and drop
the dependency on BdsLib.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 170a3c1e0fff7de43501ef851b4ad5cbe355e220
Author: Jeff Fan 
Date:   Tue Apr 18 10:14:08 2017 +0800

UefiCpuPkg/PiSmmCpuDxeSmm: Lock should be acquired

SMM BSP's *busy* state should be acquired. We could use AcquireSpinLock()
instead of AcquireSpinLockOrFail().

Cc: Hao Wu 
Cc: Feng Tian 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan 
Reviewed-by: Hao Wu 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start fail in 107529 REGR. vs. 59254

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   3 host-install(3)  broken pass in 107529

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 107529 baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linux005882e53d62f25dae10351a8d3f13326051e8f5
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  650 days
Failing since 59348  2015-07-10 04:24:05 Z  649 days  398 attempts
Testing same since   107529  2017-04-18 22:24:05 Z1 days2 attempts


8169 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl

Re: [Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

[Juergen Gross]

On 20/04/17 01:10, Stefano Stabellini wrote:
> Juergen, I have committed this patch to for-linus-4.12 and linux-next, I
> hope that's OK.

Sure.


Juergen

> 
> Og Wed, 19 Apr 2017, Stefano Stabellini wrote:
>> On Wed, 19 Apr 2017, Arnd Bergmann wrote:
>>> All Xen frontends need to select this symbol to avoid a link error:
>>>
>>> net/built-in.o: In function `p9_trans_xen_init':
>>> :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend'
>>>
>>> Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver")
>>> Signed-off-by: Arnd Bergmann 
>>
>> Thank you for the fix!
>>
>> Reviewed-by: Stefano Stabellini 
>>> ---
>>>  net/9p/Kconfig | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/net/9p/Kconfig b/net/9p/Kconfig
>>> index 3f286f1bd1d3..e6014e0e51f7 100644
>>> --- a/net/9p/Kconfig
>>> +++ b/net/9p/Kconfig
>>> @@ -24,6 +24,7 @@ config NET_9P_VIRTIO
>>>  
>>>  config NET_9P_XEN
>>> depends on XEN
>>> +   select XEN_XENBUS_FRONTEND
>>> tristate "9P Xen Transport"
>>> help
>>>   This builds support for a transport for 9pfs between
>>> -- 
>>> 2.9.0
>>>
>>
> 


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

Re: [Xen-devel] [PATCH 2/6] xen/arm: domain_build: Inherit GIC's interrupt-parent from host device tree

[Christopher Patterson]

> Authored-by: Kyle Temkin 

We use "From: " for the author and it is different here. So who wrote
this code?

It was a team effort, but my intention was to indicate him as the primary 
author. I'll set him as From in v2.

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

[Xen-devel] [PATCH v3] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Chao Gao]

According to SDM "ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
"EXTENDED XAPIC (X2APIC)" -> "x2APIC State Transitions", the APIC mode
and APIC ID are preserved when handling INIT signal and a reset places
APIC to xAPIC mode and APIC base address to 0xFEE0h (this part
is in "Local APIC" -> "Local APIC Status and Location"). So there are
two problems in current code:
1. Using reset logic (aka vlapic_reset) to handle INIT signal.
2. Forgetting resetting APIC mode and base address in vlapic_reset()

This patch introduces a new function vlapic_do_init() and replaces the
wrongly used vlapic_reset(). Also reset APIC mode and APIC base address
in vlapic_reset().

Note that: LDR is read only in x2APIC mode. Resetting it to zero in x2APIC
mode is unreasonable. This patch also doesn't reset LDR when handling INIT
signal in x2APIC mode.

Signed-off-by: Chao Gao 

---
I regard this patch as a bug fix. But I haven't seen issues caused by
this bug and am not sure of the existance of such issues. Anyhow Cc
Julien and leave the decision to you (Julien and Jan).

---
v3:
- Reset APIC base address in vlapic_reset() and accordingly change the
commit message
- Reset APIC mode before other APIC registers.

v2:
- rename vlapic_INIT to vlapic_do_init
- reset APIC to xAPIC mode in vlapic_reset()
- constify the struct vcpu in vlapic_reset()
- subject, commit message, comment changes   
- properly handle LDR in x2apic mode

---
 xen/arch/x86/hvm/vlapic.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 2653ba8..4ac9f46 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -83,6 +83,8 @@ static const unsigned int vlapic_lvt_mask[VLAPIC_LVT_NUM] =
 ((vlapic_get_reg(vlapic, APIC_LVTT) & APIC_TIMER_MODE_MASK) \
  == APIC_TIMER_MODE_TSC_DEADLINE)
 
+static void vlapic_do_init(struct vlapic *vlapic);
+
 static int vlapic_find_highest_vector(const void *bitmap)
 {
 const uint32_t *word = bitmap;
@@ -281,7 +283,7 @@ static void vlapic_init_sipi_one(struct vcpu *target, 
uint32_t icr)
 rc = vcpu_reset(target);
 ASSERT(!rc);
 target->fpu_initialised = fpu_initialised;
-vlapic_reset(vcpu_vlapic(target));
+vlapic_do_init(vcpu_vlapic(target));
 domain_unlock(target->domain);
 break;
 }
@@ -1237,16 +1239,14 @@ bool_t is_vlapic_lvtpc_enabled(struct vlapic *vlapic)
 !(vlapic_get_reg(vlapic, APIC_LVTPC) & APIC_LVT_MASKED));
 }
 
-/* Reset the VLPAIC back to its power-on/reset state. */
-void vlapic_reset(struct vlapic *vlapic)
+/* Reset the VLAPIC back to its init state. */
+static void vlapic_do_init(struct vlapic *vlapic)
 {
-struct vcpu *v = vlapic_vcpu(vlapic);
 int i;
 
-if ( !has_vlapic(v->domain) )
+if ( !has_vlapic(vlapic_vcpu(vlapic)->domain) )
 return;
 
-vlapic_set_reg(vlapic, APIC_ID,  (v->vcpu_id * 2) << 24);
 vlapic_set_reg(vlapic, APIC_LVR, VLAPIC_VERSION);
 
 for ( i = 0; i < 8; i++ )
@@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic)
 }
 vlapic_set_reg(vlapic, APIC_ICR, 0);
 vlapic_set_reg(vlapic, APIC_ICR2,0);
-vlapic_set_reg(vlapic, APIC_LDR, 0);
+/*
+ * LDR is read-only in x2APIC mode. Preserve its value when handling
+ * INIT signal in x2APIC mode.
+ */
+if ( !vlapic_x2apic_mode(vlapic) )
+vlapic_set_reg(vlapic, APIC_LDR, 0);
 vlapic_set_reg(vlapic, APIC_TASKPRI, 0);
 vlapic_set_reg(vlapic, APIC_TMICT,   0);
 vlapic_set_reg(vlapic, APIC_TMCCT,   0);
@@ -1275,6 +1280,21 @@ void vlapic_reset(struct vlapic *vlapic)
 destroy_periodic_time(>pt);
 }
 
+/* Reset the VLAPIC back to its power-on/reset state. */
+void vlapic_reset(struct vlapic *vlapic)
+{
+const struct vcpu *v = vlapic_vcpu(vlapic);
+
+if ( !has_vlapic(v->domain) )
+return;
+
+vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
+APIC_DEFAULT_PHYS_BASE);
+
+vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
+vlapic_do_init(vlapic);
+}
+
 /* rearm the actimer if needed, after a HVM restore */
 static void lapic_rearm(struct vlapic *s)
 {
@@ -1489,8 +1509,6 @@ int vlapic_init(struct vcpu *v)
 
 vlapic_reset(vlapic);
 
-vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
-APIC_DEFAULT_PHYS_BASE);
 if ( v->vcpu_id == 0 )
 vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_BSP;
 
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Chao Gao]

On Wed, Apr 19, 2017 at 03:41:41PM +0800, Chao Gao wrote:
>>> -vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
>>> -APIC_DEFAULT_PHYS_BASE);
>>> +vlapic->hw.apic_base_msr |= APIC_DEFAULT_PHYS_BASE;
>>
>>Perhaps better move this ahead of the call to vlapic_reset() then
>>too.
>>
>>Remains the question (not answered by the SDM afaics): What
>>happens to the base address during reset?
>
>Actually, I don't know and that's also why I don't touch apic_base_msr in the
>first verson. Will try to get a confirmation from hardware guys.

According to the description about APIC base address in 
"ADVANCED PROGRAMMABLE INTERRUPT CONTROLLER (APIC) ->
"LOCAL APIC" -> "Local APIC Status and Location", the APIC base
address is set to 0xFEE0H as a result of reset or power-up.

Thanks
Chao

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4395f82e7f81f5215e52f3dba523ca1ccf280823
baseline version:
 ovmf 33cc487c263384451aef77fa5d749fd4f3d78b7d

Last test of basis   107535  2017-04-19 03:15:28 Z0 days
Testing same since   107545  2017-04-19 17:14:46 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Jeff Fan 
  Leif Lindholm 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Yi Sun]

On 17-04-19 03:00:29, Jan Beulich wrote:
> >>> On 19.04.17 at 10:22,  wrote:
> > On 17-04-18 05:46:43, Jan Beulich wrote:
> >> >>> On 18.04.17 at 12:55,  wrote:
> >> > I made a test patch based on v10 and attached it in mail. Could you 
> >> > please
> >> > help to check it? Thanks!
> >> 
> >> This looks reasonable at the first glance, albeit I continue to be
> >> unconvinced that this is the only (reasonable) way of solving the

Do you have any other suggestion on this? Thanks!

> >> problem. After all we don't have to go through similar hoops for
> >> any other of the register state associated with a vCPU. There
> > 
> > Sorry, I do not understand your meaning clearly.
> > 1. DYM the ASSOC register which is set in 'psr_ctxt_switch_to'? In this 
> > patch,
> >we check 'dom_ids' array to know if the domain's cos id has not been set 
> > but
> >its 'psr_cos_ids[socket]' already has a non zero value. This case means 
> > the
> >socket offline has happened so that we have to restore the domain's
> >'psr_cos_ids[socket]' to default value 0 which points to default COS MSR.
> >I think we have discussed this in previous mails and achieved agreement 
> > on
> >such logic. 
> > 2. DYM the COS MSRs? We have discussed this before. Per your comments, when
> >socket is online, the registers values may be modified by FW and others.
> >So, we have to restore them to default value which is being done in
> >'cat_init_feature'.
> > 
> > So, what is your exactly meaning here? Thanks!
> 
> Neither of the two. I'm comparing with COS/PSR-_unrelated_
> handling of register state. After all there are other MSRs which
> we need to put into the right state after a core comes online.
> 
For PSR feature, the 'cos_reg_val[]' of the feature is destroied when socket
is offline. The values in it are all 0 when socket is online again. This causes
error when user shows the CBMs. So, we have two options when socket is online:
1. Read COS MSRs values and save them into 'cos_reg_val[]'.
2. Restore COS MSRs values and 'cos_reg_val[]' values to default CBM.

Per our discussion on v9 patch 05, we decided to adopt option 2. Below are
what we discussed. FYR.

[v9 patch 05]
>> >> > +/* cos=0 is reserved as default cbm(all bits within cbm_len are 
>> >> > 1). */
>> >> > +feat->cos_reg_val[0] = cat_default_val(cat.cbm_len);
>> >> > +/*
>> >> > + * To handle cpu offline and then online case, we need read MSRs 
>> >> > back to
>> >> > + * save values into cos_reg_val array.
>> >> > + */
>> >> > +for ( i = 1; i <= cat.cos_max; i++ )
>> >> > +{
>> >> > +rdmsrl(MSR_IA32_PSR_L3_MASK(i), val);
>> >> > +feat->cos_reg_val[i] = (uint32_t)val;
>> >> > +}
>> >> 
[Jan]
>> >> You mention this in the changes done, but I don't understand why 
>> >> you do this. What meaning to these values have to you? If you want 
>> >> hardware and cached values to match up, the much more conventional 
>> >> way of enforcing this would be to write the values you actually 
>> >> want (normally all zero).
>> >>
[Sun Yi] 
>> > When all cpus on a socket are offline, the free_feature() is called 
>> > to free features resources so that the values saved in 
>> > cos_reg_val[] are lost. When the socket is online again, features 
>> > are allocated again so that cos_reg_val[] members are all 
>> > initialized to 0. Only is cos_reg_val[0] initialized to default value in 
>> > this function in old codes.
>> > 
>> > But domain is still alive so that its cos id on the socket is kept. 
>> > The corresponding MSR value is kept too per test. To make 
>> > cos_reg_val[] values be same as HW to not to mislead user, we 
>> > should read back the valid values on HW into cos_reg_val[].
>> 
[Jan]
>> Okay, I understand the background, but I don't view this solution as 
>> viable: Once the last core on a socket goes offline, all references 
>> to it should be cleaned up. After all what will be brought back 
>> online may be a different physical CPU altogether; you can't assume 
>> MSR values to have survived even if it is the same CPU which comes 
>> back online, as it may have undergone a reset cycle, or BIOS/SMM may 
>> have played with the MSRs.
>> That's even a possibility for a single core coming back online, so 
>> you have to reload MSRs explicitly anyway if implicit reloading (i.e. 
>> once vCPU-s get scheduled onto it) doesn't suffice.
>> 
[Sun Yi]
> So, you think the MSRs values may not be valid after such process and 
> reloading (write MSRs to default value) is needed. If so, I would like 
> to do more operations in 'free_feature()':
> 1. Iterate all domains working on the offline socket to change
>'d->arch.psr_cos_ids[socket]' to COS 0, i.e restore it back to init
>status.
> 2. Restore 'socket_info[socket].cos_ref[]' to all 0.
> 
> These can make the socket's info be totally restored back to init status.
[Jan]
Yes, that's what I think is 

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

On 04/19/2017 05:36 PM, Alistair Francis wrote:
> On Wed, Apr 19, 2017 at 3:22 PM, Eric Blake  wrote:
>> Libvirt would like to be able to distinguish between a SHUTDOWN
>> event triggered solely by guest request and one triggered by a
>> SIGTERM or other action on the host.  qemu_kill_report() is
>> already able to tell whether a shutdown was triggered by a host
>> signal (but NOT by a host UI event, such as clicking the X on
>> the window), but that information was then lost after being
>> printed to stderr.
>>
>> Enhance the shutdown request path to take a parameter of which
>> way it is being triggered, and update ALL callers.  It would have
>> been less churn to keep the common case with no arguments as
>> meaning guest-triggered, and only modified the host-triggered
>> code paths, via a wrapper function, but then we'd still have to
>> audit that I didn't miss any host-triggered spots; changing the
>> signature forces us to double-check that I correctly categorized
>> all callers.

> With all this churn is it not worth chaning the bool from_guest to an
> int that we can expand in future?
> 
> I'm imagining an enum with multiple values for different shutdown
> events. At the moment it will just be one for guest and one for host,
> but at some point in the future we might want more.

Yes, that makes sense.  Probably easiest is creating a QMP enum now ( as
in { 'enum': 'ShutdownCause', 'data': ['guest', 'host'] } - although
such an enum defaults to starting at 0, and the shutdown_requested
variable in vl.c would need a tweak to pick a different value when no
shutdown is requested.

> Not only does this future proof us, but I think it makes it more clear
> what you are passing the function instead of just true/false.

Under your proposal, it would be
qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST), which does look a
bit nicer. I'll wait for other review comments, but you have given me a
good reason to do a v3.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  4 host-ping-check-native fail pass in 107528

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 107528 blocked 
in 107539
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107528
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107528
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107528
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107528
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107528
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107528
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107528

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

version targeted for testing:
 xen  828aa3352f97b613bd06daf7eb1ae734262196be
baseline version:
 xen  828aa3352f97b613bd06daf7eb1ae734262196be

Last test of basis   107539  2017-04-19 10:03:19 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17275 days0 attempts

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

Re: [Xen-devel] raisin and minios stubdom

[Stefano Stabellini]

On Mon, 10 Apr 2017, Juergen Gross wrote:
> On 07/04/17 20:54, Géza Gémes wrote:
> > 
> > On 01/04/17 08:19, Géza Gémes wrote:
> > >
> > >
> > > 2017. márc. 31. 16:15 ezt írta ("Juergen Gross"  > 
> > > >>):
> > >
> > > On 31/03/17 16:05, Konrad Rzeszutek Wilk wrote:
> > > > On Thu, Mar 30, 2017 at 07:42:48PM +0200, Gémes Géza wrote:
> > > >>
> > > >>> On Mon, Mar 27, 2017 at 09:28:14PM +0200, Gémes Géza wrote:
> > >  Hi,
> > > 
> > >  Currently the xen build system has optional support for
> > > building a minios
> > >  (+needed libraries and tools) based stubdom.
> > > 
> > >  What is your opinion about moving support for building this
> > > into raisin and
> > >  once that is stable drop support in the xen build system?
> > > >>> Why? I do like doing 'make' and 'make install' and it doing
> > > everything
> > > >>> for me.
> > > >>>
> > >  Cheers,
> > > 
> > >  Geza
> > > 
> > > 
> > >  ___
> > >  Xen-devel mailing list
> > >  Xen-devel@lists.xen.org 
> > >
> > >  https://lists.xen.org/xen-devel
> >   > >
> > > >>
> > > >> Because it means that xen build needs to download and build
> > a lot
> > > of 3PP
> > > >> components. Raisin is already designed to do so (it already
> > > builds qemu-xen,
> > > >
> > > > If you do 'make src-tarball' it will do that for you - and
> > you can
> > > package
> > > > all of that in a tarball.
> > > >
> > > >> qemu-traditional, libvirt and a few others). I think building
> > > anything
> > > >> besides xen proper would fit its scope better.
> > > >
> > > > OK, but that does not square well with RPM build systems. Those
> > > are interested
> > > > in building just one component (xen+toolstack+its extra
> > pieces). Using
> > > > raisin to build everything is not going to fly.
> > > >
> > > > (Also distros like to seperate componets out - so they build
> > > qemu-upstream
> > > > seperate - which is used by Xen - and they could also do it
> > for MiniOS
> > > > if they were spec files for it and such).
> > >
> > > There are only few stubdoms you can build without the Xen
> > tree. How
> > > would you do so for e.g. xenstore-stubdom needing the Xenstore
> > sources
> > > to be built? Several stubdoms need libxc built for stubdom
> > included.
> > > And you want to have a build error if e.g. a libxc modification is
> > > breaking stubdom build.
> > >
> > >
> > > Juergen
> > >
> > > Hi,
> > >
> > > Raisin already builds xen too, so it has all the dependencies ready.
> > > Regarding the problem of breaking stubdom build by libxc changes I
> > think
> > > those can be prevented if we introduce osstests for raisin build.
> > Maybe
> > > we should start with that, adding raisin to the osstest framework.
> > > Opinions?
> > 
> > osstest is too late. I want to see a build error _before_ sending a
> > patch.
> > 
> > So how is raisin working exactly? Is it possible to do incremental
> > buils or is the build always complete? Can I start builds of only a
> > subtree? Is it possible to use a private version of some sub-component?
> > 
> > 
> > You can use private versions easily. Regarding the problem of
> > selective rebuild O think that is missing currently, but given your
> > input it looks important, so I'll look for ways to enable it.
> > 
> > 
> > I'm not opposed to use raisin e.g. in osstest. I'm opposed to a change
> > in the developer workflow requiring to spend either much more time for
> > testing the build or to add additional steps for it. One-time changes
> > are fine, changes requiring the developer not to forget an additional
> > command are not.
> > 
> > 
> > As raisin is able to build xen and a set of related projects it is
> > practically a matter of running raise build rather than make.
> 
> Raisin is calling make. I don't think it is appropriate to replace the
> "make" call by a raisin call which in turn calls make again.
> 
> What I could imagine to be really nice is using raisin to setup the
> environment to just build everything:
> 
> - configure all components (e.g. 

Re: [Xen-devel] Outreachy project - Xen Code Review Dashboard

[Heather Booker]

Hi Jesus,

I have a version of the task running, I'd love if you could take a
look and let me know if there are any changes you'd like to see.

It's at https://github.com/heatherbooker/xen-outreachy

It gets the mailboxes, analyzes them using Perceval and an
implementation of the well known jwz's threading algorithm
(https://www.jwz.org/doc/threading.html) then indexes them
in Elasticsearch.
Each document in ES is a message, with its id being the
Message-ID and type being a modified Subject line from the
first message in a thread.

I hope this is what was intended for the task!

PS - Should I continue copying these messages to the
whole xen-devel mailing list, or is sending them to you
sufficient?

Thanks!

Heather

On Mon, Apr 17, 2017 at 2:04 AM, Jesus M. Gonzalez-Barahona <
j...@bitergia.com> wrote:

> On Sun, 2017-04-16 at 21:26 -0700, Heather Booker wrote:
> > Hi Jesus!
> >
> > I appreciate the info on the unicode error. I might have missed it,
> > but I also asked about the general microtask specifications. Here
> > was my original inquiry:
> > > And to clarify, my understanding is that the final result of
> > this task
> > > is an index of Xen data, with two types: commits and messages.
> > > Each commit document should contain its original information
> > > from git, plus the name of the branch it was developed in. And
> > > should only the mbox messages which appear to be associated
> > > with a specific commit exist in the final index? Is there some
> > > key information in messages that is supposed to indicate the
> > > association of a given commit with a git branch? I would be
> > > grateful if you could specify the end goal a little more. :D
> >
> > Yeah, so overall I'm not sure I understand the relationship of
> > branches to the mailing list messages. Is this to be a simple
> > string parsing task wherein I should scan the message body
> > for the word "branch"? (I am guessing not ;P)
>
> I'm sorry, I understood that text was about the project, not about the
> microtask. The microtask is about either:
>
> * Producing an ES index with messages labeled by thread (by applying a
> threading algorithm to messages retrieved from archives), or
>
> * Producing an ES index with commits labeled by branch (by following
> refes, and parents information in the output produced by Perceval).
>
> In the complete project, both will be used to produce the final indexes
> that power the code review dashboard.
>
> > I will be happy to get back on developing once I better grasp
> > the goal! :)
>
> More clear now?
>
> If you want, let's schedule some IRC slot for clarifying whatever is
> not clear.
>
> Jesus.
>
> > Thanks!
> >
> > Heather
> >
> > On Sun, Apr 16, 2017 at 4:23 PM, Jesus M. Gonzalez-Barahona  > rgia.com> wrote:
> > > On Thu, 2017-04-13 at 00:47 -0700, Heather Booker wrote:
> > > > Hi,
> > > >
> > > > I submitted an application for this code review dashboard and
> > > > would love to keep working on the microtask once I get some
> > > > more info. :)
> > >
> > > Great! I answered your message, could you progress with the task?
> > >
> > > > I also came up with a general idea of how the project might be
> > > > split up - any feedback on this would be welcome! I wrote:
> > > >
> > > > "As said by Jesus, the big picture of this project will be
> > > porting
> > > > everything behind the current code review dashboard to use
> > > > Grimoire Lab tools, from the current state of using
> > > > MetricsGrimoire and custom scripts. I expect this would involve
> > > > Perceval for analyzing data, and Grimoire Elk may be useful in
> > > > further stages, or may be too general - this is something I would
> > > > wish to explore.
> > > > This project will also involve a migration from SQL to
> > > Elasticsearch
> > > > - because I believe the relevant data is mostly / all available
> > > in
> > > > places online, I am unsure whether this would need to be a direct
> > > > migration. However, looking at the current SQL setup would be
> > > > beneficial to understanding the desired format of the
> > > Elasticsearch
> > > > indexes.
> > > > I would love to dive into this project and have 3 main parts -
> > > > getting
> > > > data into ES, turning it into dashboard displays, and then fine
> > > > tuning
> > > > and perhaps augmenting the dashboard to improve its usefulness.
> > > > Getting data into ES may seem simple but I believe that once it
> > > > needs to be used for the dashboard, many realizations will pop up
> > > > - thus I’d like to leave maybe 2-3 weeks for that first step, 6-7
> > > > weeks
> > > > for the visualizations (which will include querying the data),
> > > and
> > > > the
> > > > final 3 weeks for touch ups and improvements."
> > >
> > > The plan could be sound, but would need some tweaks, once your
> > > skills
> > > in Python are clear, which could be the main blocker for the first
> > > stages.
> > >
> > > > Does this sound like an accurate summary and reasonable
> > > 

[Xen-devel] [linux-arm-xen test] 107537: regressions - FAIL

[osstest service owner]

flight 107537 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107537/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start.2fail REGR. vs. 107176
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107176
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107176

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass

version targeted for testing:
 linux92ed32019d0dd22b796608079023ce42aa8a5a57
baseline version:
 linux6878b2fa7229c9208a02d45f280c71389cba0617

Last test of basis   107176  2017-04-04 09:44:38 Z   15 days
Failing since107256  2017-04-07 00:24:43 Z   12 days   18 attempts
Testing same since   107537  2017-04-19 06:31:15 Z0 days1 attempts


10162 people touched revisions under test,
not listing them all

jobs:
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-arm64  pass
 build-armhf  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-arm64-pvopspass
 build-armhf-pvopspass
 test-arm64-arm64-xl  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-arm64-arm64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  

Re: [Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

[Stefano Stabellini]

Juergen, I have committed this patch to for-linus-4.12 and linux-next, I
hope that's OK.

Og Wed, 19 Apr 2017, Stefano Stabellini wrote:
> On Wed, 19 Apr 2017, Arnd Bergmann wrote:
> > All Xen frontends need to select this symbol to avoid a link error:
> > 
> > net/built-in.o: In function `p9_trans_xen_init':
> > :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend'
> > 
> > Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver")
> > Signed-off-by: Arnd Bergmann 
> 
> Thank you for the fix!
> 
> Reviewed-by: Stefano Stabellini 
> > ---
> >  net/9p/Kconfig | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/net/9p/Kconfig b/net/9p/Kconfig
> > index 3f286f1bd1d3..e6014e0e51f7 100644
> > --- a/net/9p/Kconfig
> > +++ b/net/9p/Kconfig
> > @@ -24,6 +24,7 @@ config NET_9P_VIRTIO
> >  
> >  config NET_9P_XEN
> > depends on XEN
> > +   select XEN_XENBUS_FRONTEND
> > tristate "9P Xen Transport"
> > help
> >   This builds support for a transport for 9pfs between
> > -- 
> > 2.9.0
> > 
> 

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

Re: [Xen-devel] QEMU build breakage on ARM against Xen 4.9 caused by libxendevicemodel

[Stefano Stabellini]

On Wed, 19 Apr 2017, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 18 April 2017 18:41
> > To: Paul Durrant 
> > Cc: 'Stefano Stabellini' ; qemu-de...@nongnu.org;
> > Anthony Perard ; Wei Liu
> > ; jgr...@suse.com; julien.gr...@arm.com; xen-
> > de...@lists.xenproject.org
> > Subject: RE: QEMU build breakage on ARM against Xen 4.9 caused by
> > libxendevicemodel
> > 
> > On Tue, 18 Apr 2017, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > > > Sent: 15 April 2017 01:40
> > > > To: Stefano Stabellini 
> > > > Cc: Paul Durrant ; qemu-de...@nongnu.org;
> > > > Anthony Perard ; Wei Liu
> > > > ; jgr...@suse.com; julien.gr...@arm.com; xen-
> > > > de...@lists.xenproject.org
> > > > Subject: Re: QEMU build breakage on ARM against Xen 4.9 caused by
> > > > libxendevicemodel
> > > >
> > > > On Fri, 14 Apr 2017, Stefano Stabellini wrote:
> > > > > Hi Paul,
> > > > >
> > > > > The following commit in my qemu "next" branch breaks the build on
> > arm
> > > > > and arm64:
> > > > >
> > > > > commit 670271647ad15e9d937ced7a72c892349c709216
> > > > > Author: Paul Durrant 
> > > > > Date:   Tue Mar 7 10:55:34 2017 +
> > > > >
> > > > > xen: use libxendevicemodel when available
> > > > >
> > > > > See the appended build log. Sorry for not realizing it sooner.
> > > >
> > > > As I imagined, this bug is easy to solve. It is reproducible on x86 too,
> > > > if you pass -DXC_WANT_COMPAT_DEVICEMODEL_API=1 to configure
> > and
> > > > forcefully disable Xen 4.9 detection in the configure script.
> > > >
> > > > If QEMU detects xen_ctrl_version = 480, the build will fail against Xen
> > > > 4.9, even when -DXC_WANT_COMPAT_DEVICEMODEL_API=1 is
> > specified.
> > > >
> > > > The appended patch solves the problem. However, Xen 4.9 detection
> > and
> > > > compilation remain broken.
> > >
> > > Ok, that fix looks fine to me.
> > 
> > I merged this change into "use libxendevicemodel when available" in my
> > next branch.
> > 
> > Are you going to take care of getting the QEMU build on ARM to work
> > against Xen 4.9 (properly detecting 4.9, without
> > -DXC_WANT_COMPAT_DEVICEMODEL_API=1)?
> > 
> 
> I can take a look once I get access to some h/w. Since the 4.9 detection 
> should merely be based upon the presence of libxendevicemodel, I can't really 
> imagine why ARM should behave any differently to x86.

I managed to find the time to do some debugging. You are right that is
not anything major. The bug is due to a missing -lxencall in the QEMU
configure script, I wonder why it works on x86.

diff --git a/configure b/configure
index 99d6cbc..363a126 100755
--- a/configure
+++ b/configure
@@ -2027,9 +2027,9 @@ int main(void) {
   return 0;
 }
 EOF
-compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel"
+compile_prog "" "$xen_libs $xen_stable_libs -lxendevicemodel -lxencall"
   then
-  xen_stable_libs="$xen_stable_libs -lxendevicemodel"
+  xen_stable_libs="$xen_stable_libs -lxendevicemodel -lxencall"
   xen_ctrl_version=40900
   xen=yes
 elif

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

[Xen-devel] [xen-unstable-smoke test] 107549: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f97838bbd980a0104e16c4a12fbf514f9fa805f1
baseline version:
 xen  5d1ad47ff7940d95c322667678a190c8607754b4

Last test of basis   107540  2017-04-19 12:02:20 Z0 days
Testing same since   107544  2017-04-19 17:03:35 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ross Lagerwall 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Alistair Francis]

On Wed, Apr 19, 2017 at 3:22 PM, Eric Blake  wrote:
> Libvirt would like to be able to distinguish between a SHUTDOWN
> event triggered solely by guest request and one triggered by a
> SIGTERM or other action on the host.  qemu_kill_report() is
> already able to tell whether a shutdown was triggered by a host
> signal (but NOT by a host UI event, such as clicking the X on
> the window), but that information was then lost after being
> printed to stderr.
>
> Enhance the shutdown request path to take a parameter of which
> way it is being triggered, and update ALL callers.  It would have
> been less churn to keep the common case with no arguments as
> meaning guest-triggered, and only modified the host-triggered
> code paths, via a wrapper function, but then we'd still have to
> audit that I didn't miss any host-triggered spots; changing the
> signature forces us to double-check that I correctly categorized
> all callers.
>
> Here is output from 'virsh qemu-monitor-event --loop' with the
> patch installed:
>
> event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
> event STOP at 1492639680.732116 for domain fedora_13: 
> event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}
>
> Note that libvirt runs qemu with -no-quit: the first SHUTDOWN event
> was triggered by an action I took directly in the guest (shutdown -h),
> at which point qemu stops the vcpus and waits for libvirt to do any
> final cleanups; the second SHUTDOWN event is the result of libvirt
> sending SIGTERM now that it has completed cleanup.
>
> See also https://bugzilla.redhat.com/1384007
>
> Signed-off-by: Eric Blake 
>
> ---
>
> I did not wire up the RESET event to report guest-triggered, although
> I had to plumb that through all the guests since qemu has options that
> allow remapping reset to shutdown.  It's easy to add that if we want
> it in v3.
>
> The replay driver needs a followup patch if we want to be able to
> faithfully replay the difference between a host- and guest-initiated
> shutdown (for now, the replayed event is always attributed to host).
>
>
> v2: retitle (was "event: Add signal information to SHUTDOWN"),
> completely rework to post bool based on whether it is guest-initiated
> v1: initial submission, exposing just Unix signals from host

With all this churn is it not worth chaning the bool from_guest to an
int that we can expand in future?

I'm imagining an enum with multiple values for different shutdown
events. At the moment it will just be one for guest and one for host,
but at some point in the future we might want more.

Not only does this future proof us, but I think it makes it more clear
what you are passing the function instead of just true/false.

Thanks,

Alistair

> ---
>  qapi/event.json |  8 ++--
>  include/sysemu/sysemu.h |  4 ++--
>  vl.c| 19 +++
>  hw/acpi/core.c  |  4 ++--
>  hw/arm/highbank.c   |  4 ++--
>  hw/arm/integratorcp.c   |  2 +-
>  hw/arm/musicpal.c   |  2 +-
>  hw/arm/omap1.c  |  6 +++---
>  hw/arm/omap2.c  |  2 +-
>  hw/arm/spitz.c  |  2 +-
>  hw/arm/stellaris.c  |  2 +-
>  hw/arm/tosa.c   |  2 +-
>  hw/i386/pc.c|  2 +-
>  hw/input/pckbd.c|  4 ++--
>  hw/ipmi/ipmi.c  |  4 ++--
>  hw/isa/lpc_ich9.c   |  2 +-
>  hw/mips/boston.c|  2 +-
>  hw/mips/mips_malta.c|  2 +-
>  hw/mips/mips_r4k.c  |  4 ++--
>  hw/misc/arm_sysctl.c|  8 
>  hw/misc/cbus.c  |  2 +-
>  hw/misc/macio/cuda.c|  4 ++--
>  hw/misc/slavio_misc.c   |  4 ++--
>  hw/misc/zynq_slcr.c |  2 +-
>  hw/pci-host/apb.c   |  4 ++--
>  hw/pci-host/bonito.c|  2 +-
>  hw/pci-host/piix.c  |  2 +-
>  hw/ppc/e500.c   |  2 +-
>  hw/ppc/mpc8544_guts.c   |  2 +-
>  hw/ppc/ppc.c|  2 +-
>  hw/ppc/ppc405_uc.c  |  2 +-
>  hw/ppc/spapr_hcall.c|  2 +-
>  hw/ppc/spapr_rtas.c |  4 ++--
>  hw/s390x/ipl.c  |  2 +-
>  hw/sh4/r2d.c|  2 +-
>  hw/timer/etraxfs_timer.c|  2 +-
>  hw/timer/m48t59.c   |  4 ++--
>  hw/timer/milkymist-sysctl.c |  4 ++--
>  hw/timer/pxa2xx_timer.c |  2 +-
>  hw/watchdog/watchdog.c  |  2 +-
>  hw/xenpv/xen_domainbuild.c  |  2 +-
>  hw/xtensa/xtfpga.c  |  2 +-
>  kvm-all.c   |  6 +++---
>  os-win32.c  |  2 +-
>  qmp.c   |  4 ++--
>  replay/replay.c |  5 -
>  target/alpha/sys_helper.c   |  4 ++--
>  target/arm/psci.c   |  4 ++--
>  target/i386/excp_helper.c   |  2 +-
>  target/i386/hax-all.c   |  6 +++---
>  target/i386/helper.c|  2 +-
>  target/i386/kvm.c   |  2 +-
>  target/s390x/helper.c   |  2 +-
>  target/s390x/kvm.c  |  4 ++--
>  

[Xen-devel] [PATCH v2] event: Add source information to SHUTDOWN

[Eric Blake]

Libvirt would like to be able to distinguish between a SHUTDOWN
event triggered solely by guest request and one triggered by a
SIGTERM or other action on the host.  qemu_kill_report() is
already able to tell whether a shutdown was triggered by a host
signal (but NOT by a host UI event, such as clicking the X on
the window), but that information was then lost after being
printed to stderr.

Enhance the shutdown request path to take a parameter of which
way it is being triggered, and update ALL callers.  It would have
been less churn to keep the common case with no arguments as
meaning guest-triggered, and only modified the host-triggered
code paths, via a wrapper function, but then we'd still have to
audit that I didn't miss any host-triggered spots; changing the
signature forces us to double-check that I correctly categorized
all callers.

Here is output from 'virsh qemu-monitor-event --loop' with the
patch installed:

event SHUTDOWN at 1492639680.731251 for domain fedora_13: {"guest":true}
event STOP at 1492639680.732116 for domain fedora_13: 
event SHUTDOWN at 1492639680.732830 for domain fedora_13: {"guest":false}

Note that libvirt runs qemu with -no-quit: the first SHUTDOWN event
was triggered by an action I took directly in the guest (shutdown -h),
at which point qemu stops the vcpus and waits for libvirt to do any
final cleanups; the second SHUTDOWN event is the result of libvirt
sending SIGTERM now that it has completed cleanup.

See also https://bugzilla.redhat.com/1384007

Signed-off-by: Eric Blake 

---

I did not wire up the RESET event to report guest-triggered, although
I had to plumb that through all the guests since qemu has options that
allow remapping reset to shutdown.  It's easy to add that if we want
it in v3.

The replay driver needs a followup patch if we want to be able to
faithfully replay the difference between a host- and guest-initiated
shutdown (for now, the replayed event is always attributed to host).


v2: retitle (was "event: Add signal information to SHUTDOWN"),
completely rework to post bool based on whether it is guest-initiated
v1: initial submission, exposing just Unix signals from host
---
 qapi/event.json |  8 ++--
 include/sysemu/sysemu.h |  4 ++--
 vl.c| 19 +++
 hw/acpi/core.c  |  4 ++--
 hw/arm/highbank.c   |  4 ++--
 hw/arm/integratorcp.c   |  2 +-
 hw/arm/musicpal.c   |  2 +-
 hw/arm/omap1.c  |  6 +++---
 hw/arm/omap2.c  |  2 +-
 hw/arm/spitz.c  |  2 +-
 hw/arm/stellaris.c  |  2 +-
 hw/arm/tosa.c   |  2 +-
 hw/i386/pc.c|  2 +-
 hw/input/pckbd.c|  4 ++--
 hw/ipmi/ipmi.c  |  4 ++--
 hw/isa/lpc_ich9.c   |  2 +-
 hw/mips/boston.c|  2 +-
 hw/mips/mips_malta.c|  2 +-
 hw/mips/mips_r4k.c  |  4 ++--
 hw/misc/arm_sysctl.c|  8 
 hw/misc/cbus.c  |  2 +-
 hw/misc/macio/cuda.c|  4 ++--
 hw/misc/slavio_misc.c   |  4 ++--
 hw/misc/zynq_slcr.c |  2 +-
 hw/pci-host/apb.c   |  4 ++--
 hw/pci-host/bonito.c|  2 +-
 hw/pci-host/piix.c  |  2 +-
 hw/ppc/e500.c   |  2 +-
 hw/ppc/mpc8544_guts.c   |  2 +-
 hw/ppc/ppc.c|  2 +-
 hw/ppc/ppc405_uc.c  |  2 +-
 hw/ppc/spapr_hcall.c|  2 +-
 hw/ppc/spapr_rtas.c |  4 ++--
 hw/s390x/ipl.c  |  2 +-
 hw/sh4/r2d.c|  2 +-
 hw/timer/etraxfs_timer.c|  2 +-
 hw/timer/m48t59.c   |  4 ++--
 hw/timer/milkymist-sysctl.c |  4 ++--
 hw/timer/pxa2xx_timer.c |  2 +-
 hw/watchdog/watchdog.c  |  2 +-
 hw/xenpv/xen_domainbuild.c  |  2 +-
 hw/xtensa/xtfpga.c  |  2 +-
 kvm-all.c   |  6 +++---
 os-win32.c  |  2 +-
 qmp.c   |  4 ++--
 replay/replay.c |  5 -
 target/alpha/sys_helper.c   |  4 ++--
 target/arm/psci.c   |  4 ++--
 target/i386/excp_helper.c   |  2 +-
 target/i386/hax-all.c   |  6 +++---
 target/i386/helper.c|  2 +-
 target/i386/kvm.c   |  2 +-
 target/s390x/helper.c   |  2 +-
 target/s390x/kvm.c  |  4 ++--
 target/s390x/misc_helper.c  |  4 ++--
 target/sparc/int32_helper.c |  2 +-
 ui/sdl.c|  2 +-
 ui/sdl2.c   |  4 ++--
 xen-hvm.c   |  2 +-
 trace-events|  2 +-
 ui/cocoa.m  |  2 +-
 61 files changed, 106 insertions(+), 96 deletions(-)

diff --git a/qapi/event.json b/qapi/event.json
index e80f3f4..c230265 100644
--- a/qapi/event.json
+++ b/qapi/event.json
@@ -10,6 +10,10 @@
 # Emitted when the virtual machine has shut down, indicating that qemu is
 # about to exit.
 #
+# @guest: If true, the shutdown was triggered by a guest request (such as
+# executing a halt instruction) rather than a host request (such as sending
+# qemu a SIGINT). (since 2.10)

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

[Stefano Stabellini]

On Wed, 19 Apr 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/04/2017 22:01, Stefano Stabellini wrote:
> > On Wed, 19 Apr 2017, Julien Grall wrote:
> > > Currently, Xen is assuming the FDT will always fit in a 2MB section.
> > > Recently, I noticed an early crash on Xen when using GRUB with the
> > > following call trace:
> > > 
> > > (XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
> > > (XEN) CPU0: Unexpected Trap: Hypervisor
> > > (XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
> > > (XEN) CPU:0
> > > (XEN) PC: 00264140 strlen+0x10/0x84
> > > (XEN) LR: 002401c0
> > > (XEN) SP: 002cfc20
> > > (XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
> > > (XEN)  X0: 00801230  X1: 00801230  X2:
> > > 5230
> > > (XEN)  X3: 0030  X4: 0030  X5:
> > > 0038
> > > (XEN)  X6: 0034  X7:   X8:
> > > 7f7f7f7f7f7f7f7f
> > > (XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11:
> > > 0101010101010101
> > > (XEN) X12: 0030 X13: ff00ff00 X14:
> > > 08000300
> > > (XEN) X15:  X16: fefff610 X17:
> > > 00f0
> > > (XEN) X18: 0004 X19: 0008 X20:
> > > 007fc040
> > > (XEN) X21: 007fc000 X22: 000e X23:
> > > 
> > > (XEN) X24: 002a9f58 X25: 00801230 X26:
> > > 002a9f68
> > > (XEN) X27: 002a9f58 X28: 00298910  FP:
> > > 002cfc20
> > > (XEN)
> > > (XEN)   VTCR_EL2: 80010c40
> > > (XEN)  VTTBR_EL2: 082800203000
> > > (XEN)
> > > (XEN)  SCTLR_EL2: 30c5183d
> > > (XEN)HCR_EL2: 0038663f
> > > (XEN)  TTBR0_EL2: f4912000
> > > (XEN)
> > > (XEN)ESR_EL2: 9606
> > > (XEN)  HPFAR_EL2: e8071000
> > > (XEN)FAR_EL2: 00801230
> > > (XEN)
> > > (XEN) Xen stack trace from sp=002cfc20:
> > > (XEN)002cfc70 00240254 002a9f58
> > > 007fc000
> > > (XEN)  
> > > 007fc03c
> > > (XEN)002cfd78  002cfca0
> > > 002986fc
> > > (XEN) 007fc000 
> > > 
> > > (XEN)002cfcc0 00298f1c 
> > > 007fc000
> > > (XEN)002cfdc0 0029904c f47fc000
> > > f4604000
> > > (XEN)f47fc000 007fc000 0040
> > > 0100
> > > (XEN)f4604000 0001 0001
> > > 8002
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  002cfdc0
> > > 00299038
> > > (XEN)f47fc000 f4604000 f47fc000
> > > 
> > > (XEN)002cfe20 0029c420 002d8000
> > > f4604000
> > > (XEN)f47fc000  0040
> > > 0100
> > > (XEN)f4604000 0001 f47fc000
> > > 0029c404
> > > (XEN)fefff510 00200624 f4804000
> > > f4604000
> > > (XEN)f47fc000  0040
> > > 0100
> > > (XEN)0001 0001 0001
> > > 8002
> > > (XEN)f47fc000  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN)  
> > > 
> > > (XEN) Xen call trace:
> > > (XEN)[<00264140>] strlen+0x10/0x84 (PC)
> > > (XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
> > > (XEN)[<00240254>] 

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Andrew Cooper]

On 19/04/2017 22:12, Julien Grall wrote:
> Would you be fine with code motion for Xen 4.9?

The only important question is whether the patch/series is suitable
material for 4.9.  By the looks of this series, it most certainly is
(and at the end of the day, you have final say on this matter).

Other than that, the modification should conform to the normal
guidelines (break different logical changes apart into different
patches, don't skimp on style, etc).

What matters (moreso during a stabilisation period) is review-ability of
the changes, not the quantity of patches.  I'd have no qualms submitting
a 25 patch series for 4.9, if I decided the bugfix was important enough
and 25 patches is what it took to do sensibly.

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

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

[Julien Grall]

Hi Stefano,

On 19/04/2017 22:01, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:

Currently, Xen is assuming the FDT will always fit in a 2MB section.
Recently, I noticed an early crash on Xen when using GRUB with the
following call trace:

(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 00264140 strlen+0x10/0x84
(XEN) LR: 002401c0
(XEN) SP: 002cfc20
(XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 00801230  X1: 00801230  X2: 5230
(XEN)  X3: 0030  X4: 0030  X5: 0038
(XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
(XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
(XEN) X12: 0030 X13: ff00ff00 X14: 08000300
(XEN) X15:  X16: fefff610 X17: 00f0
(XEN) X18: 0004 X19: 0008 X20: 007fc040
(XEN) X21: 007fc000 X22: 000e X23: 
(XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
(XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
(XEN)
(XEN)   VTCR_EL2: 80010c40
(XEN)  VTTBR_EL2: 082800203000
(XEN)
(XEN)  SCTLR_EL2: 30c5183d
(XEN)HCR_EL2: 0038663f
(XEN)  TTBR0_EL2: f4912000
(XEN)
(XEN)ESR_EL2: 9606
(XEN)  HPFAR_EL2: e8071000
(XEN)FAR_EL2: 00801230
(XEN)
(XEN) Xen stack trace from sp=002cfc20:
(XEN)002cfc70 00240254 002a9f58 007fc000
(XEN)   007fc03c
(XEN)002cfd78  002cfca0 002986fc
(XEN) 007fc000  
(XEN)002cfcc0 00298f1c  007fc000
(XEN)002cfdc0 0029904c f47fc000 f4604000
(XEN)f47fc000 007fc000 0040 0100
(XEN)f4604000 0001 0001 8002
(XEN)   
(XEN)   
(XEN)   
(XEN)  002cfdc0 00299038
(XEN)f47fc000 f4604000 f47fc000 
(XEN)002cfe20 0029c420 002d8000 f4604000
(XEN)f47fc000  0040 0100
(XEN)f4604000 0001 f47fc000 0029c404
(XEN)fefff510 00200624 f4804000 f4604000
(XEN)f47fc000  0040 0100
(XEN)0001 0001 0001 8002
(XEN)f47fc000   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) Xen call trace:
(XEN)[<00264140>] strlen+0x10/0x84 (PC)
(XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
(XEN)[<00240254>] fdt_get_property+0x40/0x50
(XEN)[<002986fc>] bootfdt.c#device_tree_get_u32+0x18/0x5c
(XEN)[<00298f1c>] device_tree_for_each_node+0x84/0x144
(XEN)[<0029904c>] boot_fdt_info+0x70/0x23c
(XEN)[<0029c420>] start_xen+0x9c/0xd30
(XEN)[<00200624>] arm64/head.o#paging+0x84/0xbc
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN)
(XEN) 

Indeed, the booting documentation for AArch32 and AArch64 only requires
the FDT to be placed on a 8-byte boundary. This means the Device-Tree can
cross a 2MB boundary.

Given that Xen limits the size of the FDT to 2MB, it 

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Stefano Stabellini]

On Wed, 19 Apr 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 19/04/2017 22:01, Stefano Stabellini wrote:
> > On Wed, 19 Apr 2017, Julien Grall wrote:
> > > The FDT will not be accessed before start_xen (begining of C code) is
> > > called and it will be easier to maintain as the code could be common
> > > between AArch32 and AArch64.
> > > 
> > > A new function early_fdt_map is introduced to map the FDT in the boot
> > > page table.
> > > 
> > > Note that create_mapping will flush the TLBs for us so no need to add an
> > > extra on in case the entry was previously used by the 1:1 mapping.
> > > 
> > > Signed-off-by: Julien Grall 
> > > 
> > > ---
> > > 
> > > I can move the function create_mappings at the beginning of the
> > > function instead of adding a static declaration. But I thought it
> > > was not Xen 4.9 material. Any opinions?
> > > ---
> > >  xen/arch/arm/arm32/head.S | 14 --
> > >  xen/arch/arm/arm64/head.S | 13 -
> > >  xen/arch/arm/mm.c | 20 
> > >  xen/arch/arm/setup.c  |  4 +---
> > >  xen/include/asm-arm/mm.h  |  2 ++
> > >  5 files changed, 23 insertions(+), 30 deletions(-)
> > > 
> > > diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> > > index ec63ba4c04..4090f4a744 100644
> > > --- a/xen/arch/arm/arm32/head.S
> > > +++ b/xen/arch/arm/arm32/head.S
> > > @@ -389,20 +389,6 @@ paging:
> > >  /* Use a virtual address to access the UART. */
> > >  ldr   r11, =EARLY_UART_VIRTUAL_ADDRESS
> > >  #endif
> > > -/* Map the DTB in the boot misc slot */
> > > -teq   r12, #0/* Only on boot CPU */
> > > -bne   1f
> > > -
> > > -ldr   r1, =boot_second
> > > -mov   r3, #0x0
> > > -lsr   r2, r8, #SECOND_SHIFT
> > > -lsl   r2, r2, #SECOND_SHIFT  /* r2: 2MB-aligned paddr of DTB */
> > > -orr   r2, r2, #PT_UPPER(MEM)
> > > -orr   r2, r2, #PT_LOWER(MEM) /* r2:r3 := 2MB RAM incl. DTB */
> > > -ldr   r4, =BOOT_FDT_VIRT_START
> > > -mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* Slot for
> > > BOOT_FDT_VIRT_START */
> > > -strd  r2, r3, [r1, r4]   /* Map it in the early fdt slot */
> > > -1:
> > > 
> > >  /*
> > >   * Flush the TLB in case the 1:1 mapping happens to clash with
> > > diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> > > index 72ea4e0233..78292f4396 100644
> > > --- a/xen/arch/arm/arm64/head.S
> > > +++ b/xen/arch/arm/arm64/head.S
> > > @@ -550,19 +550,6 @@ paging:
> > >  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
> > >  #endif
> > > 
> > > -/* Map the DTB in the boot misc slot */
> > > -cbnz  x22, 1f/* Only on boot CPU */
> > > -
> > > -ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
> > > -lsr   x2, x21, #SECOND_SHIFT
> > > -lsl   x2, x2, #SECOND_SHIFT  /* x2 := 2MB-aligned paddr of DTB */
> > > -mov   x3, #PT_MEM/* x2 := 2MB RAM incl. DTB */
> > > -orr   x2, x2, x3
> > > -ldr   x1, =BOOT_FDT_VIRT_START
> > > -lsr   x1, x1, #(SECOND_SHIFT - 3)   /* x4 := Slot for
> > > BOOT_FDT_VIRT_START */
> > > -str   x2, [x4, x1]   /* Map it in the early fdt slot */
> > > -1:
> > > -
> > >  /*
> > >   * Flush the TLB in case the 1:1 mapping happens to clash with
> > >   * the virtual addresses used by the fixmap or DTB.
> > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > > index f0a2eddaaf..0d076489c6 100644
> > > --- a/xen/arch/arm/mm.c
> > > +++ b/xen/arch/arm/mm.c
> > > @@ -38,6 +38,13 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > > +
> > > +static void __init create_mappings(lpae_t *second,
> > > +   unsigned long virt_offset,
> > > +   unsigned long base_mfn,
> > > +   unsigned long nr_mfns,
> > > +   unsigned int mapping_size);
> > 
> > I would have added early_fdt_map to this file in a way to avoid the need
> > for duplicating the declaration of create_mappings (because this version
> > doesn't have the useful comment on top).
> 
> I wanted to keep the function close to the counterpart remove_early_mappings
> rather than adding somewhere that make less sense.
> 
> Hence why I suggested to move the create_mappings function. Would you be fine
> with code motion for Xen 4.9?

Sure. But please keep the code motion in its own separate patch.

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

Re: [Xen-devel] [PATCH for-4.9 3/4] xen/arm: Check if the FDT passed by the bootloader is valid

[Julien Grall]

Hi Stefano,

On 19/04/2017 22:01, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:

There is currently no sanity check on the FDT passed by the bootloader.
Whilst they are stricly not necessary, it will avoid us to spend hours
to try to find out why it does not work.

>From the booting documentation for AArch32 [1] and AArch64 [2] must :
- be placed on 8-byte boundary
- not exceed 2MB (only on AArch64)

Even if AArch32 does not seem to limit the size, Xen is not currently
able to support more the 2MB FDT. It is better to crash rather with a nice
error message than claiming we are supporting any size of FDT.

The checks are mostly borrowed from the Linux code (see fixmap_remap_fdt
in arch/arm64/mm/mmu.c).

[1] Section 2 in linux/Documentation/arm64/booting.txt
[2] Section 4b in linux/Documentation/arm/Booting

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c   | 29 -
 xen/arch/arm/setup.c|  6 ++
 xen/include/asm-arm/setup.h |  3 +++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0d076489c6..53d36e2ce2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 

 static void __init create_mappings(lpae_t *second,
unsigned long virt_offset,
@@ -447,11 +449,36 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 {
 /* We are using 2MB superpage for mapping the FDT */
 paddr_t base_paddr = fdt_paddr & SECOND_MASK;
+paddr_t offset;
+void *fdt_virt;
+
+/*
+ * Check whether the physical FDT address is set and meets the minimum
+ * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
+ * least 8 bytes so that we always access the magic and size fields
+ * of the FDT header after mapping the first chunk, double check if
+ * that is indeed the case.
+ */
+BUILD_BUG_ON(MIN_FDT_ALIGN < 8);


I think that this BUILD_BUG_ON is overkill, a comment would be enough



+if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
+return NULL;
+
+/* The FDT is mapped using 2MB superpage */
+BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);


Same here.


Whilst I agree the first one is not that useful, this one will catch any 
change in the memory memory map that will not keep BOOT_FDT_VIRT_START 
2MB aligned.






 create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
 SZ_2M >> PAGE_SHIFT, SZ_2M);

-return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
+offset = fdt_paddr % SECOND_SIZE;
+fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;


offset is useless, you can just:


It will be useful later on and wanted to avoid too much code 
modification in later patch.




  fdt_virt = (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);



+if ( fdt_magic(fdt_virt) != FDT_MAGIC )
+return NULL;
+
+if ( fdt_totalsize(fdt_virt) > MAX_FDT_SIZE )
+return NULL;
+
+return fdt_virt;
 }

 void __init remove_early_mappings(void)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 986398970f..8f72f31fb5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -725,6 +725,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 smp_clear_cpu_maps();

 device_tree_flattened = early_fdt_map(fdt_paddr);
+if ( !device_tree_flattened )
+panic("Invalid device tree blob at physical address %#lx\n"
+  "The DTB must be 8-byte aligned and must not exceed 2 MB in 
size\n"
+  "\nPlease check your bootloader.",
+  fdt_paddr);


Strange, why did you place the "\n" at the beginning of the line?


I blindly copied from the kernel. I can fix that.



These are all minor stylistic nits, so

Reviewed-by: Stefano Stabellini 



 fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);

 cmdline = boot_fdt_cmdline(device_tree_flattened);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7c761851d2..7ff2c34dab 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,9 @@

 #include 

+#define MIN_FDT_ALIGN 8
+#define MAX_FDT_SIZE SZ_2M
+
 #define NR_MEM_BANKS 64

 #define MAX_MODULES 5 /* Current maximum useful modules */
--
2.11.0



--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Julien Grall]

Hi Stefano,

On 19/04/2017 22:01, Stefano Stabellini wrote:

On Wed, 19 Apr 2017, Julien Grall wrote:

The FDT will not be accessed before start_xen (begining of C code) is
called and it will be easier to maintain as the code could be common
between AArch32 and AArch64.

A new function early_fdt_map is introduced to map the FDT in the boot
page table.

Note that create_mapping will flush the TLBs for us so no need to add an
extra on in case the entry was previously used by the 1:1 mapping.

Signed-off-by: Julien Grall 

---

I can move the function create_mappings at the beginning of the
function instead of adding a static declaration. But I thought it
was not Xen 4.9 material. Any opinions?
---
 xen/arch/arm/arm32/head.S | 14 --
 xen/arch/arm/arm64/head.S | 13 -
 xen/arch/arm/mm.c | 20 
 xen/arch/arm/setup.c  |  4 +---
 xen/include/asm-arm/mm.h  |  2 ++
 5 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index ec63ba4c04..4090f4a744 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -389,20 +389,6 @@ paging:
 /* Use a virtual address to access the UART. */
 ldr   r11, =EARLY_UART_VIRTUAL_ADDRESS
 #endif
-/* Map the DTB in the boot misc slot */
-teq   r12, #0/* Only on boot CPU */
-bne   1f
-
-ldr   r1, =boot_second
-mov   r3, #0x0
-lsr   r2, r8, #SECOND_SHIFT
-lsl   r2, r2, #SECOND_SHIFT  /* r2: 2MB-aligned paddr of DTB */
-orr   r2, r2, #PT_UPPER(MEM)
-orr   r2, r2, #PT_LOWER(MEM) /* r2:r3 := 2MB RAM incl. DTB */
-ldr   r4, =BOOT_FDT_VIRT_START
-mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* Slot for 
BOOT_FDT_VIRT_START */
-strd  r2, r3, [r1, r4]   /* Map it in the early fdt slot */
-1:

 /*
  * Flush the TLB in case the 1:1 mapping happens to clash with
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 72ea4e0233..78292f4396 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -550,19 +550,6 @@ paging:
 ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
 #endif

-/* Map the DTB in the boot misc slot */
-cbnz  x22, 1f/* Only on boot CPU */
-
-ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
-lsr   x2, x21, #SECOND_SHIFT
-lsl   x2, x2, #SECOND_SHIFT  /* x2 := 2MB-aligned paddr of DTB */
-mov   x3, #PT_MEM/* x2 := 2MB RAM incl. DTB */
-orr   x2, x2, x3
-ldr   x1, =BOOT_FDT_VIRT_START
-lsr   x1, x1, #(SECOND_SHIFT - 3)   /* x4 := Slot for 
BOOT_FDT_VIRT_START */
-str   x2, [x4, x1]   /* Map it in the early fdt slot */
-1:
-
 /*
  * Flush the TLB in case the 1:1 mapping happens to clash with
  * the virtual addresses used by the fixmap or DTB.
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f0a2eddaaf..0d076489c6 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -38,6 +38,13 @@
 #include 
 #include 
 #include 
+#include 
+
+static void __init create_mappings(lpae_t *second,
+   unsigned long virt_offset,
+   unsigned long base_mfn,
+   unsigned long nr_mfns,
+   unsigned int mapping_size);


I would have added early_fdt_map to this file in a way to avoid the need
for duplicating the declaration of create_mappings (because this version
doesn't have the useful comment on top).


I wanted to keep the function close to the counterpart 
remove_early_mappings rather than adding somewhere that make less sense.


Hence why I suggested to move the create_mappings function. Would you be 
fine with code motion for Xen 4.9?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.9 1/4] xen/arm: Add BOOT_FDT_VIRT_END and BOOT_FDT_SLOT_SIZE

[Stefano Stabellini]

On Wed, 19 Apr 2017, Julien Grall wrote:
> The 2 new defines will help to avoid hardcoding the size and the end of
> the slot in the code.
> 
> The newlines are added for clarity.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/include/asm-arm/config.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
> index b2edf95f72..9c14a385e7 100644
> --- a/xen/include/asm-arm/config.h
> +++ b/xen/include/asm-arm/config.h
> @@ -111,7 +111,11 @@
>  
>  #define XEN_VIRT_START _AT(vaddr_t,0x0020)
>  #define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)
> +
>  #define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060)
> +#define BOOT_FDT_SLOT_SIZE MB(2)
> +#define BOOT_FDT_VIRT_END  (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)
> +
>  #define BOOT_RELOC_VIRT_START  _AT(vaddr_t,0x0080)
>  #ifdef CONFIG_LIVEPATCH
>  #define LIVEPATCH_VMAP_START   _AT(vaddr_t,0x0080)
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Stefano Stabellini]

On Wed, 19 Apr 2017, Julien Grall wrote:
> The FDT will not be accessed before start_xen (begining of C code) is
> called and it will be easier to maintain as the code could be common
> between AArch32 and AArch64.
> 
> A new function early_fdt_map is introduced to map the FDT in the boot
> page table.
> 
> Note that create_mapping will flush the TLBs for us so no need to add an
> extra on in case the entry was previously used by the 1:1 mapping.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> I can move the function create_mappings at the beginning of the
> function instead of adding a static declaration. But I thought it
> was not Xen 4.9 material. Any opinions?
> ---
>  xen/arch/arm/arm32/head.S | 14 --
>  xen/arch/arm/arm64/head.S | 13 -
>  xen/arch/arm/mm.c | 20 
>  xen/arch/arm/setup.c  |  4 +---
>  xen/include/asm-arm/mm.h  |  2 ++
>  5 files changed, 23 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
> index ec63ba4c04..4090f4a744 100644
> --- a/xen/arch/arm/arm32/head.S
> +++ b/xen/arch/arm/arm32/head.S
> @@ -389,20 +389,6 @@ paging:
>  /* Use a virtual address to access the UART. */
>  ldr   r11, =EARLY_UART_VIRTUAL_ADDRESS
>  #endif
> -/* Map the DTB in the boot misc slot */
> -teq   r12, #0/* Only on boot CPU */
> -bne   1f
> -
> -ldr   r1, =boot_second
> -mov   r3, #0x0
> -lsr   r2, r8, #SECOND_SHIFT
> -lsl   r2, r2, #SECOND_SHIFT  /* r2: 2MB-aligned paddr of DTB */
> -orr   r2, r2, #PT_UPPER(MEM)
> -orr   r2, r2, #PT_LOWER(MEM) /* r2:r3 := 2MB RAM incl. DTB */
> -ldr   r4, =BOOT_FDT_VIRT_START
> -mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* Slot for 
> BOOT_FDT_VIRT_START */
> -strd  r2, r3, [r1, r4]   /* Map it in the early fdt slot */
> -1:
>  
>  /*
>   * Flush the TLB in case the 1:1 mapping happens to clash with
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 72ea4e0233..78292f4396 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -550,19 +550,6 @@ paging:
>  ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
>  #endif
>  
> -/* Map the DTB in the boot misc slot */
> -cbnz  x22, 1f/* Only on boot CPU */
> -
> -ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
> -lsr   x2, x21, #SECOND_SHIFT
> -lsl   x2, x2, #SECOND_SHIFT  /* x2 := 2MB-aligned paddr of DTB */
> -mov   x3, #PT_MEM/* x2 := 2MB RAM incl. DTB */
> -orr   x2, x2, x3
> -ldr   x1, =BOOT_FDT_VIRT_START
> -lsr   x1, x1, #(SECOND_SHIFT - 3)   /* x4 := Slot for 
> BOOT_FDT_VIRT_START */
> -str   x2, [x4, x1]   /* Map it in the early fdt slot */
> -1:
> -
>  /*
>   * Flush the TLB in case the 1:1 mapping happens to clash with
>   * the virtual addresses used by the fixmap or DTB.
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index f0a2eddaaf..0d076489c6 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -38,6 +38,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +static void __init create_mappings(lpae_t *second,
> +   unsigned long virt_offset,
> +   unsigned long base_mfn,
> +   unsigned long nr_mfns,
> +   unsigned int mapping_size);

I would have added early_fdt_map to this file in a way to avoid the need
for duplicating the declaration of create_mappings (because this version
doesn't have the useful comment on top).

In any case

Reviewed-by: Stefano Stabellini 


>  struct domain *dom_xen, *dom_io, *dom_cow;
>  
> @@ -434,6 +441,19 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
>  return mfn_to_xen_entry(mfn, WRITEALLOC);
>  }
>  
> +
> +/* Map the FDT in the early boot page table */
> +void * __init early_fdt_map(paddr_t fdt_paddr)
> +{
> +/* We are using 2MB superpage for mapping the FDT */
> +paddr_t base_paddr = fdt_paddr & SECOND_MASK;
> +
> +create_mappings(boot_second, BOOT_FDT_VIRT_START, 
> paddr_to_pfn(base_paddr),
> +SZ_2M >> PAGE_SHIFT, SZ_2M);
> +
> +return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
> +}
> +
>  void __init remove_early_mappings(void)
>  {
>  lpae_t pte = {0};
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 92a2de6b70..986398970f 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -724,9 +724,7 @@ void __init start_xen(unsigned long boot_phys_offset,
>  
>  smp_clear_cpu_maps();
>  
> -/* This is mapped by head.S */
> -device_tree_flattened = (void *)BOOT_FDT_VIRT_START
> -+ (fdt_paddr & ((1 << SECOND_SHIFT) - 

Re: [Xen-devel] [PATCH for-4.9 3/4] xen/arm: Check if the FDT passed by the bootloader is valid

[Stefano Stabellini]

On Wed, 19 Apr 2017, Julien Grall wrote:
> There is currently no sanity check on the FDT passed by the bootloader.
> Whilst they are stricly not necessary, it will avoid us to spend hours
> to try to find out why it does not work.
> 
> >From the booting documentation for AArch32 [1] and AArch64 [2] must :
> - be placed on 8-byte boundary
> - not exceed 2MB (only on AArch64)
> 
> Even if AArch32 does not seem to limit the size, Xen is not currently
> able to support more the 2MB FDT. It is better to crash rather with a nice
> error message than claiming we are supporting any size of FDT.
> 
> The checks are mostly borrowed from the Linux code (see fixmap_remap_fdt
> in arch/arm64/mm/mmu.c).
> 
> [1] Section 2 in linux/Documentation/arm64/booting.txt
> [2] Section 4b in linux/Documentation/arm/Booting
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/mm.c   | 29 -
>  xen/arch/arm/setup.c|  6 ++
>  xen/include/asm-arm/setup.h |  3 +++
>  3 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> index 0d076489c6..53d36e2ce2 100644
> --- a/xen/arch/arm/mm.c
> +++ b/xen/arch/arm/mm.c
> @@ -39,6 +39,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  static void __init create_mappings(lpae_t *second,
> unsigned long virt_offset,
> @@ -447,11 +449,36 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
>  {
>  /* We are using 2MB superpage for mapping the FDT */
>  paddr_t base_paddr = fdt_paddr & SECOND_MASK;
> +paddr_t offset;
> +void *fdt_virt;
> +
> +/*
> + * Check whether the physical FDT address is set and meets the minimum
> + * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
> + * least 8 bytes so that we always access the magic and size fields
> + * of the FDT header after mapping the first chunk, double check if
> + * that is indeed the case.
> + */
> +BUILD_BUG_ON(MIN_FDT_ALIGN < 8);

I think that this BUILD_BUG_ON is overkill, a comment would be enough


> +if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
> +return NULL;
> +
> +/* The FDT is mapped using 2MB superpage */
> +BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);

Same here.


>  create_mappings(boot_second, BOOT_FDT_VIRT_START, 
> paddr_to_pfn(base_paddr),
>  SZ_2M >> PAGE_SHIFT, SZ_2M);
>  
> -return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
> +offset = fdt_paddr % SECOND_SIZE;
> +fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;

offset is useless, you can just:

  fdt_virt = (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);


> +if ( fdt_magic(fdt_virt) != FDT_MAGIC )
> +return NULL;
> +
> +if ( fdt_totalsize(fdt_virt) > MAX_FDT_SIZE )
> +return NULL;
> +
> +return fdt_virt;
>  }
>  
>  void __init remove_early_mappings(void)
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index 986398970f..8f72f31fb5 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -725,6 +725,12 @@ void __init start_xen(unsigned long boot_phys_offset,
>  smp_clear_cpu_maps();
>  
>  device_tree_flattened = early_fdt_map(fdt_paddr);
> +if ( !device_tree_flattened )
> +panic("Invalid device tree blob at physical address %#lx\n"
> +  "The DTB must be 8-byte aligned and must not exceed 2 MB in 
> size\n"
> +  "\nPlease check your bootloader.",
> +  fdt_paddr);

Strange, why did you place the "\n" at the beginning of the line?

These are all minor stylistic nits, so

Reviewed-by: Stefano Stabellini 


>  fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
>  
>  cmdline = boot_fdt_cmdline(device_tree_flattened);
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 7c761851d2..7ff2c34dab 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -3,6 +3,9 @@
>  
>  #include 
>  
> +#define MIN_FDT_ALIGN 8
> +#define MAX_FDT_SIZE SZ_2M
> +
>  #define NR_MEM_BANKS 64
>  
>  #define MAX_MODULES 5 /* Current maximum useful modules */
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

[Stefano Stabellini]

On Wed, 19 Apr 2017, Julien Grall wrote:
> Currently, Xen is assuming the FDT will always fit in a 2MB section.
> Recently, I noticed an early crash on Xen when using GRUB with the
> following call trace:
> 
> (XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
> (XEN) CPU0: Unexpected Trap: Hypervisor
> (XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
> (XEN) CPU:0
> (XEN) PC: 00264140 strlen+0x10/0x84
> (XEN) LR: 002401c0
> (XEN) SP: 002cfc20
> (XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
> (XEN)  X0: 00801230  X1: 00801230  X2: 5230
> (XEN)  X3: 0030  X4: 0030  X5: 0038
> (XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
> (XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
> (XEN) X12: 0030 X13: ff00ff00 X14: 08000300
> (XEN) X15:  X16: fefff610 X17: 00f0
> (XEN) X18: 0004 X19: 0008 X20: 007fc040
> (XEN) X21: 007fc000 X22: 000e X23: 
> (XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
> (XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
> (XEN)
> (XEN)   VTCR_EL2: 80010c40
> (XEN)  VTTBR_EL2: 082800203000
> (XEN)
> (XEN)  SCTLR_EL2: 30c5183d
> (XEN)HCR_EL2: 0038663f
> (XEN)  TTBR0_EL2: f4912000
> (XEN)
> (XEN)ESR_EL2: 9606
> (XEN)  HPFAR_EL2: e8071000
> (XEN)FAR_EL2: 00801230
> (XEN)
> (XEN) Xen stack trace from sp=002cfc20:
> (XEN)002cfc70 00240254 002a9f58 007fc000
> (XEN)   007fc03c
> (XEN)002cfd78  002cfca0 002986fc
> (XEN) 007fc000  
> (XEN)002cfcc0 00298f1c  007fc000
> (XEN)002cfdc0 0029904c f47fc000 f4604000
> (XEN)f47fc000 007fc000 0040 0100
> (XEN)f4604000 0001 0001 8002
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)  002cfdc0 00299038
> (XEN)f47fc000 f4604000 f47fc000 
> (XEN)002cfe20 0029c420 002d8000 f4604000
> (XEN)f47fc000  0040 0100
> (XEN)f4604000 0001 f47fc000 0029c404
> (XEN)fefff510 00200624 f4804000 f4604000
> (XEN)f47fc000  0040 0100
> (XEN)0001 0001 0001 8002
> (XEN)f47fc000   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN)   
> (XEN) Xen call trace:
> (XEN)[<00264140>] strlen+0x10/0x84 (PC)
> (XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
> (XEN)[<00240254>] fdt_get_property+0x40/0x50
> (XEN)[<002986fc>] bootfdt.c#device_tree_get_u32+0x18/0x5c
> (XEN)[<00298f1c>] device_tree_for_each_node+0x84/0x144
> (XEN)[<0029904c>] boot_fdt_info+0x70/0x23c
> (XEN)[<0029c420>] start_xen+0x9c/0xd30
> (XEN)[<00200624>] arm64/head.o#paging+0x84/0xbc
> (XEN)
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) CPU0: Unexpected Trap: Hypervisor
> (XEN)
> (XEN) 
> 
> Indeed, the booting documentation for AArch32 and AArch64 only requires
> the FDT to be placed on a 8-byte boundary. 

[Xen-devel] [PATCH v4 0/2] kexec: Use hypercall_create_continuation to protect KEXEC ops

[Eric DeVolder]

During testing (using the script below) we found that multiple
invocations of kexec of unload/load are not safe.

This does not exist in classic Xen kernels in which the kexec-tools
did the kexec via Linux kernel syscall (which in turn made the
hypercall), as the Linux code has a mutex_trylock which would
inhibit multiple concurrent calls.

But with the kexec-tools utilizing xc_kexec_* that is no longer
the case and we need to protect against multiple concurrent
invocations.

Please see the patches and review at your convenience!

 try-crash.pl from bhavesh.da...@oracle.com 
#!/usr/bin/perl -w

use strict;
use warnings;
use threads;

sub threaded_task {
threads->create(sub {
my $thr_id = threads->self->tid;
#print "Starting load thread $thr_id\n";
system("/sbin/kexec  -p --command-line=\"placeholder 
root=/dev/mapper/nimbula-root ro rhbg console=tty0 console=hvc0 earlyprintk=xen 
nomodeset printk.time=1 irqpoll maxcpus=1 nr_cpus=1 reset_devices 
cgroup_disable=memory mce=off selinux=0 console=ttyS1,115200n8\" 
--initrd=/boot/initrd-4.1.12-61.1.9.el6uek.x86_64kdump.img 
/boot/vmlinuz-4.1.12-61.1.9.el6uek.x86_64");
#print "Ending load thread $thr_id\n";
threads->detach(); #End thread.
});
threads->create(sub {
my $thr_id = threads->self->tid;
#print "Starting unload thread $thr_id\n";
system("/sbin/kexec  -p -u");
#print "Ending unload thread $thr_id\n";
threads->detach(); #End thread.
});
}

for my $i (0..99)
{
threaded_task();
}


Eric DeVolder (2):
  kexec: use hypercall_create_continuation to protect KEXEC ops
  kexec: remove spinlock now that all KEXEC hypercall ops are protected
at the top-level

 xen/common/kexec.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v4 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

[Eric DeVolder]

When we concurrently try to unload and load crash
images we eventually get:

 Xen call trace:
[] machine_kexec_add_page+0x3a0/0x3fa
[] machine_kexec_load+0xdb/0x107
[] kexec.c#kexec_load_slot+0x11/0x42
[] kexec.c#kexec_load+0x119/0x150
[] kexec.c#do_kexec_op_internal+0xab/0xcf
[] do_kexec_op+0xe/0x1e
[] pv_hypercall+0x20a/0x44a
[] cpufreq.c#test_all_events+0/0x30

 Pagetable walk from 820040088320:
  L4[0x104] = 0002979d1063 
  L3[0x001] = 0002979d0063 
  L2[0x000] = 0002979c7063 
  L1[0x088] = 80037a91ede97063 

The interesting thing is that the page bits (063) look legit.

The operation on which we blow up is us trying to write
in the L1 and finding that the L2 entry points to some
bizzare MFN. It stinks of a race, and it looks like
the issue is due to no concurrency locks when dealing
with the crash kernel space.

Specifically we concurrently call kimage_alloc_crash_control_page
which iterates over the kexec_crash_area.start -> kexec_crash_area.size
and once found:

  if ( page )
  {
  image->next_crash_page = hole_end;
  clear_domain_page(_mfn(page_to_mfn(page)));
  }

clears. Since the parameters of what MFN to use are provided
by the callers (and the area to search is bounded) the the 'page'
is probably the same. So #1 we concurrently clear the
'control_code_page'.

The next step is us passing this 'control_code_page' to
machine_kexec_add_page. This function requires the MFNs:
page_to_maddr(image->control_code_page).

And this would always return the same virtual address, as
the MFN of the control_code_page is inside of the
kexec_crash_area.start -> kexec_crash_area.size area.

Then machine_kexec_add_page updates the L1 .. which can be done
concurrently and on subsequent calls we mangle it up.

This is all a theory at this time, but testing reveals
that adding the hypercall_create_continuation() at the
kexec hypercall fixes the crash.

NOTE: This patch follows 5c5216 (kexec: clear kexec_image slot
when unloading kexec image) to prevent crashes during
simultaneous load/unloads.

NOTE: Consideration was given to using the existing flag
KEXEC_FLAG_IN_PROGRESS to denote a kexec hypercall in
progress. This, however, overloads the original intent of
the flag which is to denote that we are about-to/have made
the jump to the crash path. The overloading would lead to
failures in existing checks on this flag as the flag would
always be set at the top level in do_kexec_op_internal().
For this reason, the new flag KEXEC_FLAG_HC_IN_PROGRESS
was introduced.

While at it, fixed the #define mismatched spacing

Signed-off-by: Eric DeVolder 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Reviewed-by: Daniel Kiper 
---
v4: 04/19/2017
 - Unchanged

v3: 04/19/2017
 - Incorporated feedback from Jan Beulich to change the
   name of the new flag to KEXEC_FLAG_IN_HYPERCALL

v2: 04/17/2017
 - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC ops'
 - Jan Beulich directed me to use a continuation method instead
   of spinlock.
 - Incorporated feedback from Daniel Kiper 
 - Incorporated feedback from Konrad Wilk 

v1: 04/10/2017
 - Patch titled 'kexec: Add spinlock for the whole hypercall'
 - Used spinlock in do_kexec_op_internal()
---
 xen/common/kexec.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 072cc8e..253c204 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus;
 
 static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];
 
-#define KEXEC_FLAG_DEFAULT_POS   (KEXEC_IMAGE_NR + 0)
-#define KEXEC_FLAG_CRASH_POS (KEXEC_IMAGE_NR + 1)
-#define KEXEC_FLAG_IN_PROGRESS   (KEXEC_IMAGE_NR + 2)
+#define KEXEC_FLAG_DEFAULT_POS  (KEXEC_IMAGE_NR + 0)
+#define KEXEC_FLAG_CRASH_POS(KEXEC_IMAGE_NR + 1)
+#define KEXEC_FLAG_IN_PROGRESS  (KEXEC_IMAGE_NR + 2)
+#define KEXEC_FLAG_IN_HYPERCALL (KEXEC_IMAGE_NR + 3)
 
 static unsigned long kexec_flags = 0; /* the lowest bits are for 
KEXEC_IMAGE... */
 
@@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op,
 if ( ret )
 return ret;
 
+if ( test_and_set_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) )
+return hypercall_create_continuation(__HYPERVISOR_kexec_op, "lh", op, 
uarg);
+
 switch ( op )
 {
 case KEXEC_CMD_kexec_get_range:
@@ -1227,6 +1231,8 @@ static int do_kexec_op_internal(unsigned long op,
 break;
 }
 
+clear_bit(KEXEC_FLAG_IN_HYPERCALL, _flags);
+
 return ret;
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v4 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Eric DeVolder]

The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec hypercall, which is
now protected at the top-level in do_kexec_op_internal(),
thus the local spinlock is no longer necessary.

Per recommendation from Jan Beulich and Andrew Cooper, I left
an ASSERT in place of the spin_lock().

Signed-off-by: Eric DeVolder 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v4: 04/19/2017
 - Fix ASSERT to work properly. Tested with Config.mk:debug=y

v3: 04/19/2017
 - Incorporated feedback from Jan Beulich and Andrew Cooper
   to leave an ASSERT where spin_lock() once was.

v2: 04/17/2017
 - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC ops'
 - Separated removal of spinlock in kexec_swap_images() into its own patch.

v1: 04/10/2017
 - Patch titled 'kexec: Add spinlock for the whole hypercall'
 - Removal of spinlock in kexec_swap_images() was part of other patch.
---
 xen/common/kexec.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 253c204..96efa3b 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -820,7 +820,6 @@ static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
 static int kexec_swap_images(int type, struct kexec_image *new,
  struct kexec_image **old)
 {
-static DEFINE_SPINLOCK(kexec_lock);
 int base, bit, pos;
 int new_slot, old_slot;
 
@@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 if ( kexec_load_get_bits(type, , ) )
 return -EINVAL;
 
-spin_lock(_lock);
+ASSERT(test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags));
 
 pos = (test_bit(bit, _flags) != 0);
 old_slot = base + pos;
@@ -846,8 +845,6 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 clear_bit(old_slot, _flags);
 *old = kexec_image[old_slot];
 
-spin_unlock(_lock);
-
 return 0;
 }
 
-- 
2.7.4


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 71195
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71195
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71195
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71195
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71195
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71195
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71195
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 71195
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 71195

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  828aa3352f97b613bd06daf7eb1ae734262196be
baseline version:
 xen  e412c03be25dee8202a440b973561afd8ab6d868

Last test of basis71195  2017-04-14 18:45:06 Z5 days
Testing same since71205  2017-04-19 10:14:47 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Ian Jackson 
  Razvan Cojocaru 
  Wei Liu 

jobs:
 build-amd64-xsm 

Re: [Xen-devel] [PATCH 1/6] xen/arm: platforms: Add earlyprintk and serial support for Tegra boards.

[Chris Patterson]

Will split patches & fix for v2, thanks!

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep  fail REGR. vs. 107540

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f97838bbd980a0104e16c4a12fbf514f9fa805f1
baseline version:
 xen  5d1ad47ff7940d95c322667678a190c8607754b4

Last test of basis   107540  2017-04-19 12:02:20 Z0 days
Testing same since   107544  2017-04-19 17:03:35 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ross Lagerwall 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  blocked 
 test-arm64-arm64-xl-xsm  broken  
 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


Not pushing.


commit f97838bbd980a0104e16c4a12fbf514f9fa805f1
Author: Ross Lagerwall 
Date:   Tue Apr 18 16:47:24 2017 +0100

x86: Move microcode loading earlier

Move microcode loading earlier for the boot CPU and secondary CPUs so
that it takes place before identify_cpu() is called for each CPU.
Without this, the detected features may be wrong if the new microcode
loading adjusts the feature bits. That could mean that some fixes (e.g.
d6e9f8d4f35d ("x86/vmx: fix vmentry failure with TSX bits in LBR"))
don't work as expected.

Previously during boot, the microcode loader was invoked for each
secondary CPU started and then again for each CPU as part of an
initcall. Simplify the code so that it is invoked exactly once for each
CPU during boot.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Andrew Cooper 
Tested-by: Andrew Cooper 
Release-acked-by: Julien Grall 
(qemu changes not included)

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

[Xen-devel] [ovmf baseline-only test] 71206: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 33cc487c263384451aef77fa5d749fd4f3d78b7d
baseline version:
 ovmf f76bc44362e5f0a2ea509c07b2f6846bd9833ee8

Last test of basis71202  2017-04-18 17:20:30 Z1 days
Testing same since71206  2017-04-19 17:21:20 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit 33cc487c263384451aef77fa5d749fd4f3d78b7d
Author: Ruiyu Ni 
Date:   Mon Apr 17 11:03:54 2017 +0800

ShellPkg/Pci: Always dump the extended config space for PCIE

It is to align to the original behavior before "-ec" option was
added.

The patch also refines the code to make it more readable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Reviewed-by: Jaben Carsey 
Cc: Jim Dailey 

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

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Daniel Kiper]

On Wed, Apr 19, 2017 at 08:37:38PM +0100, Matt Fleming wrote:
> On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote:
> > On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote:
> > > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
> > > >
> > > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> > > > rather than spreading it further.
> > > >
> > > > IMO, given reset_system is a *mandatory* function, the Xen wrapper
> > > > should provide an implementation.
> > > >
> > > > I don't see why you can't implement a wrapper that calls the usual Xen
> > > > poweroff/reset functions.
> > >
> > > I realise I'm making a sweeping generalisation, but adding
> > > EFI_PARAVIRT is almost always the wrong thing to do.
> >
> > Why?
>
> Because it makes paravirt a special case, and there's usually very
> little reason to make it special in the EFI code. Special-casing means
> more branches, more code paths, a bigger testing matrix and more
> complex code.
>
> EFI_PARAVIRT does have its uses, like for those scenarios where we
> don't have a table of function pointers that can be overidden for
> paravirt.
>
> But we do have such a table for ->reset_system().

This is more or less what I expected. Thanks a lot for explanation.

Daniel

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

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Matt Fleming]

On Wed, 19 Apr, at 09:29:06PM, Daniel Kiper wrote:
> On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote:
> > On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
> > >
> > > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> > > rather than spreading it further.
> > >
> > > IMO, given reset_system is a *mandatory* function, the Xen wrapper
> > > should provide an implementation.
> > >
> > > I don't see why you can't implement a wrapper that calls the usual Xen
> > > poweroff/reset functions.
> >
> > I realise I'm making a sweeping generalisation, but adding
> > EFI_PARAVIRT is almost always the wrong thing to do.
> 
> Why?
 
Because it makes paravirt a special case, and there's usually very
little reason to make it special in the EFI code. Special-casing means
more branches, more code paths, a bigger testing matrix and more
complex code. 

EFI_PARAVIRT does have its uses, like for those scenarios where we
don't have a table of function pointers that can be overidden for
paravirt.

But we do have such a table for ->reset_system().

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

Re: [Xen-devel] [PATCH] arm64: xen: Implement EFI reset_system callback

[Daniel Kiper]

On Tue, Apr 18, 2017 at 02:46:50PM +0100, Matt Fleming wrote:
> On Thu, 06 Apr, at 04:55:11PM, Mark Rutland wrote:
> >
> > Please, let's keep the Xen knowledge constrained to the Xen EFI wrapper,
> > rather than spreading it further.
> >
> > IMO, given reset_system is a *mandatory* function, the Xen wrapper
> > should provide an implementation.
> >
> > I don't see why you can't implement a wrapper that calls the usual Xen
> > poweroff/reset functions.
>
> I realise I'm making a sweeping generalisation, but adding
> EFI_PARAVIRT is almost always the wrong thing to do.

Why?

> I'd much prefer to see Mark's idea implemented.

If you wish I do not object.

Daniel

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

Re: [Xen-devel] [PATCH 07/10] xen/arm: vpl011: Add a new console type to domain structure in xenconsole

[Stefano Stabellini]

On Mon, 3 Apr 2017, Bhupinder Thakur wrote:
> Modify the domain structure to to make console specific fields as an array 
> indexed
> by the console type. Two console types are defined - PV and VCON.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
>  tools/console/daemon/io.c | 24 +++-
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> index 7e6a886..0cd1fee 100644
> --- a/tools/console/daemon/io.c
> +++ b/tools/console/daemon/io.c
> @@ -61,6 +61,10 @@
>  /* Duration of each time period in ms */
>  #define RATE_LIMIT_PERIOD 200
>  
> +#define MAX_CONSOLE 2
> +#define CONSOLE_TYPE_PV 0
> +#define CONSOLE_TYPE_VCON 1
> +
>  extern int log_reload;
>  extern int log_guest;
>  extern int log_hv;
> @@ -91,23 +95,25 @@ struct buffer {
>  
>  struct domain {
>   int domid;
> - int master_fd;
> - int master_pollfd_idx;
> - int slave_fd;
> - int log_fd;
> + int master_fd[MAX_CONSOLE];
> + int master_pollfd_idx[MAX_CONSOLE];
> + int slave_fd[MAX_CONSOLE];
> + int log_fd[MAX_CONSOLE];
>   bool is_dead;
>   unsigned last_seen;
> - struct buffer buffer;
> + struct buffer buffer[MAX_CONSOLE];
>   struct domain *next;
>   char *conspath;
> - int ring_ref;
> - xenevtchn_port_or_error_t local_port;
> - xenevtchn_port_or_error_t remote_port;
> + int ring_ref[MAX_CONSOLE];
> + xenevtchn_port_or_error_t local_port[MAX_CONSOLE];
> + xenevtchn_port_or_error_t remote_port[MAX_CONSOLE];
>   xenevtchn_handle *xce_handle;
>   int xce_pollfd_idx;
> - struct xencons_interface *interface;
> + struct xencons_interface *interface[MAX_CONSOLE];
>   int event_count;
>   long long next_period;
> + int console_data_pending;
> + bool vcon_enabled;

I think you need to gather together all the info of one console into a
single struct, maybe called struct console. Then you'll have an array of
MAX_CONSOLE struct consoles for each domain. Something like:

struct console {
int master_fd;
int master_pollfd_idx;
int slave_fd;
int log_fd;
struct buffer buffer;
int ring_ref;
xenevtchn_port_or_error_t local_port;
xenevtchn_port_or_error_t remote_port;
struct xencons_interface *interface;
}

At that point, you'll be able to generalize all functions in this file,
like buffer_append and handle_ring_read, to take a struct console* as
argument instead of a struct domain*, and they will work seamlessly on
the old pv console and the new vuart console.

The for loop in handle_io can figure out which struct console* to pass
as parameter.

The resulting patch will be much nicer.



>  };
>  
>  static struct domain *dom_head;
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH 06/10] xen/arm: vpl011: Add new parameters to xenstore for the virtual console

[Stefano Stabellini]

On Mon, 3 Apr 2017, Bhupinder Thakur wrote:
> Add two new parameters to the xen store:
> - newly allocated PFN to be used as IN/OUT ring buffer by xenconsoled
> - a new event channel read from Xen using a hvm call to be used by 
> xenconsoled
> 
> Signed-off-by: Bhupinder Thakur 

please use vuart instead of vcon


> ---
>  tools/libxl/libxl.c | 10 ++
>  tools/libxl/libxl_dom.c | 13 -
>  2 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index d400fa2..5fa1e41 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -1791,6 +1791,9 @@ int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, 
> int cons_num,
>  case LIBXL_CONSOLE_TYPE_SERIAL:
>  cons_type_s = "serial";
>  break;
> +case LIBXL_CONSOLE_TYPE_VCON:
> +cons_type_s = "vcon";
> +break;
>  default:
>  goto out;
>  }
> @@ -3159,6 +3162,13 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t 
> domid,
>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
> state->console_port));
>  flexarray_append(ro_front, "ring-ref");
>  flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
> +if (state->vconsole_enabled)
> +{
> +flexarray_append(ro_front, "vcon-port");
> +flexarray_append(ro_front, GCSPRINTF("%"PRIu32, 
> state->vconsole_port));
> +flexarray_append(ro_front, "vcon-ring-ref");
> +flexarray_append(ro_front, GCSPRINTF("%lu", 
> state->vconsole_mfn));

it makes more sense to add a new sub-directory such as:

  ro_front/vuart/port
  ro_front/vuart/ring-ref

Even better, with the idea of supporting more than one in the future:

  ro_front/vuart/0/port
  ro_front/vuart/0/ring-ref


> +}
>  } else {
>  flexarray_append(front, "state");
>  flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
> diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> index d519c8d..8df1e10 100644
> --- a/tools/libxl/libxl_dom.c
> +++ b/tools/libxl/libxl_dom.c
> @@ -302,7 +302,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>  libxl_ctx *ctx = libxl__gc_owner(gc);
>  char *xs_domid, *con_domid;
>  int rc;
> -uint64_t size;
> +uint64_t size, val;
>  
>  if (xc_domain_max_vcpus(ctx->xch, domid, info->max_vcpus) != 0) {
>  LOG(ERROR, "Couldn't set max vcpu count");
> @@ -432,6 +432,16 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
>  state->store_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
> state->store_domid);
>  state->console_port = xc_evtchn_alloc_unbound(ctx->xch, domid, 
> state->console_domid);
>  
> +state->vconsole_port = -1;
> +
> +if (state->vconsole_enabled)
> +{
> +rc = xc_hvm_param_get(ctx->xch, domid, HVM_PARAM_VCONSOLE_EVTCHN,
> +  );
> +if ( !rc )
> +state->vconsole_port = val;
> +}
> +
>  if (info->type == LIBXL_DOMAIN_TYPE_HVM) {
>  hvm_set_conf_params(ctx->xch, domid, info);
>  #if defined(__i386__) || defined(__x86_64__)
> @@ -771,6 +781,7 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
>  if (xc_dom_feature_translated(dom)) {
>  state->console_mfn = dom->console_pfn;
>  state->store_mfn = dom->xenstore_pfn;
> +state->vconsole_mfn = dom->vconsole_pfn;
>  } else {
>  state->console_mfn = xc_dom_p2m(dom, dom->console_pfn);
>  state->store_mfn = xc_dom_p2m(dom, dom->xenstore_pfn);
> -- 
> 2.7.4
> 

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

[Xen-devel] [PATCH v5] ns16550: Add support for UART parameters to be specifed with name-value pairs

[Swapnil Paratey]

Add name=value parsing options for com1 and com2 to add flexibility
in setting register values for MMIO UART devices.

Maintain backward compatibility with previous positional parameter
specfications.

eg. com1=115200,8n1,0x3f8,4
eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2
eg. com1=baud=115200,parity=n,reg_width=4,reg_shift=2,irq=4

Signed-off-by: Swapnil Paratey i

---
Changed since v4:
 * Changes from [PATCH v4] code review

Changed since v3:
 * Changed subject/title of the patch
   Previous name: ns16550-Add-command-line-parsing-adjustments
 * Increased length of opt_com1 and opt_com2 buffers to 128 bytes.
 * Implementation changes from [PATCH v3] code review

Changed since v2:
 * Added name=value specification for com1 and com2 command line
   parameter input for UART devices
   Syntax: "com1=(positional parameters),(name-value parameters)"
 * Maintained previous positional specification for UART parameters
 * All parameters should be comma-separated

Changed since v1:
 * Changed opt_com1 and opt_com2 array size to 64 (power of 2).
 * Added descriptions for reg_width and reg_shift in
   docs/misc/xen-command-line.markdown
 * Changed subject to ns16550 from 16550 for better tracking.
---
 docs/misc/xen-command-line.markdown |  38 ++
 xen/common/kernel.c |   2 +-
 xen/drivers/char/ns16550.c  | 248 +---
 3 files changed, 271 insertions(+), 17 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 450b222..53052b2 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -324,6 +324,44 @@ Both option `com1` and `com2` follow the same format.
 
 A typical setup for most situations might be `com1=115200,8n1`
 
+In addition to the above positional specification for UART parameters,
+name=value pair specfications are also supported. This is used to add
+flexibility for UART devices which require additional UART parameter
+configurations.
+
+The comma separation still delineates positional parameters. Hence,
+unless the parameter is explicitly specified with name=value option, it
+will be considered a positional parameter.
+
+The syntax consists of
+com1=(comma-separated positional parameters),(comma separated name-value pairs)
+
+The accepted name keywords for name=value pairs are
+ * `baud` - accepts integer baud rate (eg. 115200) or `auto`
+ * `bridge`- Similar to bridge-bdf in positional parameters.
+ Used to determine the PCI bridge to access the UART device.
+ Notation is xx:xx.xx :.
+ * `clock-hz`- accepts large integers to setup UART clock frequencies.
+   Do note - these values are multiplied by 16.
+ * `data-bits` - integer between 5 and 8
+ * `dev` - accepted values are `pci` OR `amt`. If this option
+   is used to specify if the serial device is pci-based. The io_base
+   cannot be specified when `dev=pci` or `dev=amt` is used.
+ * `io-base` - accepts integer which specified IO base port for UART registers
+ * `irq` - IRQ number to use
+ * `parity` - accepted values are same as positional parameters
+ * `port` - Used to specify which port the PCI serial device is located on
+Notation is xx:xx.xx :.
+ * `reg-shift` - register shifts required to set UART registers
+ * `reg-width` - register width required to set UART registers
+ (only accepts 1 and 4)
+ * `stop-bits` - only accepts 1 or 2 for the number of stop bits
+
+The following are examples of correct specifications:
+`com1=115200,8n1,0x3f8,4`
+`com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2`
+`com1=baud=115200,parity=n,stop_bits=1,io_base=0x3f8,reg_width=4`
+
 ### conring\_size
 > `= `
 
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 8461871..e1ebb0b 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -49,7 +49,7 @@ static void __init assign_integer_param(
 
 static void __init _cmdline_parse(const char *cmdline)
 {
-char opt[100], *optval, *optkey, *q;
+char opt[128], *optval, *optkey, *q;
 const char *p = cmdline;
 const struct kernel_param *param;
 int bool_assert;
diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index e4de3b4..89e0e4d 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -38,11 +38,28 @@
  * can be specified in place of a numeric baud rate. Polled mode is specified
  * by requesting irq 0.
  */
-static char __initdata opt_com1[30] = "";
-static char __initdata opt_com2[30] = "";
+static char __initdata opt_com1[128] = "";
+static char __initdata opt_com2[128] = "";
 string_param("com1", opt_com1);
 string_param("com2", opt_com2);
 
+enum serial_param_type {
+baud,
+bridge_bdf,
+clock_hz,
+data_bits,
+device,
+io_base,
+irq,
+parity,
+port_bdf,
+reg_shift,
+reg_width,
+stop_bits,
+/* List all parameters before this line. */
+

Re: [Xen-devel] [PATCH 09/10] xen/arm: vpl011: Add new virtual console to xenconsole client

[Stefano Stabellini]

On Mon, 3 Apr 2017, Bhupinder Thakur wrote:
> Add a new console type VCON to connect to the virtual console.

VUART is a better name here too. Please add a doc under docs/misc to
document the new xenstore paths.


> Signed-off-by: Bhupinder Thakur 
> ---
>  tools/console/client/main.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/console/client/main.c b/tools/console/client/main.c
> index 99f..03b6fb1 100644
> --- a/tools/console/client/main.c
> +++ b/tools/console/client/main.c
> @@ -264,6 +264,7 @@ typedef enum {
> CONSOLE_INVAL,
> CONSOLE_PV,
> CONSOLE_SERIAL,
> +   CONSOLE_VCON,
>  } console_type;
>  
>  static struct termios stdin_old_attr;
> @@ -361,6 +362,8 @@ int main(int argc, char **argv)
>   type = CONSOLE_SERIAL;
>   else if (!strcmp(optarg, "pv"))
>   type = CONSOLE_PV;
> + else if (!strcmp(optarg, "vcon"))
> + type = CONSOLE_VCON;
>   else {
>   fprintf(stderr, "Invalid type argument\n");
>   fprintf(stderr, "Console types supported are: 
> serial, pv\n");
> @@ -436,6 +439,9 @@ int main(int argc, char **argv)
>   else
>   snprintf(path, strlen(dom_path) + 
> strlen("/device/console/%d/tty") + 5, "%s/device/console/%d/tty", dom_path, 
> num);
>   }
> + if (type == CONSOLE_VCON) {
> + snprintf(path, strlen(dom_path) + strlen("/console/vtty") + 1, 
> "%s/console/vtty", dom_path);
> + }
>  
>   /* FIXME consoled currently does not assume domain-0 doesn't have a
>  console which is good when we break domain-0 up.  To keep us
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH 10/10] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree

[Stefano Stabellini]

On Mon, 3 Apr 2017, Bhupinder Thakur wrote:
> The SBSA uart node format is as specified in
> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:
> 
> ARM SBSA defined generic UART
> --
> This UART uses a subset of the PL011 registers and consequently lives
> in the PL011 driver. It's baudrate and other communication parameters
> cannot be adjusted at runtime, so it lacks a clock specifier here.
> 
> Required properties:
> - compatible: must be "arm,sbsa-uart"
> - reg: exactly one register range
> - interrupts: exactly one interrupt specifier
> - current-speed: the (fixed) baud rate set by the firmware
> 
> Signed-off-by: Bhupinder Thakur 
> ---
>  tools/libxl/libxl_arm.c | 48 ++--
>  1 file changed, 46 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index d842d88..b25fff6 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -57,6 +57,13 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>  nr_spis = spi + 1;
>  }
>  
> +/*
> + * If pl011 is enabled then increment the nr_spis to allow allocation
> + * of a SPI VIRQ for pl011.
> + */
> +if (libxl_defbool_val(d_config->b_info.enable_pl011))
> +nr_spis += 1;
> +
>  LOG(DEBUG, "Configure the domain");
>  
>  xc_config->nr_spis = nr_spis;
> @@ -130,9 +137,10 @@ static struct arch_info {
>  const char *guest_type;
>  const char *timer_compat;
>  const char *cpu_compat;
> +const char *uart_compat;
>  } arch_info[] = {
> -{"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15" },
> -{"xen-3.0-aarch64", "arm,armv8-timer", "arm,armv8" },
> +{"xen-3.0-armv7l",  "arm,armv7-timer", "arm,cortex-a15", "arm,sbsa-uart" 
> },
> +{"xen-3.0-aarch64", "arm,armv8-timer", "arm,armv8", "arm,sbsa-uart" },
>  };
>  
>  /*
> @@ -590,6 +598,39 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
>  return 0;
>  }
>  
> +static int make_vpl011_uart_node(libxl__gc *gc, void *fdt,
> + const struct arch_info *ainfo,
> + struct xc_dom_image *dom)
> +{
> +int res;
> +gic_interrupt intr;
> +
> +res = fdt_begin_node(fdt, "sbsa-pl011");
> +if (res) return res;
> +
> +res = fdt_property_compat(gc, fdt, 1, ainfo->uart_compat);
> +if (res) return res;
> +
> +res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +1,
> +GUEST_PL011_BASE, GUEST_PL011_SIZE);

strange indentation


> +if (res)
> +return res;

you might as well keep doing if (res) return res; everywhere.

Aside from these two minor issues:

Reviewed-by: Stefano Stabellini 


> +set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
> +
> +res = fdt_property_interrupts(gc, fdt, , 1);
> +if (res) return res;
> +
> +/* Use a default baud rate of 115200. */
> +fdt_property_u32(fdt, "current-speed", 115200);
> +
> +res = fdt_end_node(fdt);
> +if (res) return res;
> +
> +return 0;
> +}
> +
>  static const struct arch_info *get_arch_info(libxl__gc *gc,
>   const struct xc_dom_image *dom)
>  {
> @@ -889,6 +930,9 @@ next_resize:
>  FDT( make_timer_node(gc, fdt, ainfo, xc_config->clock_frequency) );
>  FDT( make_hypervisor_node(gc, fdt, vers) );
>  
> +if ( libxl_defbool_val(info->enable_pl011) )
> +FDT( make_vpl011_uart_node(gc, fdt, ainfo, dom) );
> +
>  if (pfdt)
>  FDT( copy_partial_fdt(gc, fdt, pfdt) );
>  
> -- 
> 2.7.4
> 

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

[Xen-devel] [xen-unstable-smoke test] 107544: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f97838bbd980a0104e16c4a12fbf514f9fa805f1
baseline version:
 xen  5d1ad47ff7940d95c322667678a190c8607754b4

Last test of basis   107540  2017-04-19 12:02:20 Z0 days
Testing same since   107544  2017-04-19 17:03:35 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ross Lagerwall 

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


Not pushing.


commit f97838bbd980a0104e16c4a12fbf514f9fa805f1
Author: Ross Lagerwall 
Date:   Tue Apr 18 16:47:24 2017 +0100

x86: Move microcode loading earlier

Move microcode loading earlier for the boot CPU and secondary CPUs so
that it takes place before identify_cpu() is called for each CPU.
Without this, the detected features may be wrong if the new microcode
loading adjusts the feature bits. That could mean that some fixes (e.g.
d6e9f8d4f35d ("x86/vmx: fix vmentry failure with TSX bits in LBR"))
don't work as expected.

Previously during boot, the microcode loader was invoked for each
secondary CPU started and then again for each CPU as part of an
initcall. Simplify the code so that it is invoked exactly once for each
CPU during boot.

Signed-off-by: Ross Lagerwall 
Reviewed-by: Andrew Cooper 
Tested-by: Andrew Cooper 
Release-acked-by: Julien Grall 
(qemu changes not included)

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

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 linuxe6ff2eed0d0865fd3b0391b7e88ecc5e259eed28
baseline version:
 linux53752ea210016b548cfc3898e6a5ea338fcb6c2c

Last test of basis   105632  2017-02-08 09:05:36 Z   70 days
Testing same since   107495  2017-04-18 06:17:10 Z1 days3 attempts


People who touched revisions under test:
  Alan Stern 
  Alexander Popov 
  Alexander Potapenko 
  Alexei Starovoitov 
  Andrew Collins 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Ryabinin 
  Andy Whitcroft 
  Anna Schumaker 
  Anoob Soman 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Arve Hjønnevåg 
  Ashok Raj 
  Benjamin Herrenschmidt 
  Benjamin Poirier 
  Bjørn Mork 
  Boris Brezillon 
  Brian Norris 

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

[Stefano Stabellini]

On Fri, 14 Apr 2017, Bhupinder Thakur wrote:
> Hi Stefano,
> 
> On 12 April 2017 at 03:37, Stefano Stabellini  wrote:
> > On Tue, 11 Apr 2017, Bhupinder Thakur wrote:
> >> Hi,
> >>
> >> Kindly let me know if my understanding is correct.
> >>
> >> Using a domctl API will allow us to keep the vUART configuration
> >> flexible. Currently, we can operate on one ring-buf PFN and an event
> >> channel port only for a single vUART but if we use DOMCTL interface,
> >> then we can effectively get/set multiple event channel ports/multiple
> >> PFNs from/to Xen in a single domctl call.
> >>
> >> I am not clear who will be the caller of this domctl API. Is it
> >> xenconsoled or the toolstack? Currently, xenconsoled reads the
> >> ring-buf PFN and event channel from the xenstore, which is populated
> >> by the toolstack.
> >
> > The caller could be either, but I think it would make sense for it to be
> > xenconsoled to cut the middle-man (xl).
> >
> I see the issue with Xenconsoled getting the PFN using a DOMCTL API.
> 
> PFN is allocated in alloc_magic_pages() which is part of
> libxenguest.so and the DOMCTL API is part of libxenctrl.so. As per my
> understanding, libxenguest.so has dependency on libxenctrl.so but not
> the other way round.So I am not sure how libxenctrl can call into
> libxenguest to get the PFN.
> 
> If the DOMCTL API is called from libxenguest then I can get the PFN easily.

Yes, that is the case. libxenguest would call libxenctrl to issue
domctls. You would simply replace hvm_param reads/writes with a new pair
of domctl, conceptually very similar.

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

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

[Stefano Stabellini]

On Wed, 19 Apr 2017, Bhupinder Thakur wrote:
> Hi Stefano,
> 
> Thanks for your comments.
> 
> On 19 April 2017 at 05:45, Stefano Stabellini  wrote:
> >> +static void vpl011_read_data(struct domain *d, uint8_t *data)
> >> +{
> >> +unsigned long flags;
> >> +struct vpl011_s *vpl011=>arch.vpl011;
> >
> > The code style is:
> >
> > vpl011 = >arch.vpl011
> >
> >
> >> +struct xencons_interface *intf=(struct xencons_interface 
> >> *)vpl011->ring_buf;
> >
> > Same here. Please fix it everywhere.
> >
> I will fix the coding style here.
> 
> >
> >> +/*
> >> + * Initialize the data so that even if there is no data in ring buffer
> >> + * 0 is returned.
> >> + */
> >> +*data = 0;
> >> +
> >> +VPL011_LOCK(d, flags);
> >> +
> >> +/*
> >> + * It is expected that there will be data in the ring buffer when this
> >> + * function is called since the guest is expected to read the data 
> >> register
> >> + * only if the TXFE flag is not set.
> >> + * If the guest still does read event when TXFE bit is set then 0 will
> >> + * be returned.
> >> + */
> >> +if ( !VPL011_IN_RING_EMPTY(intf) )
> >> +{
> >> +*data = intf->in[MASK_XENCONS_IDX(intf->in_cons++, intf->in)];
> >
> > For correctness, it is important to maintain the right ordering and use
> > barriers:
> >
> > in_cons = intf->in_cons;
> > *data = intf->in[MASK_XENCONS_IDX(in_cons, intf->in)];
> > smb_mb();
> > intf->in_cons = in_cons + 1;
> >
> >
> >> +}
> >> +
> >> +if ( VPL011_IN_RING_EMPTY(intf) )
> >> +{
> >> +vpl011->uartfr |= (RXFE);
> >> +vpl011->uartris &= ~(RXI);
> >> +}
> >> +
> >> +vpl011->uartfr &= ~(RXFF);
> >> +
> >> +VPL011_UNLOCK(d, flags);
> >
> > I think we need to notify xenconsoled here, in case the ring was
> > previosuly full? Now that we have read some data, xenconsoled can go
> > back and write more.
> >
> Yes this is a valid point. I will send an event here.
> 
> >
> >> +}
> >> +
> >> +static void vpl011_write_data(struct domain *d, uint8_t data)
> >> +{
> >> +unsigned long flags;
> >> +struct vpl011_s *vpl011=>arch.vpl011;
> >> +struct xencons_interface *intf=(struct xencons_interface 
> >> *)vpl011->ring_buf;
> >> +
> >> +VPL011_LOCK(d, flags);
> >> +
> >> +/*
> >> + * It is expected that the ring is not full when this function is 
> >> called
> >> + * as the guest is expected to write to the data register only when 
> >> the
> >> + * TXFF flag is not set.
> >> + * In case the guest does write even when the TXFF flag is set then 
> >> the
> >> + * data will be silently dropped.
> >> + */
> >> +if ( !VPL011_OUT_RING_FULL(intf) )
> >> +{
> >> +intf->out[MASK_XENCONS_IDX(intf->out_prod++, intf->out)] = data;
> >> +smp_wmb();
> >
> > Similarly, the order should be:
> >
> > out_prod = intf->out_prod;
> > intf->out[MASK_XENCONS_IDX(out_prod, intf->out)] = data;
> > smb_wmb();
> > intf->out_prod = out_prod + 1;
> >
> I will use the suggested order.
> >
> >> +}
> >> +
> >> +if ( VPL011_OUT_RING_FULL(intf) )
> >> +{
> >> +vpl011->uartfr |= (TXFF);
> >> +vpl011->uartris &= ~(TXI);
> >> +}
> >> +
> >> +vpl011->uartfr |= (BUSY);
> >> +
> >> +vpl011->uartfr &= ~(TXFE);
> >> +
> >> +VPL011_UNLOCK(d, flags);
> >> +
> >> +/* raise an event to xenconsoled only if it is the first character in 
> >> the buffer */
> >> +if ( VPL011_RING_DEPTH(intf, out) == 1 )
> >> +{
> >> +notify_via_xen_event_channel(d, 
> >> d->arch.hvm_domain.params[HVM_PARAM_VCONSOLE_EVTCHN]);
> >> +}
> >
> > Why only in case is the first character? xenconsoled will miss updates
> > if we don't send a notification, right?
> >
> Whenever xenconsoled sends an event, the vpl011_data_avail function
> will make sure that if there is data in the OUT ring buffer then it
> again
> sends an event to xenconsoled. Also it avoids the need of sending an
> event for every character written in the OUT ring buffer.

We don't have a formal protocol spec for PV console, but if we had, it
would say that the frontend (Xen in this case) should send notifications
every time there is new data to write. Thus, once per character in this
case.

I would start with a dumb implementation like that, simply notify the
other end every time. Then, in a separate patch, we can consider
introducing optimizations, which need to be well explained.


Regarding the optimization you introduced in this patch, delaying write
notifications until we receive a notification from xenconsoled, how many
notifications from xen to xenconsoled does it actually save? xenconsoled
is going to send a notification for every read: we might end up sending
the same number of notifications, only delayed.


> >> +}
> >> +
> >> +static int vpl011_mmio_read(struct vcpu *v, mmio_info_t *info, register_t 
> >> *r, void *priv)
> 

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

[Stefano Stabellini]

On Wed, 19 Apr 2017, Juergen Gross wrote:
> On 19/04/17 19:25, Stefano Stabellini wrote:
> > Hello Russell,
> > 
> > Can I have your acked-by on the following fix (original patch is
> > 1492117462-19886-1-git-send-email-sstabell...@kernel.org)?
> 
> Stefano, through which tree should this go? ARM or Xen or other?

I think it could go via the Xen tree, but we still need an ack from the
ARM maintainer for changes to code under arch/arm.

 
> Juergen
> 
> > 
> > Thanks,
> > 
> > Stefano
> > 
> > 
> > On Tue, 18 Apr 2017, Catalin Marinas wrote:
> >> On Thu, Apr 13, 2017 at 02:04:21PM -0700, Stefano Stabellini wrote:
> >>> The following commit:
> >>>
> >>>   commit 815dd18788fe0d41899f51b91d0560279cf16b0d
> >>>   Author: Bart Van Assche 
> >>>   Date:   Fri Jan 20 13:04:04 2017 -0800
> >>>
> >>>   treewide: Consolidate get_dma_ops() implementations
> >>>
> >>> rearranges get_dma_ops in a way that xen_dma_ops are not returned when
> >>> running on Xen anymore, dev->dma_ops is returned instead (see
> >>> arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
> >>> include/linux/dma-mapping.h:get_dma_ops).
> >>>
> >>> Fix the problem by storing dev->dma_ops in dev_archdata, and setting
> >>> dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
> >>> by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
> >>> dev_archdata when needed. It also allows us to remove __generic_dma_ops
> >>> from common headers.
> >>>
> >>> Signed-off-by: Stefano Stabellini 
> >>> Tested-by: Julien Grall 
> >>> Suggested-by: Catalin Marinas 
> >>> CC: li...@armlinux.org.uk
> >>> CC: catalin.mari...@arm.com
> >>> CC: will.dea...@arm.com
> >>> CC: boris.ostrov...@oracle.com
> >>> CC: jgr...@suse.com
> >>> CC: Julien Grall 
> >>
> >> Reviewed-by: Catalin Marinas 
> >>
> >>
> >>> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> >>> index 220ba20..36ec9c8 100644
> >>> --- a/arch/arm/include/asm/device.h
> >>> +++ b/arch/arm/include/asm/device.h
> >>> @@ -16,6 +16,9 @@ struct dev_archdata {
> >>>  #ifdef CONFIG_ARM_DMA_USE_IOMMU
> >>>   struct dma_iommu_mapping*mapping;
> >>>  #endif
> >>> +#ifdef CONFIG_XEN
> >>> + const struct dma_map_ops *dev_dma_ops;
> >>> +#endif
> >>>   bool dma_coherent;
> >>>  };
> >>>  
> >>> diff --git a/arch/arm/include/asm/dma-mapping.h 
> >>> b/arch/arm/include/asm/dma-mapping.h
> >>> index 7166569..680d3f3 100644
> >>> --- a/arch/arm/include/asm/dma-mapping.h
> >>> +++ b/arch/arm/include/asm/dma-mapping.h
> >>> @@ -16,19 +16,9 @@
> >>>  extern const struct dma_map_ops arm_dma_ops;
> >>>  extern const struct dma_map_ops arm_coherent_dma_ops;
> >>>  
> >>> -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
> >>> *dev)
> >>> -{
> >>> - if (dev && dev->dma_ops)
> >>> - return dev->dma_ops;
> >>> - return _dma_ops;
> >>> -}
> >>> -
> >>>  static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
> >>> *bus)
> >>>  {
> >>> - if (xen_initial_domain())
> >>> - return xen_dma_ops;
> >>> - else
> >>> - return __generic_dma_ops(NULL);
> >>> + return _dma_ops;
> >>>  }
> >>>  
> >>>  #define HAVE_ARCH_DMA_SUPPORTED 1
> >>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> >>> index 63eabb0..a614459 100644
> >>> --- a/arch/arm/mm/dma-mapping.c
> >>> +++ b/arch/arm/mm/dma-mapping.c
> >>> @@ -2396,6 +2396,13 @@ void arch_setup_dma_ops(struct device *dev, u64 
> >>> dma_base, u64 size,
> >>>   dma_ops = arm_get_dma_map_ops(coherent);
> >>>  
> >>>   set_dma_ops(dev, dma_ops);
> >>> +
> >>> +#ifdef CONFIG_XEN
> >>> + if (xen_initial_domain()) {
> >>> + dev->archdata.dev_dma_ops = dev->dma_ops;
> >>> + dev->dma_ops = xen_dma_ops;
> >>> + }
> >>> +#endif
> >>>  }
> >>>  
> >>>  void arch_teardown_dma_ops(struct device *dev)
> >>> diff --git a/arch/arm64/include/asm/device.h 
> >>> b/arch/arm64/include/asm/device.h
> >>> index 73d5bab..5a5fa47 100644
> >>> --- a/arch/arm64/include/asm/device.h
> >>> +++ b/arch/arm64/include/asm/device.h
> >>> @@ -20,6 +20,9 @@ struct dev_archdata {
> >>>  #ifdef CONFIG_IOMMU_API
> >>>   void *iommu;/* private IOMMU data */
> >>>  #endif
> >>> +#ifdef CONFIG_XEN
> >>> + const struct dma_map_ops *dev_dma_ops;
> >>> +#endif
> >>>   bool dma_coherent;
> >>>  };
> >>>  
> >>> diff --git a/arch/arm64/include/asm/dma-mapping.h 
> >>> b/arch/arm64/include/asm/dma-mapping.h
> >>> index 505756c..5392dbe 100644
> >>> --- a/arch/arm64/include/asm/dma-mapping.h
> >>> +++ b/arch/arm64/include/asm/dma-mapping.h
> >>> @@ -27,11 +27,8 @@
> >>>  #define DMA_ERROR_CODE   (~(dma_addr_t)0)
> >>>  extern const struct dma_map_ops dummy_dma_ops;
> >>>  
> >>> -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
> >>> *dev)
> >>> +static inline const struct 

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

[Julien Grall]

Hi Oleksandr,

Please CC the appropriate maintainers for all the components you modify.

On 15/03/17 20:05, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

This flag is intended to let Xen know that the guest has devices
which will most likely be used for passthrough.
The primary aim of this knowledge is to help the IOMMUs that don't
share page tables with the CPU be ready before P2M code starts
updating IOMMU mapping.
So, if this flag is set the unshared IOMMUs will populate their
page tables at the domain creation time and thereby will be able
to handle IOMMU mapping updates from *the very beginning*.

Signed-off-by: Oleksandr Tyshchenko 
---
 tools/libxl/libxl_create.c  | 5 +
 xen/arch/arm/domain.c   | 4 +++-
 xen/arch/x86/domain.c   | 4 +++-
 xen/common/domctl.c | 5 -
 xen/include/public/domctl.h | 3 +++
 xen/include/xen/sched.h | 3 +++
 6 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index e741b9a..4393fa2 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -546,6 +546,11 @@ int libxl__domain_make(libxl__gc *gc, libxl_domain_config 
*d_config,
 flags |= XEN_DOMCTL_CDF_hap;
 }

+/* TODO Are these assumptions enough to make decision about using IOMMU? */
+if ((d_config->num_dtdevs && d_config->dtdevs) ||
+(d_config->num_pcidevs && d_config->pcidevs))
+flags |= XEN_DOMCTL_CDF_use_iommu;


Regardless Jan's comment about the flag, I believe we still want to keep 
the current behavior for x86 (e.g allocating the page table on-demand).


So I think this should be per architecture decision rather than a common 
change. Maybe in, libxl__arch_domain_prepare_config. This also means we 
would switch to xen_arch_domainconfig.



+
 /* Ultimately, handle is an array of 16 uint8_t, same as uuid */
 libxl_uuid_copy(ctx, (libxl_uuid *)handle, >uuid);

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index bab62ee..940bb98 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -539,6 +539,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
struct xen_arch_domainconfig *config)
 {
 int rc, count = 0;
+bool_t use_iommu;


s/bool_t/bool/



 BUILD_BUG_ON(GUEST_MAX_VCPUS < MAX_VIRT_CPUS);
 d->arch.relmem = RELMEM_not_started;
@@ -550,7 +551,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 ASSERT(config != NULL);

 /* p2m_init relies on some value initialized by the IOMMU subsystem */
-if ( (rc = iommu_domain_init(d, false)) != 0 )
+use_iommu = !!(domcr_flags & DOMCRF_use_iommu);
+if ( (rc = iommu_domain_init(d, use_iommu)) != 0 )
 goto fail;

 if ( (rc = p2m_init(d)) != 0 )
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 8ef4160..7d634ff 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -525,6 +525,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 {
 bool paging_initialised = false;
 int rc = -ENOMEM;
+bool_t use_iommu;


Ditto.



 if ( config == NULL && !is_idle_domain(d) )
 return -EINVAL;
@@ -646,7 +647,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (rc = init_domain_irq_mapping(d)) != 0 )
 goto fail;

-if ( (rc = iommu_domain_init(d, false)) != 0 )
+use_iommu = !!(domcr_flags & DOMCRF_use_iommu);
+if ( (rc = iommu_domain_init(d, use_iommu)) != 0 )
 goto fail;
 }
 spin_lock_init(>arch.e820_lock);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 93e3029..56c4d38 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -505,7 +505,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
| XEN_DOMCTL_CDF_hap
| XEN_DOMCTL_CDF_s3_integrity
| XEN_DOMCTL_CDF_oos_off
-   | XEN_DOMCTL_CDF_xs_domain)) )
+   | XEN_DOMCTL_CDF_xs_domain
+   | XEN_DOMCTL_CDF_use_iommu)) )
 break;

 dom = op->domain;
@@ -549,6 +550,8 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 domcr_flags |= DOMCRF_oos_off;
 if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_xs_domain )
 domcr_flags |= DOMCRF_xs_domain;
+if ( op->u.createdomain.flags & XEN_DOMCTL_CDF_use_iommu )
+domcr_flags |= DOMCRF_use_iommu;

 d = domain_create(dom, domcr_flags, op->u.createdomain.ssidref,
   >u.createdomain.config);
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 85cbb7c..a37a566 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -66,6 +66,9 @@ struct xen_domctl_createdomain {
  /* Is this a xenstore domain? */
 #define _XEN_DOMCTL_CDF_xs_domain  

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

[Juergen Gross]

On 19/04/17 19:25, Stefano Stabellini wrote:
> Hello Russell,
> 
> Can I have your acked-by on the following fix (original patch is
> 1492117462-19886-1-git-send-email-sstabell...@kernel.org)?

Stefano, through which tree should this go? ARM or Xen or other?


Juergen

> 
> Thanks,
> 
> Stefano
> 
> 
> On Tue, 18 Apr 2017, Catalin Marinas wrote:
>> On Thu, Apr 13, 2017 at 02:04:21PM -0700, Stefano Stabellini wrote:
>>> The following commit:
>>>
>>>   commit 815dd18788fe0d41899f51b91d0560279cf16b0d
>>>   Author: Bart Van Assche 
>>>   Date:   Fri Jan 20 13:04:04 2017 -0800
>>>
>>>   treewide: Consolidate get_dma_ops() implementations
>>>
>>> rearranges get_dma_ops in a way that xen_dma_ops are not returned when
>>> running on Xen anymore, dev->dma_ops is returned instead (see
>>> arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
>>> include/linux/dma-mapping.h:get_dma_ops).
>>>
>>> Fix the problem by storing dev->dma_ops in dev_archdata, and setting
>>> dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
>>> by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
>>> dev_archdata when needed. It also allows us to remove __generic_dma_ops
>>> from common headers.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>> Tested-by: Julien Grall 
>>> Suggested-by: Catalin Marinas 
>>> CC: li...@armlinux.org.uk
>>> CC: catalin.mari...@arm.com
>>> CC: will.dea...@arm.com
>>> CC: boris.ostrov...@oracle.com
>>> CC: jgr...@suse.com
>>> CC: Julien Grall 
>>
>> Reviewed-by: Catalin Marinas 
>>
>>
>>> diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
>>> index 220ba20..36ec9c8 100644
>>> --- a/arch/arm/include/asm/device.h
>>> +++ b/arch/arm/include/asm/device.h
>>> @@ -16,6 +16,9 @@ struct dev_archdata {
>>>  #ifdef CONFIG_ARM_DMA_USE_IOMMU
>>> struct dma_iommu_mapping*mapping;
>>>  #endif
>>> +#ifdef CONFIG_XEN
>>> +   const struct dma_map_ops *dev_dma_ops;
>>> +#endif
>>> bool dma_coherent;
>>>  };
>>>  
>>> diff --git a/arch/arm/include/asm/dma-mapping.h 
>>> b/arch/arm/include/asm/dma-mapping.h
>>> index 7166569..680d3f3 100644
>>> --- a/arch/arm/include/asm/dma-mapping.h
>>> +++ b/arch/arm/include/asm/dma-mapping.h
>>> @@ -16,19 +16,9 @@
>>>  extern const struct dma_map_ops arm_dma_ops;
>>>  extern const struct dma_map_ops arm_coherent_dma_ops;
>>>  
>>> -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
>>> *dev)
>>> -{
>>> -   if (dev && dev->dma_ops)
>>> -   return dev->dma_ops;
>>> -   return _dma_ops;
>>> -}
>>> -
>>>  static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>>> *bus)
>>>  {
>>> -   if (xen_initial_domain())
>>> -   return xen_dma_ops;
>>> -   else
>>> -   return __generic_dma_ops(NULL);
>>> +   return _dma_ops;
>>>  }
>>>  
>>>  #define HAVE_ARCH_DMA_SUPPORTED 1
>>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>>> index 63eabb0..a614459 100644
>>> --- a/arch/arm/mm/dma-mapping.c
>>> +++ b/arch/arm/mm/dma-mapping.c
>>> @@ -2396,6 +2396,13 @@ void arch_setup_dma_ops(struct device *dev, u64 
>>> dma_base, u64 size,
>>> dma_ops = arm_get_dma_map_ops(coherent);
>>>  
>>> set_dma_ops(dev, dma_ops);
>>> +
>>> +#ifdef CONFIG_XEN
>>> +   if (xen_initial_domain()) {
>>> +   dev->archdata.dev_dma_ops = dev->dma_ops;
>>> +   dev->dma_ops = xen_dma_ops;
>>> +   }
>>> +#endif
>>>  }
>>>  
>>>  void arch_teardown_dma_ops(struct device *dev)
>>> diff --git a/arch/arm64/include/asm/device.h 
>>> b/arch/arm64/include/asm/device.h
>>> index 73d5bab..5a5fa47 100644
>>> --- a/arch/arm64/include/asm/device.h
>>> +++ b/arch/arm64/include/asm/device.h
>>> @@ -20,6 +20,9 @@ struct dev_archdata {
>>>  #ifdef CONFIG_IOMMU_API
>>> void *iommu;/* private IOMMU data */
>>>  #endif
>>> +#ifdef CONFIG_XEN
>>> +   const struct dma_map_ops *dev_dma_ops;
>>> +#endif
>>> bool dma_coherent;
>>>  };
>>>  
>>> diff --git a/arch/arm64/include/asm/dma-mapping.h 
>>> b/arch/arm64/include/asm/dma-mapping.h
>>> index 505756c..5392dbe 100644
>>> --- a/arch/arm64/include/asm/dma-mapping.h
>>> +++ b/arch/arm64/include/asm/dma-mapping.h
>>> @@ -27,11 +27,8 @@
>>>  #define DMA_ERROR_CODE (~(dma_addr_t)0)
>>>  extern const struct dma_map_ops dummy_dma_ops;
>>>  
>>> -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
>>> *dev)
>>> +static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
>>> *bus)
>>>  {
>>> -   if (dev && dev->dma_ops)
>>> -   return dev->dma_ops;
>>> -
>>> /*
>>>  * We expect no ISA devices, and all other DMA masters are expected to
>>>  * have someone call arch_setup_dma_ops at device creation time.
>>> @@ -39,14 +36,6 @@ static inline const struct dma_map_ops 
>>> *__generic_dma_ops(struct 

Re: [Xen-devel] [RFC PATCH 8/9] iommu: Split iommu_hwdom_init() into arch specific parts

[Julien Grall]

Hi,

Sorry for the late answer.

On 23/03/17 12:40, Oleksandr Tyshchenko wrote:

On Thu, Mar 23, 2017 at 11:08 AM, Jan Beulich  wrote:

On 22.03.17 at 19:40,  wrote:

On Wed, Mar 22, 2017 at 5:54 PM, Jan Beulich  wrote:

On 15.03.17 at 21:05,  wrote:

The code being moved from here has survived the previous separation
of arch-independent from arch-specific code, and looking at the code
I also can't immediately see what's x86-specific here, so please make
the description explain why the code as is can't be used.


You are right, there is nothing x86-specific here at first sight.
The reason why I moved this code to x86 folder is that we don't need
to retrieve IOMMU mappings on ARM this way. With need_iommu being
explicitly set at the hardware domain creation time
we just need to ask unshared IOMMU driver to allocate its page table
to be ready to receive and process IOMMU mappings from P2M code.

Other points that had prevented me from using it as is.
If the hardware domain isn't 1:1 mapped we won't know gfn. IIRC, we
can find mfn by gfn for particular domain on ARM, but not vise versa.
Also this iommu_hwdom_init() is being called before allocating domain
memory on ARM. What is the point?
So, the d->page_list is empty during it execution.


In which case the question even more so is - why move the code
if it simply does nothing in your case?


I didn't move the code, because back then we were only planning to 
support shared page table (iommu_use_hap_pt(...) always returns true on 
ARM so far).


With more perspective, this code cannot work on ARM because of 
mfn_to_gmfn (we don't have an M2P). If we keep the code like that after 
this series, this will at least expose a bug (the helper always assume a 
direct mapping).


So I think moving the code is the right solution.



Reasonable question. Before answering you I would like to clarify the reason
why the iommu_hwdom_init() is being called before allocating domain
memory on ARM.
Is it a bug or there is an explanation for doing this.


No real reason, I didn't see a reason to call this function later on. I 
would be interested to know whether there is a latent bug.


Anyway, I think this is a good idea to fully initialize the IOMMU early 
for DOM0 as the builder will take care of assigning the non-PCI device 
protected.


Cheers,

--
Julien Grall

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

[Xen-devel] [libvirt test] 107536: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107442
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107442
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107442

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  bd13b26da25bd33ca3d8885448df76e5b3eecf6a
baseline version:
 libvirt  8e09663f7ff70b10a560746f17897d2c67c8460d

Last test of basis   107442  2017-04-14 04:27:41 Z5 days
Failing since107493  2017-04-18 04:21:01 Z1 days2 attempts
Testing same since   107536  2017-04-19 04:21:01 Z0 days1 attempts


People who touched revisions under test:
  Dawid Zamirski 
  Jim Fehlig 
  John Ferlan 
  Konstantin Neumoin 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

Re: [Xen-devel] [RFC PATCH 4/9] xen/arm: p2m: Update IOMMU mapping whenever possible if page table is not shared

[Julien Grall]

Hi Oleksandr,

On 15/03/17 20:05, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Update IOMMU mapping if the IOMMU doesn't share page table with the CPU.
The best place to do so on ARM is p2m_set_entry(). Use mfn as an indicator
of the required action. If mfn is valid call iommu_map_pages(),
otherwise - iommu_unmap_pages().


Can you explain in the commit message why you do this change in 
p2m_set_entry and not __p2m_set_entry?




Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/p2m.c | 40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 1fc6ca3..84d3a09 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -979,7 +979,8 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
 if ( p2m_valid(orig_pte) && entry->p2m.base != orig_pte.p2m.base )
 p2m_free_entry(p2m, orig_pte, level);

-if ( need_iommu(p2m->domain) && (p2m_valid(orig_pte) || p2m_valid(*entry)) 
)
+if ( need_iommu(p2m->domain) && iommu_use_hap_pt(d) &&
+ (p2m_valid(orig_pte) || p2m_valid(*entry)) )
 rc = iommu_iotlb_flush(p2m->domain, gfn_x(sgfn), 1UL << page_order);
 else
 rc = 0;
@@ -997,6 +998,9 @@ int p2m_set_entry(struct p2m_domain *p2m,
   p2m_type_t t,
   p2m_access_t a)
 {
+unsigned long orig_nr = nr;
+gfn_t orig_sgfn = sgfn;
+mfn_t orig_smfn = smfn;
 int rc = 0;

 while ( nr )
@@ -1029,6 +1033,40 @@ int p2m_set_entry(struct p2m_domain *p2m,
 nr -= (1 << order);
 }

+if ( likely(!rc) )


I would do

if ( unlikely(rc) )
  return rc;

/* IOMMU map/unmap ... */

This would remove one indentation layer of if.


+{
+/*
+ * It's time to update IOMMU mapping if the latter doesn't
+ * share page table with the CPU. Pass the whole memory block to let
+ * the IOMMU code decide what to do with it.
+ * The reason to update IOMMU mapping outside "while loop" is that
+ * the IOMMU might not support the pages/superpages the CPU can deal
+ * with (4K, 2M, 1G) and as result this will lead to non-optimal
+ * mapping.


My worry with this solution is someone may decide to use __p2m_set_entry 
(see relinquish) directly because he knows the correct order. So the 
IOMMU would be correctly handled when page table are shared and not when 
they are "unshared".


I would probably extend __p2m_get_entry with a new parameter indication 
whether we want to map the page in the IOMMU directly or not.


Also, do you expect the IOMMU to support a page granularity bigger than 
the one supported by Xen? If not, we should probably have a check 
somewhere, to prevent potential security issue as we would map more than 
expected.



+ * Also we assume that the IOMMU mapping should be updated only
+ * if CPU mapping passed successfully.
+ */
+if ( need_iommu(p2m->domain) && !iommu_use_hap_pt(p2m->domain) )
+{
+if ( !mfn_eq(orig_smfn, INVALID_MFN) )
+{
+unsigned int flags = p2m_get_iommu_flags(t);
+
+rc = iommu_map_pages(p2m->domain,
+ gfn_x(orig_sgfn),
+ mfn_x(orig_smfn),
+ orig_nr,
+ flags);
+}
+else
+{
+rc = iommu_unmap_pages(p2m->domain,
+   gfn_x(orig_sgfn),
+   orig_nr);
+}
+}
+}
+
 return rc;
 }




Cheers,

--
Julien Grall

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

[Xen-devel] [RFC PATCH v4] xen: credit2: provide custom option to create runqueue

[Praveen Kumar]

The patch introduces a new, very flexible way of arranging runqueues in Credit2.
It allows to specify, explicitly and precisely, what pCPUs should belong to
which runqueue.

Signed-off-by: Praveen Kumar 
---
 docs/misc/xen-command-line.markdown |  10 ++-
 xen/common/sched_credit2.c  | 167 +++-
 2 files changed, 174 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 33e54aef63..f2ee4ad972 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -525,7 +525,7 @@ also slow in responding to load changes.
 The default value of `1 sec` is rather long.
 
 ### credit2\_runqueue
-> `= cpu | core | socket | node | all`
+> `= cpu | core | socket | node | all | `
 
 > Default: `socket`
 
@@ -543,6 +543,14 @@ Available alternatives, with their meaning, are:
 * `node`: one runqueue per each NUMA node of the host;
 * `all`: just one runqueue shared by all the logical pCPUs of
  the host
+* ``: one runqueue per mentioned subset. The subset can be defined as
+  as shown in below example:
+  credit2_runqueue=[[0,1,][2,6][3,5][4,7]] , or 0,1\;2,6\;3,5\;4,7
+  which means :
+  - pCPUs 0 and 1 belong to runqueue 0
+  - pCPUs 2 and 6 belong to runqueue 1
+  - pCPUs 3 and 5 belong to runqueue 2
+  - pCPUs 4 and 7 belong to runqueue 3
 
 ### dbgp
 > `= ehci[  | @pci:. ]`
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index b9b928347f..ebec33f450 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -321,6 +321,16 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  *   (logical) processors of the host belong. This will happen if
  *   the opt_runqueue parameter is set to 'all'.
  *
+ * - custom: meaning that there will be one runqueue per subset being passed as
+ *   parameter to credit2_runqueue as shown in below example.
+ *   Example:
+ *   credit2_runqueue=[[cpu0,cpu1][cpu3][cpu4,cpu5]] or
+ *   credit2_runqueue=0,1\;3\;4,5
+ *   The example mentioned states :
+ *   cpu0 and cpu1 belongs to runqueue 0
+ *   cpu3 belongs to runqueue 1
+ *   cpu4 and cpu5 belongs to runqueue 2
+ *
  * Depending on the value of opt_runqueue, therefore, cpus that are part of
  * either the same physical core, the same physical socket, the same NUMA
  * node, or just all of them, will be put together to form runqueues.
@@ -330,15 +340,138 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
 #define OPT_RUNQUEUE_SOCKET 2
 #define OPT_RUNQUEUE_NODE   3
 #define OPT_RUNQUEUE_ALL4
+#define OPT_RUNQUEUE_CUSTOM 5
 static const char *const opt_runqueue_str[] = {
 [OPT_RUNQUEUE_CPU] = "cpu",
 [OPT_RUNQUEUE_CORE] = "core",
 [OPT_RUNQUEUE_SOCKET] = "socket",
 [OPT_RUNQUEUE_NODE] = "node",
-[OPT_RUNQUEUE_ALL] = "all"
+[OPT_RUNQUEUE_ALL] = "all",
+[OPT_RUNQUEUE_CUSTOM] = "custom"
 };
 static int __read_mostly opt_runqueue = OPT_RUNQUEUE_SOCKET;
 
+static unsigned long __read_mostly custom_cpu_runqueue[NR_CPUS];
+
+static inline int getlen(const char *start, const char *end)
+{
+if ( ( start ) && ( end ) && ( end > start ) )
+return end-start;
+else
+return -1;
+}
+
+static int parse_custom_runqueue_option(const char *s)
+{
+const char *parse = NULL, *s_end = NULL;
+const char *start = NULL, *end = NULL;
+char delimiter[2] = {0};
+int cpu_added_to_runqueue = 0;
+int runqueue = 0;
+
+/* Format supported :
+ * [[0,1,4,5][2,3,6,7][8,9,12,13][10,11,14,15]]
+ *  or
+ * 0,1,4,5\;2,3,6,7\;8,9,12,13\;10,11,14,15
+ */
+parse = s;
+s_end = s + strlen(s);
+/* The start and should always be in format of '[..]' */
+if ( ( '[' == *parse ) && ( ']' == *(s_end-1)) )
+{
+delimiter[0] = '[';
+delimiter[1] = '\0';
+parse++;
+}
+else
+{
+delimiter[0] = ';';
+delimiter[1] = '\0';
+}
+
+while ( ( parse != NULL ) && ( parse < s_end ) )
+{
+const char *token_sub_str = NULL;
+
+while ( *parse == '[' )
+parse++;
+
+start = parse;
+end = strstr(parse, delimiter);
+
+/* Check if we don't have the delimiter */
+if ( !end )
+{
+/* If we don't have delimiter, then break, if start is greater than
+ * or equal to s_end, as we have reached the end.
+ */
+if ( start >= s_end )
+break;
+
+/* We need to parse till s_end, as we have the last set */
+end = s_end;
+}
+
+/* Just move to next, as we have empty set like [] or ;; */
+if ( getlen ( start, end ) < 1 )
+ 

[Xen-devel] [linux-4.9 test] 107532: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-stop fail pass in 107502

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxc3582cc56eac9213b32cc2a2886b11e2e5027598
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z8 days
Failing since107396  2017-04-12 11:15:19 Z7 days   14 attempts
Testing same since   107502  2017-04-18 13:18:18 Z1 days2 attempts


People who touched revisions under test:
  Adrian Hunter 
  Alan Stern 
  Alberto Aguirre 
  Alex Deucher 
  Alex Williamson 
  Alex Wood 
  Alexander Polakov 
  Alexander Polyakov 
  Amit Pundir 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Smetanin 
  Andy Gross 
  Andy Shevchenko 
  Arend van Spriel 
  Arnd Bergmann 
  Aurelien Aptel 
  Baoyou Xie 
  Bartosz Golaszewski 
  Bastien Nocera 
 

Re: [Xen-devel] [RFC PATCH 2/9] iommu: Add ability to map/unmap the number of pages

[Julien Grall]

Hi Oleksandr,

On 15/03/17 20:05, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Extend the IOMMU code with new APIs and platform callbacks.
These new map_pages/unmap_pages API do almost the same thing
as existing map_page/unmap_page ones except the formers can
handle the number of pages. So do new platform callbacks.

Currently, this patch requires to modify neither
existing IOMMU drivers nor P2M code.
But, the patch might be rewritten to replace existing
single-page stuff with the multi-page one followed by modifications
of all related parts.

Signed-off-by: Oleksandr Tyshchenko 
---
 xen/drivers/passthrough/iommu.c | 50 -
 xen/include/xen/iommu.h | 16 ++---
 2 files changed, 52 insertions(+), 14 deletions(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index 5e81813..115698f 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -249,22 +249,37 @@ void iommu_domain_destroy(struct domain *d)
 arch_iommu_domain_destroy(d);
 }

-int iommu_map_page(struct domain *d, unsigned long gfn, unsigned long mfn,
-   unsigned int flags)
+int iommu_map_pages(struct domain *d, unsigned long gfn, unsigned long mfn,
+unsigned long page_count, unsigned int flags)


It would be nice if you can use mfn_t and gfn_t instead of unsigned long 
for any new functions. They are typesafe and avoid confusion between gfn 
and mfn.



 {
 const struct domain_iommu *hd = dom_iommu(d);
-int rc;
+int rc = 0;
+unsigned long i;

 if ( !iommu_enabled || !hd->platform_ops )
 return 0;

-rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
+if ( hd->platform_ops->map_pages )
+rc = hd->platform_ops->map_pages(d, gfn, mfn, page_count, flags);
+else
+{
+for ( i = 0; i < page_count; i++ )
+{
+rc = hd->platform_ops->map_page(d, gfn + i, mfn + i, flags);
+if ( unlikely(rc) )
+{
+/* TODO Do we need to unmap if map failed? */
+break;
+}
+}
+}
+
 if ( unlikely(rc) )
 {
 if ( !d->is_shutting_down && printk_ratelimit() )
 printk(XENLOG_ERR
-   "d%d: IOMMU mapping gfn %#lx to mfn %#lx failed: %d\n",
-   d->domain_id, gfn, mfn, rc);
+   "d%d: IOMMU mapping gfn %#lx to mfn %#lx page count %lu failed: 
%d\n",
+   d->domain_id, gfn, mfn, page_count, rc);

 if ( !is_hardware_domain(d) )
 domain_crash(d);
@@ -273,21 +288,34 @@ int iommu_map_page(struct domain *d, unsigned long gfn, 
unsigned long mfn,
 return rc;
 }

-int iommu_unmap_page(struct domain *d, unsigned long gfn)
+int iommu_unmap_pages(struct domain *d, unsigned long gfn,
+  unsigned long page_count)
 {
 const struct domain_iommu *hd = dom_iommu(d);
-int rc;
+int ret, rc = 0;
+unsigned long i;

 if ( !iommu_enabled || !hd->platform_ops )
 return 0;

-rc = hd->platform_ops->unmap_page(d, gfn);
+if ( hd->platform_ops->unmap_pages )
+rc = hd->platform_ops->unmap_pages(d, gfn, page_count);
+else
+{
+for ( i = 0; i < page_count; i++ )
+{
+ret = hd->platform_ops->unmap_page(d, gfn + i);
+if ( likely(!rc) )
+rc = ret;
+}
+}
+
 if ( unlikely(rc) )
 {
 if ( !d->is_shutting_down && printk_ratelimit() )
 printk(XENLOG_ERR
-   "d%d: IOMMU unmapping gfn %#lx failed: %d\n",
-   d->domain_id, gfn, rc);
+   "d%d: IOMMU unmapping gfn %#lx page count %lu failed: %d\n",
+   d->domain_id, gfn, page_count, rc);

 if ( !is_hardware_domain(d) )
 domain_crash(d);
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 5803e3f..0446ed3 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -76,9 +76,14 @@ void iommu_teardown(struct domain *d);
 #define IOMMUF_readable  (1u<<_IOMMUF_readable)
 #define _IOMMUF_writable 1
 #define IOMMUF_writable  (1u<<_IOMMUF_writable)
-int __must_check iommu_map_page(struct domain *d, unsigned long gfn,
-unsigned long mfn, unsigned int flags);
-int __must_check iommu_unmap_page(struct domain *d, unsigned long gfn);
+int __must_check iommu_map_pages(struct domain *d, unsigned long gfn,
+ unsigned long mfn, unsigned long page_count,
+ unsigned int flags);
+int __must_check iommu_unmap_pages(struct domain *d, unsigned long gfn,
+   unsigned long page_count);
+
+#define iommu_map_page(d,gfn,mfn,flags) (iommu_map_pages(d,gfn,mfn,1,flags))
+#define iommu_unmap_page(d,gfn) 

Re: [Xen-devel] [RFC PATCH 3/9] xen/arm: p2m: Add helper to convert p2m type to IOMMU flags

[Julien Grall]

Hi Oleksandr,

On 15/03/17 20:05, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

The helper has the same purpose as existing for x86 one.
It is used for choosing IOMMU mapping attribute according to
the memory type.

Signed-off-by: Oleksandr Tyshchenko 


Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

[Stefano Stabellini]

Hello Russell,

Can I have your acked-by on the following fix (original patch is
1492117462-19886-1-git-send-email-sstabell...@kernel.org)?

Thanks,

Stefano


On Tue, 18 Apr 2017, Catalin Marinas wrote:
> On Thu, Apr 13, 2017 at 02:04:21PM -0700, Stefano Stabellini wrote:
> > The following commit:
> > 
> >   commit 815dd18788fe0d41899f51b91d0560279cf16b0d
> >   Author: Bart Van Assche 
> >   Date:   Fri Jan 20 13:04:04 2017 -0800
> > 
> >   treewide: Consolidate get_dma_ops() implementations
> > 
> > rearranges get_dma_ops in a way that xen_dma_ops are not returned when
> > running on Xen anymore, dev->dma_ops is returned instead (see
> > arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
> > include/linux/dma-mapping.h:get_dma_ops).
> > 
> > Fix the problem by storing dev->dma_ops in dev_archdata, and setting
> > dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
> > by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
> > dev_archdata when needed. It also allows us to remove __generic_dma_ops
> > from common headers.
> > 
> > Signed-off-by: Stefano Stabellini 
> > Tested-by: Julien Grall 
> > Suggested-by: Catalin Marinas 
> > CC: li...@armlinux.org.uk
> > CC: catalin.mari...@arm.com
> > CC: will.dea...@arm.com
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > CC: Julien Grall 
> 
> Reviewed-by: Catalin Marinas 
> 
> 
> > diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
> > index 220ba20..36ec9c8 100644
> > --- a/arch/arm/include/asm/device.h
> > +++ b/arch/arm/include/asm/device.h
> > @@ -16,6 +16,9 @@ struct dev_archdata {
> >  #ifdef CONFIG_ARM_DMA_USE_IOMMU
> > struct dma_iommu_mapping*mapping;
> >  #endif
> > +#ifdef CONFIG_XEN
> > +   const struct dma_map_ops *dev_dma_ops;
> > +#endif
> > bool dma_coherent;
> >  };
> >  
> > diff --git a/arch/arm/include/asm/dma-mapping.h 
> > b/arch/arm/include/asm/dma-mapping.h
> > index 7166569..680d3f3 100644
> > --- a/arch/arm/include/asm/dma-mapping.h
> > +++ b/arch/arm/include/asm/dma-mapping.h
> > @@ -16,19 +16,9 @@
> >  extern const struct dma_map_ops arm_dma_ops;
> >  extern const struct dma_map_ops arm_coherent_dma_ops;
> >  
> > -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
> > *dev)
> > -{
> > -   if (dev && dev->dma_ops)
> > -   return dev->dma_ops;
> > -   return _dma_ops;
> > -}
> > -
> >  static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
> > *bus)
> >  {
> > -   if (xen_initial_domain())
> > -   return xen_dma_ops;
> > -   else
> > -   return __generic_dma_ops(NULL);
> > +   return _dma_ops;
> >  }
> >  
> >  #define HAVE_ARCH_DMA_SUPPORTED 1
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index 63eabb0..a614459 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -2396,6 +2396,13 @@ void arch_setup_dma_ops(struct device *dev, u64 
> > dma_base, u64 size,
> > dma_ops = arm_get_dma_map_ops(coherent);
> >  
> > set_dma_ops(dev, dma_ops);
> > +
> > +#ifdef CONFIG_XEN
> > +   if (xen_initial_domain()) {
> > +   dev->archdata.dev_dma_ops = dev->dma_ops;
> > +   dev->dma_ops = xen_dma_ops;
> > +   }
> > +#endif
> >  }
> >  
> >  void arch_teardown_dma_ops(struct device *dev)
> > diff --git a/arch/arm64/include/asm/device.h 
> > b/arch/arm64/include/asm/device.h
> > index 73d5bab..5a5fa47 100644
> > --- a/arch/arm64/include/asm/device.h
> > +++ b/arch/arm64/include/asm/device.h
> > @@ -20,6 +20,9 @@ struct dev_archdata {
> >  #ifdef CONFIG_IOMMU_API
> > void *iommu;/* private IOMMU data */
> >  #endif
> > +#ifdef CONFIG_XEN
> > +   const struct dma_map_ops *dev_dma_ops;
> > +#endif
> > bool dma_coherent;
> >  };
> >  
> > diff --git a/arch/arm64/include/asm/dma-mapping.h 
> > b/arch/arm64/include/asm/dma-mapping.h
> > index 505756c..5392dbe 100644
> > --- a/arch/arm64/include/asm/dma-mapping.h
> > +++ b/arch/arm64/include/asm/dma-mapping.h
> > @@ -27,11 +27,8 @@
> >  #define DMA_ERROR_CODE (~(dma_addr_t)0)
> >  extern const struct dma_map_ops dummy_dma_ops;
> >  
> > -static inline const struct dma_map_ops *__generic_dma_ops(struct device 
> > *dev)
> > +static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
> > *bus)
> >  {
> > -   if (dev && dev->dma_ops)
> > -   return dev->dma_ops;
> > -
> > /*
> >  * We expect no ISA devices, and all other DMA masters are expected to
> >  * have someone call arch_setup_dma_ops at device creation time.
> > @@ -39,14 +36,6 @@ static inline const struct dma_map_ops 
> > *__generic_dma_ops(struct device *dev)
> > return _dma_ops;
> >  }
> >  
> > -static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type 
> > *bus)
> > 

Re: [Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

[Stefano Stabellini]

On Wed, 19 Apr 2017, Arnd Bergmann wrote:
> All Xen frontends need to select this symbol to avoid a link error:
> 
> net/built-in.o: In function `p9_trans_xen_init':
> :(.text+0x149e9c): undefined reference to `__xenbus_register_frontend'
> 
> Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver")
> Signed-off-by: Arnd Bergmann 

Thank you for the fix!

Reviewed-by: Stefano Stabellini 


> ---
>  net/9p/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/net/9p/Kconfig b/net/9p/Kconfig
> index 3f286f1bd1d3..e6014e0e51f7 100644
> --- a/net/9p/Kconfig
> +++ b/net/9p/Kconfig
> @@ -24,6 +24,7 @@ config NET_9P_VIRTIO
>  
>  config NET_9P_XEN
>   depends on XEN
> + select XEN_XENBUS_FRONTEND
>   tristate "9P Xen Transport"
>   help
> This builds support for a transport for 9pfs between
> -- 
> 2.9.0
> 

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

Re: [Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

[Daniel Kiper]

On Wed, Apr 19, 2017 at 10:19:44AM -0600, Jan Beulich wrote:
> >>> On 19.04.17 at 17:54,  wrote:
> > On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote:
> >> @@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op,
> >>  if ( ret )
> >>  return ret;
> >>
> >> +if ( test_and_set_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) )
> >> +return hypercall_create_continuation(__HYPERVISOR_kexec_op, "lh", 
> >> op, uarg);
> >> +
> >
> > I would suggest here:
> >ASSERT(test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags));
>
> You're kidding? The flag was set just in the line above. Or do you
> really mean we need to consider test_and_set_bit() not doing what
> it is supposed to do?

Yep, it looks ridiculous. However, ASSERT() in kexec_swap_images() looks almost
the same for me. So, TBH, I still do not understand need for it at all. Could
you enlighten me?

If we really need it I would put it at the beginning of every function called
from switch() in do_kexec_op_internal(). Just in case. Though I still do not
see the point for it. At least in that form.

Daniel

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

[Xen-devel] [PATCH for-4.9 4/4] xen/arm: Properly map the FDT in the boot page table

[Julien Grall]

Currently, Xen is assuming the FDT will always fit in a 2MB section.
Recently, I noticed an early crash on Xen when using GRUB with the
following call trace:

(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 00264140 strlen+0x10/0x84
(XEN) LR: 002401c0
(XEN) SP: 002cfc20
(XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 00801230  X1: 00801230  X2: 5230
(XEN)  X3: 0030  X4: 0030  X5: 0038
(XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
(XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
(XEN) X12: 0030 X13: ff00ff00 X14: 08000300
(XEN) X15:  X16: fefff610 X17: 00f0
(XEN) X18: 0004 X19: 0008 X20: 007fc040
(XEN) X21: 007fc000 X22: 000e X23: 
(XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
(XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
(XEN)
(XEN)   VTCR_EL2: 80010c40
(XEN)  VTTBR_EL2: 082800203000
(XEN)
(XEN)  SCTLR_EL2: 30c5183d
(XEN)HCR_EL2: 0038663f
(XEN)  TTBR0_EL2: f4912000
(XEN)
(XEN)ESR_EL2: 9606
(XEN)  HPFAR_EL2: e8071000
(XEN)FAR_EL2: 00801230
(XEN)
(XEN) Xen stack trace from sp=002cfc20:
(XEN)002cfc70 00240254 002a9f58 007fc000
(XEN)   007fc03c
(XEN)002cfd78  002cfca0 002986fc
(XEN) 007fc000  
(XEN)002cfcc0 00298f1c  007fc000
(XEN)002cfdc0 0029904c f47fc000 f4604000
(XEN)f47fc000 007fc000 0040 0100
(XEN)f4604000 0001 0001 8002
(XEN)   
(XEN)   
(XEN)   
(XEN)  002cfdc0 00299038
(XEN)f47fc000 f4604000 f47fc000 
(XEN)002cfe20 0029c420 002d8000 f4604000
(XEN)f47fc000  0040 0100
(XEN)f4604000 0001 f47fc000 0029c404
(XEN)fefff510 00200624 f4804000 f4604000
(XEN)f47fc000  0040 0100
(XEN)0001 0001 0001 8002
(XEN)f47fc000   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) Xen call trace:
(XEN)[<00264140>] strlen+0x10/0x84 (PC)
(XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
(XEN)[<00240254>] fdt_get_property+0x40/0x50
(XEN)[<002986fc>] bootfdt.c#device_tree_get_u32+0x18/0x5c
(XEN)[<00298f1c>] device_tree_for_each_node+0x84/0x144
(XEN)[<0029904c>] boot_fdt_info+0x70/0x23c
(XEN)[<0029c420>] start_xen+0x9c/0xd30
(XEN)[<00200624>] arm64/head.o#paging+0x84/0xbc
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN)
(XEN) 

Indeed, the booting documentation for AArch32 and AArch64 only requires
the FDT to be placed on a 8-byte boundary. This means the Device-Tree can
cross a 2MB boundary.

Given that Xen limits the size of the FDT to 2MB, it will always fit in
a 4MB slot. So extend the fixmap slot for FDT from 2MB to 4MB.

The second 2MB 

[Xen-devel] [PATCH for-4.9 1/4] xen/arm: Add BOOT_FDT_VIRT_END and BOOT_FDT_SLOT_SIZE

[Julien Grall]

The 2 new defines will help to avoid hardcoding the size and the end of
the slot in the code.

The newlines are added for clarity.

Signed-off-by: Julien Grall 
---
 xen/include/asm-arm/config.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index b2edf95f72..9c14a385e7 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -111,7 +111,11 @@
 
 #define XEN_VIRT_START _AT(vaddr_t,0x0020)
 #define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE)
+
 #define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060)
+#define BOOT_FDT_SLOT_SIZE MB(2)
+#define BOOT_FDT_VIRT_END  (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE)
+
 #define BOOT_RELOC_VIRT_START  _AT(vaddr_t,0x0080)
 #ifdef CONFIG_LIVEPATCH
 #define LIVEPATCH_VMAP_START   _AT(vaddr_t,0x0080)
-- 
2.11.0


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

[Xen-devel] [PATCH for-4.9 3/4] xen/arm: Check if the FDT passed by the bootloader is valid

[Julien Grall]

There is currently no sanity check on the FDT passed by the bootloader.
Whilst they are stricly not necessary, it will avoid us to spend hours
to try to find out why it does not work.

From the booting documentation for AArch32 [1] and AArch64 [2] must :
- be placed on 8-byte boundary
- not exceed 2MB (only on AArch64)

Even if AArch32 does not seem to limit the size, Xen is not currently
able to support more the 2MB FDT. It is better to crash rather with a nice
error message than claiming we are supporting any size of FDT.

The checks are mostly borrowed from the Linux code (see fixmap_remap_fdt
in arch/arm64/mm/mmu.c).

[1] Section 2 in linux/Documentation/arm64/booting.txt
[2] Section 4b in linux/Documentation/arm/Booting

Signed-off-by: Julien Grall 
---
 xen/arch/arm/mm.c   | 29 -
 xen/arch/arm/setup.c|  6 ++
 xen/include/asm-arm/setup.h |  3 +++
 3 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 0d076489c6..53d36e2ce2 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -39,6 +39,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 static void __init create_mappings(lpae_t *second,
unsigned long virt_offset,
@@ -447,11 +449,36 @@ void * __init early_fdt_map(paddr_t fdt_paddr)
 {
 /* We are using 2MB superpage for mapping the FDT */
 paddr_t base_paddr = fdt_paddr & SECOND_MASK;
+paddr_t offset;
+void *fdt_virt;
+
+/*
+ * Check whether the physical FDT address is set and meets the minimum
+ * alignment requirement. Since we are relying on MIN_FDT_ALIGN to be at
+ * least 8 bytes so that we always access the magic and size fields
+ * of the FDT header after mapping the first chunk, double check if
+ * that is indeed the case.
+ */
+BUILD_BUG_ON(MIN_FDT_ALIGN < 8);
+if ( !fdt_paddr || fdt_paddr % MIN_FDT_ALIGN )
+return NULL;
+
+/* The FDT is mapped using 2MB superpage */
+BUILD_BUG_ON(BOOT_FDT_VIRT_START % SZ_2M);
 
 create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
 SZ_2M >> PAGE_SHIFT, SZ_2M);
 
-return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
+offset = fdt_paddr % SECOND_SIZE;
+fdt_virt = (void *)BOOT_FDT_VIRT_START + offset;
+
+if ( fdt_magic(fdt_virt) != FDT_MAGIC )
+return NULL;
+
+if ( fdt_totalsize(fdt_virt) > MAX_FDT_SIZE )
+return NULL;
+
+return fdt_virt;
 }
 
 void __init remove_early_mappings(void)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 986398970f..8f72f31fb5 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -725,6 +725,12 @@ void __init start_xen(unsigned long boot_phys_offset,
 smp_clear_cpu_maps();
 
 device_tree_flattened = early_fdt_map(fdt_paddr);
+if ( !device_tree_flattened )
+panic("Invalid device tree blob at physical address %#lx\n"
+  "The DTB must be 8-byte aligned and must not exceed 2 MB in 
size\n"
+  "\nPlease check your bootloader.",
+  fdt_paddr);
+
 fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
 cmdline = boot_fdt_cmdline(device_tree_flattened);
diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7c761851d2..7ff2c34dab 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -3,6 +3,9 @@
 
 #include 
 
+#define MIN_FDT_ALIGN 8
+#define MAX_FDT_SIZE SZ_2M
+
 #define NR_MEM_BANKS 64
 
 #define MAX_MODULES 5 /* Current maximum useful modules */
-- 
2.11.0


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

[Xen-devel] [PATCH for-4.9 2/4] xen/arm: Move the code to map FDT in the boot tables from assembly to C

[Julien Grall]

The FDT will not be accessed before start_xen (begining of C code) is
called and it will be easier to maintain as the code could be common
between AArch32 and AArch64.

A new function early_fdt_map is introduced to map the FDT in the boot
page table.

Note that create_mapping will flush the TLBs for us so no need to add an
extra on in case the entry was previously used by the 1:1 mapping.

Signed-off-by: Julien Grall 

---

I can move the function create_mappings at the beginning of the
function instead of adding a static declaration. But I thought it
was not Xen 4.9 material. Any opinions?
---
 xen/arch/arm/arm32/head.S | 14 --
 xen/arch/arm/arm64/head.S | 13 -
 xen/arch/arm/mm.c | 20 
 xen/arch/arm/setup.c  |  4 +---
 xen/include/asm-arm/mm.h  |  2 ++
 5 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index ec63ba4c04..4090f4a744 100644
--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -389,20 +389,6 @@ paging:
 /* Use a virtual address to access the UART. */
 ldr   r11, =EARLY_UART_VIRTUAL_ADDRESS
 #endif
-/* Map the DTB in the boot misc slot */
-teq   r12, #0/* Only on boot CPU */
-bne   1f
-
-ldr   r1, =boot_second
-mov   r3, #0x0
-lsr   r2, r8, #SECOND_SHIFT
-lsl   r2, r2, #SECOND_SHIFT  /* r2: 2MB-aligned paddr of DTB */
-orr   r2, r2, #PT_UPPER(MEM)
-orr   r2, r2, #PT_LOWER(MEM) /* r2:r3 := 2MB RAM incl. DTB */
-ldr   r4, =BOOT_FDT_VIRT_START
-mov   r4, r4, lsr #(SECOND_SHIFT - 3)   /* Slot for 
BOOT_FDT_VIRT_START */
-strd  r2, r3, [r1, r4]   /* Map it in the early fdt slot */
-1:
 
 /*
  * Flush the TLB in case the 1:1 mapping happens to clash with
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index 72ea4e0233..78292f4396 100644
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -550,19 +550,6 @@ paging:
 ldr   x23, =EARLY_UART_VIRTUAL_ADDRESS
 #endif
 
-/* Map the DTB in the boot misc slot */
-cbnz  x22, 1f/* Only on boot CPU */
-
-ldr   x4, =boot_second   /* x4 := vaddr (boot_second) */
-lsr   x2, x21, #SECOND_SHIFT
-lsl   x2, x2, #SECOND_SHIFT  /* x2 := 2MB-aligned paddr of DTB */
-mov   x3, #PT_MEM/* x2 := 2MB RAM incl. DTB */
-orr   x2, x2, x3
-ldr   x1, =BOOT_FDT_VIRT_START
-lsr   x1, x1, #(SECOND_SHIFT - 3)   /* x4 := Slot for 
BOOT_FDT_VIRT_START */
-str   x2, [x4, x1]   /* Map it in the early fdt slot */
-1:
-
 /*
  * Flush the TLB in case the 1:1 mapping happens to clash with
  * the virtual addresses used by the fixmap or DTB.
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index f0a2eddaaf..0d076489c6 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -38,6 +38,13 @@
 #include 
 #include 
 #include 
+#include 
+
+static void __init create_mappings(lpae_t *second,
+   unsigned long virt_offset,
+   unsigned long base_mfn,
+   unsigned long nr_mfns,
+   unsigned int mapping_size);
 
 struct domain *dom_xen, *dom_io, *dom_cow;
 
@@ -434,6 +441,19 @@ static inline lpae_t pte_of_xenaddr(vaddr_t va)
 return mfn_to_xen_entry(mfn, WRITEALLOC);
 }
 
+
+/* Map the FDT in the early boot page table */
+void * __init early_fdt_map(paddr_t fdt_paddr)
+{
+/* We are using 2MB superpage for mapping the FDT */
+paddr_t base_paddr = fdt_paddr & SECOND_MASK;
+
+create_mappings(boot_second, BOOT_FDT_VIRT_START, paddr_to_pfn(base_paddr),
+SZ_2M >> PAGE_SHIFT, SZ_2M);
+
+return (void *)BOOT_FDT_VIRT_START + (fdt_paddr % SECOND_SIZE);
+}
+
 void __init remove_early_mappings(void)
 {
 lpae_t pte = {0};
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 92a2de6b70..986398970f 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -724,9 +724,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 
 smp_clear_cpu_maps();
 
-/* This is mapped by head.S */
-device_tree_flattened = (void *)BOOT_FDT_VIRT_START
-+ (fdt_paddr & ((1 << SECOND_SHIFT) - 1));
+device_tree_flattened = early_fdt_map(fdt_paddr);
 fdt_size = boot_fdt_info(device_tree_flattened, fdt_paddr);
 
 cmdline = boot_fdt_cmdline(device_tree_flattened);
diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index 0fef612f42..f6915ad882 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -160,6 +160,8 @@ extern unsigned long total_pages;
 
 /* Boot-time pagetable setup */
 extern void setup_pagetables(unsigned long boot_phys_offset, paddr_t 
xen_paddr);
+/* Map FDT in boot pagetable */

[Xen-devel] [PATCH for-4.9 0/4] xen/arm: Properly map the FDT in the boot page table

[Julien Grall]

Hi,

Whilst doing some testing on Juno using GRUB, I noticed random early crash
depending ([1]) on the binaries I was using.

This is because Xen is assuming that the FDT will always fit in a 2MB
superpage whilst the boot documentation allow the FDT to cross a 2MB boundary.

The first patch move the code that map the FDT in the boot page table from
assembly to C making easier to modify the code.

This series is candidate for Xen 4.9. Whilst this early boot rework sounds
scary, a user can see random early crash without this series. I chose
to move all the FDT mapping code in C right now because it is less error-prone
to write C code than assembly.

I have tested both ARM32 and ARM64 with different position of the FDT without
noticing any issue.

Cheers,

[1]

(XEN) Hypervisor Trap. HSR=0x9606 EC=0x25 IL=1 Syndrome=0x6
(XEN) CPU0: Unexpected Trap: Hypervisor
(XEN) [ Xen-4.9-unstable  arm64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 00264140 strlen+0x10/0x84
(XEN) LR: 002401c0
(XEN) SP: 002cfc20
(XEN) CPSR:   43c9 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)  X0: 00801230  X1: 00801230  X2: 5230
(XEN)  X3: 0030  X4: 0030  X5: 0038
(XEN)  X6: 0034  X7:   X8: 7f7f7f7f7f7f7f7f
(XEN)  X9: 64622c6479687222 X10: 7f7f7f7f7f7f7f7f X11: 0101010101010101
(XEN) X12: 0030 X13: ff00ff00 X14: 08000300
(XEN) X15:  X16: fefff610 X17: 00f0
(XEN) X18: 0004 X19: 0008 X20: 007fc040
(XEN) X21: 007fc000 X22: 000e X23: 
(XEN) X24: 002a9f58 X25: 00801230 X26: 002a9f68
(XEN) X27: 002a9f58 X28: 00298910  FP: 002cfc20
(XEN)
(XEN)   VTCR_EL2: 80010c40
(XEN)  VTTBR_EL2: 082800203000
(XEN)
(XEN)  SCTLR_EL2: 30c5183d
(XEN)HCR_EL2: 0038663f
(XEN)  TTBR0_EL2: f4912000
(XEN)
(XEN)ESR_EL2: 9606
(XEN)  HPFAR_EL2: e8071000
(XEN)FAR_EL2: 00801230
(XEN)
(XEN) Xen stack trace from sp=002cfc20:
(XEN)002cfc70 00240254 002a9f58 007fc000
(XEN)   007fc03c
(XEN)002cfd78  002cfca0 002986fc
(XEN) 007fc000  
(XEN)002cfcc0 00298f1c  007fc000
(XEN)002cfdc0 0029904c f47fc000 f4604000
(XEN)f47fc000 007fc000 0040 0100
(XEN)f4604000 0001 0001 8002
(XEN)   
(XEN)   
(XEN)   
(XEN)  002cfdc0 00299038
(XEN)f47fc000 f4604000 f47fc000 
(XEN)002cfe20 0029c420 002d8000 f4604000
(XEN)f47fc000  0040 0100
(XEN)f4604000 0001 f47fc000 0029c404
(XEN)fefff510 00200624 f4804000 f4604000
(XEN)f47fc000  0040 0100
(XEN)0001 0001 0001 8002
(XEN)f47fc000   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN)   
(XEN) Xen call trace:
(XEN)[<00264140>] strlen+0x10/0x84 (PC)
(XEN)[<002401c0>] fdt_get_property_namelen+0x9c/0xf0 (LR)
(XEN)[<00240254>] fdt_get_property+0x40/0x50
(XEN)[<002986fc>] bootfdt.c#device_tree_get_u32+0x18/0x5c
(XEN)[<00298f1c>] device_tree_for_each_node+0x84/0x144
(XEN)[<0029904c>] boot_fdt_info+0x70/0x23c

[Xen-devel] [PATCH] xen/9pfs: select CONFIG_XEN_XENBUS_FRONTEND

[Arnd Bergmann]

All Xen frontends need to select this symbol to avoid a link error:

net/built-in.o: In function `p9_trans_xen_init':
:(.text+0x149e9c): undefined reference to `__xenbus_register_frontend'

Fixes: d4b40a02f837 ("xen/9pfs: build 9pfs Xen transport driver")
Signed-off-by: Arnd Bergmann 
---
 net/9p/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/9p/Kconfig b/net/9p/Kconfig
index 3f286f1bd1d3..e6014e0e51f7 100644
--- a/net/9p/Kconfig
+++ b/net/9p/Kconfig
@@ -24,6 +24,7 @@ config NET_9P_VIRTIO
 
 config NET_9P_XEN
depends on XEN
+   select XEN_XENBUS_FRONTEND
tristate "9P Xen Transport"
help
  This builds support for a transport for 9pfs between
-- 
2.9.0


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 33cc487c263384451aef77fa5d749fd4f3d78b7d
baseline version:
 ovmf f76bc44362e5f0a2ea509c07b2f6846bd9833ee8

Last test of basis   107499  2017-04-18 11:15:25 Z1 days
Testing same since   107535  2017-04-19 03:15:28 Z0 days1 attempts


People who touched revisions under test:
  Ruiyu Ni 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH] x86/hvm: Corrections and improvements to unhandled vmexit logging

[Boris Ostrovsky]

On 04/19/2017 11:58 AM, Andrew Cooper wrote:
>  * Use gprintk rather than gdprintk.  These logging messages shouldn't
>disappear in release builds, as they usually happen immediately before a
>domain crash.  Raise them from WARNING to ERR.
>  * Format the vmexit reason in the same base as is used in the vendor
>manuals (decimal for Intel, hex for AMD), and consistently use 0x for hex
>numbers.
>
> In particular, this corrects the information printed for nested VT-x, and
> actually prints information for nested SVM.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Eric DeVolder]

On 04/19/2017 11:21 AM, Jan Beulich wrote:

On 19.04.17 at 17:47,  wrote:

@@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 if ( kexec_load_get_bits(type, , ) )
 return -EINVAL;

-spin_lock(_lock);
+ASSERT( !test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) );


Did you test this (in a debug build)? I ask because it looks to me that
you've inverted the condition.


You are correct, I inverted the condition. I had found this shortly 
after posting, and have corrected and have tested with Config.mk:debug=y


I will repost patch.

Thanks,
eric



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

Re: [Xen-devel] null domains after xl destroy

[Steven Haigh]

On 19/04/17 20:09, Juergen Gross wrote:
> On 19/04/17 09:16, Roger Pau Monné wrote:
>> On Wed, Apr 19, 2017 at 06:39:41AM +0200, Juergen Gross wrote:
>>> On 19/04/17 03:02, Glenn Enright wrote:
 Thanks Juergen. I applied that, to our 4.9.23 dom0 kernel, which still
 shows the issue. When replicating the leak I now see this trace (via
 dmesg). Hopefully that is useful.

 Please note, I'm going to be offline next week, but am keen to keep on
 with this, it may just be a while before I followup is all.

 Regards, Glenn
 http://rimuhosting.com


 [ cut here ]
 WARNING: CPU: 0 PID: 19 at drivers/block/xen-blkback/xenbus.c:508
 xen_blkbk_remove+0x138/0x140
 Modules linked in: xen_pciback xen_netback xen_gntalloc xen_gntdev
 xen_evtchn xenfs xen_privcmd xt_CT ipt_REJECT nf_reject_ipv4
 ebtable_filter ebtables xt_hashlimit xt_recent xt_state iptable_security
 iptable_raw igle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables bridge stp llc
 ipv6 crc_ccitt ppdev parport_pc parport serio_raw sg i2c_i801 i2c_smbus
 i2c_core e1000e ptp p000_edac edac_core raid1 sd_mod ahci libahci floppy
 dm_mirror dm_region_hash dm_log dm_mod
 CPU: 0 PID: 19 Comm: xenwatch Not tainted 4.9.23-1.el6xen.x86_64 #1
 Hardware name: Supermicro PDSML/PDSML+, BIOS 6.00 08/27/2007
  c90040cfbba8 8136b61f 0013 
    c90040cfbbf8 8108007d
  ea0001373fe0 01fc33394434 8801 88004d93fac0
 Call Trace:
  [] dump_stack+0x67/0x98
  [] __warn+0xfd/0x120
  [] warn_slowpath_null+0x1d/0x20
  [] xen_blkbk_remove+0x138/0x140
  [] xenbus_dev_remove+0x47/0xa0
  [] __device_release_driver+0xb4/0x160
  [] device_release_driver+0x2d/0x40
  [] bus_remove_device+0x124/0x190
  [] device_del+0x112/0x210
  [] ? xenbus_read+0x53/0x70
  [] device_unregister+0x22/0x60
  [] frontend_changed+0xad/0x4c0
  [] ? schedule_tail+0x1e/0xc0
  [] xenbus_otherend_changed+0xc7/0x140
  [] ? _raw_spin_unlock_irqrestore+0x16/0x20
  [] ? schedule_tail+0x1e/0xc0
  [] frontend_changed+0x10/0x20
  [] xenwatch_thread+0x9c/0x140
  [] ? woken_wake_function+0x20/0x20
  [] ? schedule+0x3a/0xa0
  [] ? _raw_spin_unlock_irqrestore+0x16/0x20
  [] ? complete+0x4d/0x60
  [] ? split+0xf0/0xf0
  [] kthread+0xcd/0xf0
  [] ? schedule_tail+0x1e/0xc0
  [] ? __kthread_init_worker+0x40/0x40
  [] ? __kthread_init_worker+0x40/0x40
  [] ret_from_fork+0x25/0x30
 ---[ end trace ee097287c9865a62 ]---
>>>
>>> Konrad, Roger,
>>>
>>> this was triggered by a debug patch in xen_blkbk_remove():
>>>
>>> if (be->blkif)
>>> -   xen_blkif_disconnect(be->blkif);
>>> +   WARN_ON(xen_blkif_disconnect(be->blkif));
>>>
>>> So I guess we need something like xen_blk_drain_io() in case of calls to
>>> xen_blkif_disconnect() which are not allowed to fail (either at the call
>>> sites of xen_blkif_disconnect() or in this function depending on a new
>>> boolean parameter indicating it should wait for outstanding I/Os).
>>>
>>> I can try a patch, but I'd appreciate if you could confirm this wouldn't
>>> add further problems...
>>
>> Hello,
>>
>> Thanks for debugging this, the easiest solution seems to be to replace the
>> ring->inflight atomic_read check in xen_blkif_disconnect with a call to
>> xen_blk_drain_io instead, and making xen_blkif_disconnect return void (to
>> prevent further issues like this one).
> 
> Glenn,
> 
> can you please try the attached patch (in dom0)?

For what its worth, I have applied this in kernel package 4.9.23-2 as
follows:

* Wed Apr 19 2017 Steven Haigh  - 4.9.23-2
- xen/blkback: fix disconnect while I/Os in flight

Its available from any 'in sync' mirror:
https://xen.crc.id.au/downloads/

Feedback welcome for both mine and Juergen's sake.

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



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

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Jan Beulich]

>>> On 19.04.17 at 17:47,  wrote:
> @@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image 
> *new,
>  if ( kexec_load_get_bits(type, , ) )
>  return -EINVAL;
>  
> -spin_lock(_lock);
> +ASSERT( !test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) );

Did you test this (in a debug build)? I ask because it looks to me that
you've inverted the condition.

Jan


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

Re: [Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

[Jan Beulich]

>>> On 19.04.17 at 17:54,  wrote:
> On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote:
>> @@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op,
>>  if ( ret )
>>  return ret;
>>
>> +if ( test_and_set_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) )
>> +return hypercall_create_continuation(__HYPERVISOR_kexec_op, "lh", 
>> op, uarg);
>> +
> 
> I would suggest here:
>ASSERT(test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags));

You're kidding? The flag was set just in the line above. Or do you
really mean we need to consider test_and_set_bit() not doing what
it is supposed to do?

Jan


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

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Eric DeVolder]

On 04/19/2017 10:47 AM, Eric DeVolder wrote:

The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec hypercall, which is
now protected at the top-level in do_kexec_op_internal(),
thus the local spinlock is no longer necessary.

Per recommendation from Jan Beulich and Andrew Cooper, I left
an ASSERT in place of the spin_lock().

Signed-off-by: Eric DeVolder 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v3:
 - Incorporated feedback from Jan Beulich and Andrew Cooper
   to leave an ASSERT where spin_lock() once was.

v2: 04/17/2017
 - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC ops'
 - Separated removal of spinlock in kexec_swap_images() into its own patch.

v1: 04/10/2017
 - Patch titled 'kexec: Add spinlock for the whole hypercall'
 - Removal of spinlock in kexec_swap_images() was part of other patch.
---
 xen/common/kexec.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 253c204..af32e58 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -820,7 +820,6 @@ static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
 static int kexec_swap_images(int type, struct kexec_image *new,
  struct kexec_image **old)
 {
-static DEFINE_SPINLOCK(kexec_lock);
 int base, bit, pos;
 int new_slot, old_slot;

@@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 if ( kexec_load_get_bits(type, , ) )
 return -EINVAL;

-spin_lock(_lock);
+ASSERT( !test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) );


There are two problems here: the spaces need to be eliminated, and more 
importantly, the sense/polarity of the expression is wrong, the '!' 
needs to be removed.




 pos = (test_bit(bit, _flags) != 0);
 old_slot = base + pos;
@@ -846,8 +845,6 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 clear_bit(old_slot, _flags);
 *old = kexec_image[old_slot];

-spin_unlock(_lock);
-
 return 0;
 }





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

Re: [Xen-devel] [PATCH v3] xen, input: add xen-kbdfront module parameter for setting resolution

[Dmitry Torokhov]

On Tue, Apr 11, 2017 at 02:30:37PM +0200, Juergen Gross wrote:
> Add a parameter for setting the resolution of xen-kbdfront in order to
> be able to cope with a (virtual) frame buffer of arbitrary resolution.
> 
> While at it remove the pointless second reading of parameters from
> Xenstore in the device connection phase: all parameters are available
> during device probing already and that is where they should be read.
> 
> Signed-off-by: Juergen Gross 

Applied, thank you.

> ---
> V3: - merged the two patches
> - read Xenstore parameters during probing of the device only
> ---
>  drivers/input/misc/xen-kbdfront.c | 39 
> ++-
>  1 file changed, 14 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/input/misc/xen-kbdfront.c 
> b/drivers/input/misc/xen-kbdfront.c
> index 3900875dec10..2fc7895373ab 100644
> --- a/drivers/input/misc/xen-kbdfront.c
> +++ b/drivers/input/misc/xen-kbdfront.c
> @@ -41,6 +41,12 @@ struct xenkbd_info {
>   char phys[32];
>  };
>  
> +enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
> +static int ptr_size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
> +module_param_array(ptr_size, int, NULL, 0444);
> +MODULE_PARM_DESC(ptr_size,
> + "Pointing device width, height in pixels (default 800,600)");
> +
>  static int xenkbd_remove(struct xenbus_device *);
>  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
> *);
>  static void xenkbd_disconnect_backend(struct xenkbd_info *);
> @@ -128,7 +134,12 @@ static int xenkbd_probe(struct xenbus_device *dev,
>   if (!info->page)
>   goto error_nomem;
>  
> + /* Set input abs params to match backend screen res */
>   abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
> + ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
> +   ptr_size[KPARAM_X]);
> + ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
> +   ptr_size[KPARAM_Y]);
>   if (abs) {
>   ret = xenbus_write(XBT_NIL, dev->nodename,
>  "request-abs-pointer", "1");
> @@ -174,8 +185,8 @@ static int xenkbd_probe(struct xenbus_device *dev,
>  
>   if (abs) {
>   __set_bit(EV_ABS, ptr->evbit);
> - input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
> - input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
> + input_set_abs_params(ptr, ABS_X, 0, ptr_size[KPARAM_X], 0, 0);
> + input_set_abs_params(ptr, ABS_Y, 0, ptr_size[KPARAM_Y], 0, 0);
>   } else {
>   input_set_capability(ptr, EV_REL, REL_X);
>   input_set_capability(ptr, EV_REL, REL_Y);
> @@ -309,9 +320,6 @@ static void xenkbd_disconnect_backend(struct xenkbd_info 
> *info)
>  static void xenkbd_backend_changed(struct xenbus_device *dev,
>  enum xenbus_state backend_state)
>  {
> - struct xenkbd_info *info = dev_get_drvdata(>dev);
> - int ret, val;
> -
>   switch (backend_state) {
>   case XenbusStateInitialising:
>   case XenbusStateInitialised:
> @@ -321,15 +329,6 @@ static void xenkbd_backend_changed(struct xenbus_device 
> *dev,
>   break;
>  
>   case XenbusStateInitWait:
> -InitWait:
> - if (xenbus_read_unsigned(info->xbdev->otherend,
> -  "feature-abs-pointer", 0)) {
> - ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
> -"request-abs-pointer", "1");
> - if (ret)
> - pr_warning("xenkbd: can't request abs-pointer");
> - }
> -
>   xenbus_switch_state(dev, XenbusStateConnected);
>   break;
>  
> @@ -340,17 +339,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
> *dev,
>* get Connected twice here.
>*/
>   if (dev->state != XenbusStateConnected)
> - goto InitWait; /* no InitWait seen yet, fudge it */
> -
> - /* Set input abs params to match backend screen res */
> - if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> -  "width", "%d", ) > 0)
> - input_set_abs_params(info->ptr, ABS_X, 0, val, 0, 0);
> -
> - if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
> -  "height", "%d", ) > 0)
> - input_set_abs_params(info->ptr, ABS_Y, 0, val, 0, 0);
> -
> + xenbus_switch_state(dev, XenbusStateConnected);
>   break;
>  
>   case XenbusStateClosed:
> -- 
> 2.12.0
> 

-- 
Dmitry

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

Re: [Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Daniel Kiper]

On Wed, Apr 19, 2017 at 10:47:16AM -0500, Eric DeVolder wrote:
> The spinlock in kexec_swap_images() was removed as
> this function is only reachable on the kexec hypercall, which is
> now protected at the top-level in do_kexec_op_internal(),
> thus the local spinlock is no longer necessary.
>
> Per recommendation from Jan Beulich and Andrew Cooper, I left
> an ASSERT in place of the spin_lock().
>
> Signed-off-by: Eric DeVolder 
> Reviewed-by: Bhavesh Davda 
> Reviewed-by: Konrad Rzeszutek Wilk 
> ---
> v3:
>  - Incorporated feedback from Jan Beulich and Andrew Cooper
>to leave an ASSERT where spin_lock() once was.
>
> v2: 04/17/2017
>  - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC 
> ops'
>  - Separated removal of spinlock in kexec_swap_images() into its own patch.
>
> v1: 04/10/2017
>  - Patch titled 'kexec: Add spinlock for the whole hypercall'
>  - Removal of spinlock in kexec_swap_images() was part of other patch.
> ---
>  xen/common/kexec.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/xen/common/kexec.c b/xen/common/kexec.c
> index 253c204..af32e58 100644
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -820,7 +820,6 @@ static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
>  static int kexec_swap_images(int type, struct kexec_image *new,
>   struct kexec_image **old)
>  {
> -static DEFINE_SPINLOCK(kexec_lock);
>  int base, bit, pos;
>  int new_slot, old_slot;
>
> @@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image 
> *new,
>  if ( kexec_load_get_bits(type, , ) )
>  return -EINVAL;
>
> -spin_lock(_lock);
> +ASSERT( !test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) );

...and drop ASSERT() here.

Daniel

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

[Xen-devel] [PATCH] x86/hvm: Corrections and improvements to unhandled vmexit logging

[Andrew Cooper]

 * Use gprintk rather than gdprintk.  These logging messages shouldn't
   disappear in release builds, as they usually happen immediately before a
   domain crash.  Raise them from WARNING to ERR.
 * Format the vmexit reason in the same base as is used in the vendor
   manuals (decimal for Intel, hex for AMD), and consistently use 0x for hex
   numbers.

In particular, this corrects the information printed for nested VT-x, and
actually prints information for nested SVM.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
CC: Julien Grall 

Request for this to be in 4.9, for the purposes of these log messages
remaining present in release builds.  The nested versions are less important,
but modified here for consistency.

For the nested virt side of things, it is insecure to ever hit the default
case, as it causes unknown exits to be handled in the context of being L1,
even when it originated from L2.  I considered putting using domain_crash(),
but that isn't very helpful, and nested virt is still strictly expermiental.
---
 xen/arch/x86/hvm/svm/nestedsvm.c | 2 ++
 xen/arch/x86/hvm/svm/svm.c   | 7 +++
 xen/arch/x86/hvm/vmx/vmx.c   | 2 +-
 xen/arch/x86/hvm/vmx/vvmx.c  | 4 ++--
 4 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index d4fc81f..097a4d8 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -1406,6 +1406,8 @@ nestedsvm_check_intercepts(struct vcpu *v, struct 
cpu_user_regs *regs,
 /* Always let the guest handle VMMCALL/VMCALL */
 return NESTEDHVM_VMEXIT_INJECT;
 default:
+gprintk(XENLOG_ERR, "Unhandled nested vmexit: reason %#"PRIx64"\n",
+exitcode);
 break;
 }
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 07e9718..68bdcdd 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -2833,10 +2833,9 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 
 default:
 unexpected_exit_type:
-gdprintk(XENLOG_ERR, "unexpected VMEXIT: exit reason = %#"PRIx64", "
- "exitinfo1 = %#"PRIx64", exitinfo2 = %#"PRIx64"\n",
- exit_reason, 
- (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
+gprintk(XENLOG_ERR, "Bad vmexit: reason %#"PRIx64", "
+"exitinfo1 %#"PRIx64", exitinfo2 %#"PRIx64"\n",
+exit_reason, (u64)vmcb->exitinfo1, (u64)vmcb->exitinfo2);
 svm_crash_or_fault(v);
 break;
 }
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index f8d3c17..98d3f08 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4106,7 +4106,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
 /* fall through */
 default:
 exit_and_crash:
-gdprintk(XENLOG_WARNING, "Bad vmexit (reason %#lx)\n", exit_reason);
+gprintk(XENLOG_ERR, "Bad vmexit: reason %ld\n", exit_reason);
 
 if ( vmx_get_cpl() )
 hvm_inject_hw_exception(TRAP_invalid_op,
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 936feb6..560babb 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2550,8 +2550,8 @@ int nvmx_n2_vmexit_handler(struct cpu_user_regs *regs,
 nvcpu->nv_vmexit_pending = 1;
 break;
 default:
-gdprintk(XENLOG_WARNING, "Unknown nested vmexit reason %x.\n",
- exit_reason);
+gprintk(XENLOG_ERR, "Unhandled nested vmexit: reason %u\n",
+exit_reason);
 }
 
 return ( nvcpu->nv_vmexit_pending == 1 );
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

[Daniel Kiper]

On Wed, Apr 19, 2017 at 10:47:15AM -0500, Eric DeVolder wrote:
> When we concurrently try to unload and load crash
> images we eventually get:
>
>  Xen call trace:
> [] machine_kexec_add_page+0x3a0/0x3fa
> [] machine_kexec_load+0xdb/0x107
> [] kexec.c#kexec_load_slot+0x11/0x42
> [] kexec.c#kexec_load+0x119/0x150
> [] kexec.c#do_kexec_op_internal+0xab/0xcf
> [] do_kexec_op+0xe/0x1e
> [] pv_hypercall+0x20a/0x44a
> [] cpufreq.c#test_all_events+0/0x30
>
>  Pagetable walk from 820040088320:
>   L4[0x104] = 0002979d1063 
>   L3[0x001] = 0002979d0063 
>   L2[0x000] = 0002979c7063 
>   L1[0x088] = 80037a91ede97063 
>
> The interesting thing is that the page bits (063) look legit.
>
> The operation on which we blow up is us trying to write
> in the L1 and finding that the L2 entry points to some
> bizzare MFN. It stinks of a race, and it looks like
> the issue is due to no concurrency locks when dealing
> with the crash kernel space.
>
> Specifically we concurrently call kimage_alloc_crash_control_page
> which iterates over the kexec_crash_area.start -> kexec_crash_area.size
> and once found:
>
>   if ( page )
>   {
>   image->next_crash_page = hole_end;
>   clear_domain_page(_mfn(page_to_mfn(page)));
>   }
>
> clears. Since the parameters of what MFN to use are provided
> by the callers (and the area to search is bounded) the the 'page'
> is probably the same. So #1 we concurrently clear the
> 'control_code_page'.
>
> The next step is us passing this 'control_code_page' to
> machine_kexec_add_page. This function requires the MFNs:
> page_to_maddr(image->control_code_page).
>
> And this would always return the same virtual address, as
> the MFN of the control_code_page is inside of the
> kexec_crash_area.start -> kexec_crash_area.size area.
>
> Then machine_kexec_add_page updates the L1 .. which can be done
> concurrently and on subsequent calls we mangle it up.
>
> This is all a theory at this time, but testing reveals
> that adding the hypercall_create_continuation() at the
> kexec hypercall fixes the crash.
>
> NOTE: This patch follows 5c5216 (kexec: clear kexec_image slot
> when unloading kexec image) to prevent crashes during
> simultaneous load/unloads.
>
> NOTE: Consideration was given to using the existing flag
> KEXEC_FLAG_IN_PROGRESS to denote a kexec hypercall in
> progress. This, however, overloads the original intent of
> the flag which is to denote that we are about-to/have made
> the jump to the crash path. The overloading would lead to
> failures in existing checks on this flag as the flag would
> always be set at the top level in do_kexec_op_internal().
> For this reason, the new flag KEXEC_FLAG_HC_IN_PROGRESS
> was introduced.
>
> While at it, fixed the #define mismatched spacing
>
> Signed-off-by: Eric DeVolder 
> Reviewed-by: Bhavesh Davda 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Jan Beulich 
> Reviewed-by: Andrew Cooper 
> Reviewed-by: Daniel Kiper 
> ---
> v3:
>  - Incorporated feedback from Jan Beulich to change the
>name of the new flag to KEXEC_FLAG_IN_HYPERCALL
>
> v2: 04/17/2017
>  - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC 
> ops'
>  - Jan Beulich directed me to use a continuation method instead
>of spinlock.
>  - Incorporated feedback from Daniel Kiper 
>  - Incorporated feedback from Konrad Wilk 
>
> v1: 04/10/2017
>  - Patch titled 'kexec: Add spinlock for the whole hypercall'
>  - Used spinlock in do_kexec_op_internal()
> ---
>  xen/common/kexec.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/xen/common/kexec.c b/xen/common/kexec.c
> index 072cc8e..253c204 100644
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus;
>
>  static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];
>
> -#define KEXEC_FLAG_DEFAULT_POS   (KEXEC_IMAGE_NR + 0)
> -#define KEXEC_FLAG_CRASH_POS (KEXEC_IMAGE_NR + 1)
> -#define KEXEC_FLAG_IN_PROGRESS   (KEXEC_IMAGE_NR + 2)
> +#define KEXEC_FLAG_DEFAULT_POS  (KEXEC_IMAGE_NR + 0)
> +#define KEXEC_FLAG_CRASH_POS(KEXEC_IMAGE_NR + 1)
> +#define KEXEC_FLAG_IN_PROGRESS  (KEXEC_IMAGE_NR + 2)
> +#define KEXEC_FLAG_IN_HYPERCALL (KEXEC_IMAGE_NR + 3)

I do not think that you need change all of this right now.
Just add one space after KEXEC_FLAG_IN_HYPERCALL and you
are set.

>  static unsigned long kexec_flags = 0; /* the lowest bits are for 
> KEXEC_IMAGE... */
>
> @@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op,
>  if ( ret )
>  return ret;
>
> +if ( test_and_set_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) )
> +return hypercall_create_continuation(__HYPERVISOR_kexec_op, 

Re: [Xen-devel] [PATCH v2 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

[Eric DeVolder]

On 04/19/2017 06:48 AM, Andrew Cooper wrote:

On 19/04/17 12:00, Daniel Kiper wrote:

On Tue, Apr 18, 2017 at 04:48:06AM -0600, Jan Beulich wrote:

On 17.04.17 at 21:09,  wrote:

--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus;

 static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];

-#define KEXEC_FLAG_DEFAULT_POS   (KEXEC_IMAGE_NR + 0)
-#define KEXEC_FLAG_CRASH_POS (KEXEC_IMAGE_NR + 1)
-#define KEXEC_FLAG_IN_PROGRESS   (KEXEC_IMAGE_NR + 2)
+#define KEXEC_FLAG_DEFAULT_POS(KEXEC_IMAGE_NR + 0)
+#define KEXEC_FLAG_CRASH_POS  (KEXEC_IMAGE_NR + 1)
+#define KEXEC_FLAG_IN_PROGRESS(KEXEC_IMAGE_NR + 2)
+#define KEXEC_FLAG_HC_IN_PROGRESS (KEXEC_IMAGE_NR + 3)

Perhaps KEXEC_FLAG_IN_HYPERCALL? Other than that (and this

Make sense for me.


Agreed.  (I can fix on commit).




clearly is subject to Andrew's opinion)
Reviewed-by: Jan Beulich 

Otherwise Reviewed-by: Daniel Kiper 


Reviewed-by: Andrew Cooper 

CC'ing Julien.  This is clearly a good bugfix for 4.9


I've just posted v3 of this patch with the flag name change.
Eric



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

Re: [Xen-devel] [PATCH v2 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Eric DeVolder]

On 04/19/2017 08:37 AM, Jan Beulich wrote:

On 19.04.17 at 14:13,  wrote:

On Wed, Apr 19, 2017 at 05:20:50AM -0600, Jan Beulich wrote:

On 19.04.17 at 12:56,  wrote:

On Tue, Apr 18, 2017 at 04:49:48AM -0600, Jan Beulich wrote:

On 17.04.17 at 21:09,  wrote:

The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec hypercall, which is
now protected at the top-level in do_kexec_op_internal(),
thus the local spinlock is no longer necessary.


But perhaps leave an ASSERT() there, making sure the in-hypercall
flag is set?


I am not sure why but if at all I think that we should also consider
other key kexec functions then. Or put ASSERT() into do_kexec_op_internal()
just before "switch ( op )".


The point of my placement suggestion was that the ASSERT()
effectively replaces the lock acquire - the places you name
didn't previously require any synchronization.


After the first patch of this series kexec_swap_images() cannot be
started twice in parallel. So, I do not see the point of ASSERT() here.
Or let's say we wish to have it to double check that "the in-hypercall
flag is set". AIUI, it is your original idea. However, then I think that
we should have an ASSERT() at least in kexec_load_slot() because parallel
loads make issues too. And we can go higher to feel more safe. That is
why I suggested do_kexec_op_internal() as the final resting place for
an ASSERT(). Simply it looks to me the safest approach. Am I missing
something?


The point you're missing is - why don't you then move the ASSERT()
yet one more level up, right next to where the flag is being set? IOW
what you suggest would imo rather mean not adding any assertion
at all.


I've just posted v3 of this patch with the ASSERT in lieu of the 
spin_lock().


Eric



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

[Xen-devel] [PATCH v3 0/2] kexec: Use hypercall_create_continuation to protect KEXEC ops

[Eric DeVolder]

During testing (using the script below) we found that multiple
invocations of kexec of unload/load are not safe.

This does not exist in classic Xen kernels in which the kexec-tools
did the kexec via Linux kernel syscall (which in turn made the
hypercall), as the Linux code has a mutex_trylock which would
inhibit multiple concurrent calls.

But with the kexec-tools utilizing xc_kexec_* that is no longer
the case and we need to protect against multiple concurrent
invocations.

Please see the patches and review at your convenience!

 try-crash.pl from bhavesh.da...@oracle.com 
#!/usr/bin/perl -w

use strict;
use warnings;
use threads;

sub threaded_task {
threads->create(sub {
my $thr_id = threads->self->tid;
#print "Starting load thread $thr_id\n";
system("/sbin/kexec  -p --command-line=\"placeholder 
root=/dev/mapper/nimbula-root ro rhbg console=tty0 console=hvc0 earlyprintk=xen 
nomodeset printk.time=1 irqpoll maxcpus=1 nr_cpus=1 reset_devices 
cgroup_disable=memory mce=off selinux=0 console=ttyS1,115200n8\" 
--initrd=/boot/initrd-4.1.12-61.1.9.el6uek.x86_64kdump.img 
/boot/vmlinuz-4.1.12-61.1.9.el6uek.x86_64");
#print "Ending load thread $thr_id\n";
threads->detach(); #End thread.
});
threads->create(sub {
my $thr_id = threads->self->tid;
#print "Starting unload thread $thr_id\n";
system("/sbin/kexec  -p -u");
#print "Ending unload thread $thr_id\n";
threads->detach(); #End thread.
});
}

for my $i (0..99)
{
threaded_task();
}


Eric DeVolder (2):
  kexec: use hypercall_create_continuation to protect KEXEC ops
  kexec: remove spinlock now that all KEXEC hypercall ops are protected
at the top-level

 xen/common/kexec.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v3 1/2] kexec: use hypercall_create_continuation to protect KEXEC ops

[Eric DeVolder]

When we concurrently try to unload and load crash
images we eventually get:

 Xen call trace:
[] machine_kexec_add_page+0x3a0/0x3fa
[] machine_kexec_load+0xdb/0x107
[] kexec.c#kexec_load_slot+0x11/0x42
[] kexec.c#kexec_load+0x119/0x150
[] kexec.c#do_kexec_op_internal+0xab/0xcf
[] do_kexec_op+0xe/0x1e
[] pv_hypercall+0x20a/0x44a
[] cpufreq.c#test_all_events+0/0x30

 Pagetable walk from 820040088320:
  L4[0x104] = 0002979d1063 
  L3[0x001] = 0002979d0063 
  L2[0x000] = 0002979c7063 
  L1[0x088] = 80037a91ede97063 

The interesting thing is that the page bits (063) look legit.

The operation on which we blow up is us trying to write
in the L1 and finding that the L2 entry points to some
bizzare MFN. It stinks of a race, and it looks like
the issue is due to no concurrency locks when dealing
with the crash kernel space.

Specifically we concurrently call kimage_alloc_crash_control_page
which iterates over the kexec_crash_area.start -> kexec_crash_area.size
and once found:

  if ( page )
  {
  image->next_crash_page = hole_end;
  clear_domain_page(_mfn(page_to_mfn(page)));
  }

clears. Since the parameters of what MFN to use are provided
by the callers (and the area to search is bounded) the the 'page'
is probably the same. So #1 we concurrently clear the
'control_code_page'.

The next step is us passing this 'control_code_page' to
machine_kexec_add_page. This function requires the MFNs:
page_to_maddr(image->control_code_page).

And this would always return the same virtual address, as
the MFN of the control_code_page is inside of the
kexec_crash_area.start -> kexec_crash_area.size area.

Then machine_kexec_add_page updates the L1 .. which can be done
concurrently and on subsequent calls we mangle it up.

This is all a theory at this time, but testing reveals
that adding the hypercall_create_continuation() at the
kexec hypercall fixes the crash.

NOTE: This patch follows 5c5216 (kexec: clear kexec_image slot
when unloading kexec image) to prevent crashes during
simultaneous load/unloads.

NOTE: Consideration was given to using the existing flag
KEXEC_FLAG_IN_PROGRESS to denote a kexec hypercall in
progress. This, however, overloads the original intent of
the flag which is to denote that we are about-to/have made
the jump to the crash path. The overloading would lead to
failures in existing checks on this flag as the flag would
always be set at the top level in do_kexec_op_internal().
For this reason, the new flag KEXEC_FLAG_HC_IN_PROGRESS
was introduced.

While at it, fixed the #define mismatched spacing

Signed-off-by: Eric DeVolder 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Reviewed-by: Daniel Kiper 
---
v3:
 - Incorporated feedback from Jan Beulich to change the
   name of the new flag to KEXEC_FLAG_IN_HYPERCALL

v2: 04/17/2017
 - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC ops'
 - Jan Beulich directed me to use a continuation method instead
   of spinlock.
 - Incorporated feedback from Daniel Kiper 
 - Incorporated feedback from Konrad Wilk 

v1: 04/10/2017
 - Patch titled 'kexec: Add spinlock for the whole hypercall'
 - Used spinlock in do_kexec_op_internal()
---
 xen/common/kexec.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 072cc8e..253c204 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -50,9 +50,10 @@ static cpumask_t crash_saved_cpus;
 
 static struct kexec_image *kexec_image[KEXEC_IMAGE_NR];
 
-#define KEXEC_FLAG_DEFAULT_POS   (KEXEC_IMAGE_NR + 0)
-#define KEXEC_FLAG_CRASH_POS (KEXEC_IMAGE_NR + 1)
-#define KEXEC_FLAG_IN_PROGRESS   (KEXEC_IMAGE_NR + 2)
+#define KEXEC_FLAG_DEFAULT_POS  (KEXEC_IMAGE_NR + 0)
+#define KEXEC_FLAG_CRASH_POS(KEXEC_IMAGE_NR + 1)
+#define KEXEC_FLAG_IN_PROGRESS  (KEXEC_IMAGE_NR + 2)
+#define KEXEC_FLAG_IN_HYPERCALL (KEXEC_IMAGE_NR + 3)
 
 static unsigned long kexec_flags = 0; /* the lowest bits are for 
KEXEC_IMAGE... */
 
@@ -1193,6 +1194,9 @@ static int do_kexec_op_internal(unsigned long op,
 if ( ret )
 return ret;
 
+if ( test_and_set_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) )
+return hypercall_create_continuation(__HYPERVISOR_kexec_op, "lh", op, 
uarg);
+
 switch ( op )
 {
 case KEXEC_CMD_kexec_get_range:
@@ -1227,6 +1231,8 @@ static int do_kexec_op_internal(unsigned long op,
 break;
 }
 
+clear_bit(KEXEC_FLAG_IN_HYPERCALL, _flags);
+
 return ret;
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v3 2/2] kexec: remove spinlock now that all KEXEC hypercall ops are protected at the top-level

[Eric DeVolder]

The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec hypercall, which is
now protected at the top-level in do_kexec_op_internal(),
thus the local spinlock is no longer necessary.

Per recommendation from Jan Beulich and Andrew Cooper, I left
an ASSERT in place of the spin_lock().

Signed-off-by: Eric DeVolder 
Reviewed-by: Bhavesh Davda 
Reviewed-by: Konrad Rzeszutek Wilk 
---
v3:
 - Incorporated feedback from Jan Beulich and Andrew Cooper
   to leave an ASSERT where spin_lock() once was.

v2: 04/17/2017
 - Patch titled 'kexec: use hypercall_create_continuation to protect KEXEC ops'
 - Separated removal of spinlock in kexec_swap_images() into its own patch.

v1: 04/10/2017
 - Patch titled 'kexec: Add spinlock for the whole hypercall'
 - Removal of spinlock in kexec_swap_images() was part of other patch.
---
 xen/common/kexec.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 253c204..af32e58 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -820,7 +820,6 @@ static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
 static int kexec_swap_images(int type, struct kexec_image *new,
  struct kexec_image **old)
 {
-static DEFINE_SPINLOCK(kexec_lock);
 int base, bit, pos;
 int new_slot, old_slot;
 
@@ -832,7 +831,7 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 if ( kexec_load_get_bits(type, , ) )
 return -EINVAL;
 
-spin_lock(_lock);
+ASSERT( !test_bit(KEXEC_FLAG_IN_HYPERCALL, _flags) );
 
 pos = (test_bit(bit, _flags) != 0);
 old_slot = base + pos;
@@ -846,8 +845,6 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 clear_bit(old_slot, _flags);
 *old = kexec_image[old_slot];
 
-spin_unlock(_lock);
-
 return 0;
 }
 
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 for-next v2 8/8] x86/mm: split HVM grant table code to hvm/mm.c

[Jan Beulich]

>>> On 03.04.17 at 13:22,  wrote:
> PG_external requires hardware support so the code guarded by that is HVM
> only.
> 
> Signed-off-by: Wei Liu 
> ---
>  xen/arch/x86/hvm/Makefile |  1 +
>  xen/arch/x86/hvm/mm.c | 85 
> +++

I think the moved code would better go under x86/mm/, possibly (but
not necessarily) into p2m.c.

Jan


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

Re: [Xen-devel] [PATCH v2 for-next v2 6/8] x86/mm: move two PV hypercalls from x86_64/mm.c to pv/mm.c

[Jan Beulich]

>>> On 03.04.17 at 13:22,  wrote:
> --- a/xen/arch/x86/pv/mm.c
> +++ b/xen/arch/x86/pv/mm.c
> @@ -4106,6 +4106,74 @@ int mmio_ro_do_page_fault(struct vcpu *v, unsigned 
> long addr,

Considering this file is still 4k lines, I'd prefer if stuff not obviously
belonging here could be placed elsewhere.

Jan


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

Re: [Xen-devel] [PATCH v2 for-next v2 5/8] x86/mm: split PV guest supporting code to pv/mm.c

[Jan Beulich]

>>> On 03.04.17 at 13:22,  wrote:
> -static s8 __read_mostly opt_mmio_relax;
> +s8 __read_mostly opt_mmio_relax;
>  static void __init parse_mmio_relax(const char *s)

The variable has exactly one use site outside of the parsing function,
which means both variable and parsing function should be moved too.
However, this sole user is get_page_from_l1e(), and that in turn is
also being used from shadow code. It's not immediately clear to me
whether moving it under pv/ (and hence eventually compiling it out
of Xen when PV is de-selected) is the right thing.

> -static int get_page_from_pagenr(unsigned long page_nr, struct domain *d)
> +int get_page_from_pagenr(unsigned long page_nr, struct domain *d)
>  {

I don't think this should be made non-static without first correcting its
return type - either int (and returning -E... values) or bool.

> @@ -834,3414 +524,489 @@ static int update_xen_mappings(unsigned long mfn, 
> unsigned int cacheattr)
>  return err;
>  }
>  
> -#ifndef NDEBUG
> -struct mmio_emul_range_ctxt {
> -const struct domain *d;
> -unsigned long mfn;
> -};
> -
> -static int print_mmio_emul_range(unsigned long s, unsigned long e, void *arg)
> +bool_t fill_ro_mpt(unsigned long mfn)
>  {
> -const struct mmio_emul_range_ctxt *ctxt = arg;
> -
> -if ( ctxt->mfn > e )
> -return 0;
> +l4_pgentry_t *l4tab = map_domain_page(_mfn(mfn));
> +bool_t ret = 0;

From here on the patch becomes basically unreviewable, because
plain removals (which I'd expect is all that is happening here) aren't
represented as such anymore. Please see whether you can
arrange for the diff to become more legible. If you can't talk git
into doing so, maybe an option would be to split this patch by
temporarily #include-ing pv/mm.c here until the move is complete.

Jan


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

[Xen-devel] [PATCH v2 2/3] x86/pt: enable binding of GSIs to a PVH Dom0

[Roger Pau Monne]

Achieve this by expanding pt_irq_create_bind in order to support mapping
interrupts of type PT_IRQ_TYPE_PCI to a PVH Dom0. GSIs bound to Dom0 are always
identity bound, which means the all the fields inside of the u.pci sub-struct
are ignored, and only the machine_irq is actually used in order to determine
which GSI the caller wants to bind.

Also, the hvm_irq_dpci struct is not used by a PVH Dom0, since that's used to
route interrupts and allow different host to guest GSI mappings, which is not
used by a PVH Dom0.

This requires adding some specific handlers for such directly mapped GSIs,
which bypass the PCI interrupt routing done by Xen for HVM guests.

Note that currently there's no support for unbinding this interrupts.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Remove the PT_IRQ_TYPE_GSI and instead just use PT_IRQ_TYPE_PCI with a
   hardware domain special casing.
 - Check the trigger mode of the Dom0 vIO APIC in order to set the shareable
   flags in pt_irq_create_bind.
---
 xen/arch/x86/hvm/irq.c   |  28 ++
 xen/drivers/passthrough/io.c | 212 ---
 xen/include/xen/hvm/irq.h|   6 ++
 3 files changed, 195 insertions(+), 51 deletions(-)

diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index 86255847a6..cb9084e3f3 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -126,6 +126,34 @@ void hvm_pci_intx_deassert(
 spin_unlock(>arch.hvm_domain.irq_lock);
 }
 
+void hvm_gsi_assert(struct domain *d, unsigned int gsi)
+{
+struct hvm_irq *hvm_irq = hvm_domain_irq(d);
+
+ASSERT(gsi < hvm_irq->nr_gsis);
+ASSERT(!has_vpic(d));
+spin_lock(>arch.hvm_domain.irq_lock);
+if ( !hvm_irq->gsi_assert_count[gsi] )
+{
+hvm_irq->gsi_assert_count[gsi]++;
+assert_gsi(d, gsi);
+}
+spin_unlock(>arch.hvm_domain.irq_lock);
+}
+
+void hvm_gsi_deassert(struct domain *d, unsigned int gsi)
+{
+struct hvm_irq *hvm_irq = hvm_domain_irq(d);
+
+ASSERT(gsi < hvm_irq->nr_gsis);
+ASSERT(!has_vpic(d));
+spin_lock(>arch.hvm_domain.irq_lock);
+if ( hvm_irq->gsi_assert_count[gsi] )
+hvm_irq->gsi_assert_count[gsi]--;
+ASSERT(!hvm_irq->gsi_assert_count[gsi]);
+spin_unlock(>arch.hvm_domain.irq_lock);
+}
+
 void hvm_isa_irq_assert(
 struct domain *d, unsigned int isa_irq)
 {
diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index e5a43e508f..1c89ae1642 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -164,6 +164,20 @@ static void pt_irq_time_out(void *data)
 
 spin_lock(_map->dom->event_lock);
 
+if ( irq_map->flags & HVM_IRQ_DPCI_IDENTITY_GSI )
+{
+struct pirq *pirq = dpci_pirq(irq_map);
+
+ASSERT(is_hardware_domain(irq_map->dom));
+/*
+ * Identity mapped, no need to iterate over the guest GSI list to find
+ * other pirqs sharing the same guest GSI.
+ */
+irq_map->flags |= HVM_IRQ_DPCI_EOI_LATCH;
+hvm_gsi_deassert(irq_map->dom, pirq->pirq);
+goto out;
+}
+
 dpci = domain_get_irq_dpci(irq_map->dom);
 if ( unlikely(!dpci) )
 {
@@ -185,6 +199,7 @@ static void pt_irq_time_out(void *data)
 hvm_pci_intx_deassert(irq_map->dom, digl->device, digl->intx);
 }
 
+ out:
 pt_pirq_iterate(irq_map->dom, pt_irq_guest_eoi, NULL);
 
 spin_unlock(_map->dom->event_lock);
@@ -274,10 +289,16 @@ int pt_irq_create_bind(
 spin_lock(>event_lock);
 
 hvm_irq_dpci = domain_get_irq_dpci(d);
-if ( hvm_irq_dpci == NULL )
+if ( hvm_irq_dpci == NULL && !is_hardware_domain(d) )
 {
 unsigned int i;
 
+/*
+ * NB: the hardware domain doesn't use a hvm_irq_dpci struct because
+ * it's only allowed to identity map GSIs, and so the data contained in
+ * that struct (used to map guest GSIs into machine GSIs and perform
+ * interrupt routing) it's completely useless for it.
+ */
 hvm_irq_dpci = xzalloc(struct hvm_irq_dpci);
 if ( hvm_irq_dpci == NULL )
 {
@@ -422,35 +443,51 @@ int pt_irq_create_bind(
 case PT_IRQ_TYPE_PCI:
 case PT_IRQ_TYPE_MSI_TRANSLATE:
 {
-unsigned int bus = pt_irq_bind->u.pci.bus;
-unsigned int device = pt_irq_bind->u.pci.device;
-unsigned int intx = pt_irq_bind->u.pci.intx;
-unsigned int guest_gsi = hvm_pci_intx_gsi(device, intx);
-unsigned int link = hvm_pci_intx_link(device, intx);
-struct dev_intx_gsi_link *digl = xmalloc(struct dev_intx_gsi_link);
-struct hvm_girq_dpci_mapping *girq =
-xmalloc(struct hvm_girq_dpci_mapping);
+struct dev_intx_gsi_link *digl = NULL;
+struct hvm_girq_dpci_mapping *girq = NULL;
+unsigned int guest_gsi;
 
-if ( !digl || !girq )
+/*
+ * Mapping GSIs 

[Xen-devel] [PATCH v2 1/3] x86/physdev: factor out the code to allocate and map a pirq

[Roger Pau Monne]

Move the code to allocate and map a domain pirq (either GSI or MSI) into the
x86 irq code base, so that it can be used outside of the physdev ops.

This change shouldn't affect the functionality of the already existing physdev
ops.

Signed-off-by: Roger Pau Monné 
---
Jan Beulich 
Andrew Cooper 
---
Changes since v1:
 - New in this version.
---
 xen/arch/x86/irq.c| 175 ++
 xen/arch/x86/physdev.c| 124 ++--
 xen/include/asm-x86/irq.h |   5 ++
 3 files changed, 185 insertions(+), 119 deletions(-)

diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 676ba5216f..8f6a91994c 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -2537,3 +2537,178 @@ bool_t hvm_domain_use_pirq(const struct domain *d, 
const struct pirq *pirq)
 return is_hvm_domain(d) && pirq &&
pirq->arch.hvm.emuirq != IRQ_UNBOUND; 
 }
+
+int allocate_and_map_gsi_pirq(struct domain *d, int *index, int *pirq_p)
+{
+int irq, pirq, ret;
+
+if ( *index < 0 || *index >= nr_irqs_gsi )
+{
+dprintk(XENLOG_G_ERR, "dom%d: map invalid irq %d\n", d->domain_id,
+*index);
+return -EINVAL;
+}
+
+irq = domain_pirq_to_irq(current->domain, *index);
+if ( irq <= 0 )
+{
+if ( is_hardware_domain(current->domain) )
+irq = *index;
+else {
+dprintk(XENLOG_G_ERR, "dom%d: map pirq with incorrect irq!\n",
+d->domain_id);
+return -EINVAL;
+}
+}
+
+pcidevs_lock();
+/* Verify or get pirq. */
+spin_lock(>event_lock);
+pirq = domain_irq_to_pirq(d, irq);
+
+if ( *pirq_p < 0 )
+{
+if ( pirq )
+{
+dprintk(XENLOG_G_ERR, "dom%d: %d:%d already mapped to %d\n",
+d->domain_id, *index, *pirq_p, pirq);
+if ( pirq < 0 )
+{
+ret = -EBUSY;
+goto done;
+}
+}
+else
+{
+pirq = get_free_pirq(d, MAP_PIRQ_TYPE_GSI);
+if ( pirq < 0 )
+{
+dprintk(XENLOG_G_ERR, "dom%d: no free pirq\n", d->domain_id);
+ret = pirq;
+goto done;
+}
+}
+}
+else
+{
+if ( pirq && pirq != *pirq_p )
+{
+dprintk(XENLOG_G_ERR, "dom%d: pirq %d conflicts with irq %d\n",
+d->domain_id, *index, *pirq_p);
+ret = -EEXIST;
+goto done;
+}
+else
+pirq = *pirq_p;
+}
+
+ret = map_domain_pirq(d, pirq, irq, MAP_PIRQ_TYPE_GSI, NULL);
+if ( ret == 0 )
+*pirq_p = pirq;
+
+ done:
+spin_unlock(>event_lock);
+pcidevs_unlock();
+return ret;
+}
+
+int allocate_and_map_msi_pirq(struct domain *d, int *index, int *pirq_p,
+  struct msi_info *msi)
+{
+int irq, pirq, ret, type;
+
+irq = *index;
+if ( irq == -1 || msi->entry_nr > 1 )
+irq = create_irq(NUMA_NO_NODE);
+
+if ( irq < nr_irqs_gsi || irq >= nr_irqs )
+{
+dprintk(XENLOG_G_ERR, "dom%d: can't create irq for msi!\n",
+d->domain_id);
+ret = -EINVAL;
+goto free_irq;
+}
+
+msi->irq = irq;
+type = (msi->entry_nr > 1 && !msi->table_base) ? MAP_PIRQ_TYPE_MULTI_MSI
+   : MAP_PIRQ_TYPE_MSI;
+
+pcidevs_lock();
+/* Verify or get pirq. */
+spin_lock(>event_lock);
+pirq = domain_irq_to_pirq(d, irq);
+if ( *pirq_p < 0 )
+{
+if ( pirq )
+{
+dprintk(XENLOG_G_ERR, "dom%d: %d:%d already mapped to %d\n",
+d->domain_id, *index, *pirq_p, pirq);
+if ( pirq < 0 )
+{
+ret = -EBUSY;
+goto done;
+}
+}
+else if ( msi->entry_nr > 1 && !msi->table_base )
+{
+if ( msi->entry_nr <= 0 || msi->entry_nr > 32 )
+ret = -EDOM;
+else if ( msi->entry_nr != 1 && !iommu_intremap )
+ret = -EOPNOTSUPP;
+else
+{
+while ( msi->entry_nr & (msi->entry_nr - 1) )
+msi->entry_nr += msi->entry_nr & -msi->entry_nr;
+pirq = get_free_pirqs(d, msi->entry_nr);
+ret = 0;
+if ( pirq < 0 )
+{
+while ( (msi->entry_nr >>= 1) > 1 )
+if ( get_free_pirqs(d, msi->entry_nr) > 0 )
+break;
+dprintk(XENLOG_G_ERR, "dom%d: no block of %d free pirqs\n",
+d->domain_id, msi->entry_nr << 1);
+ret = pirq;
+}
+}
+if ( ret < 0 )
+goto done;
+}
+else
+  

Re: [Xen-devel] [PATCH v2 for-next v2 2/8] x86/mm: carve out create_grant_pv_mapping

[Jan Beulich]

>>> On 03.04.17 at 13:22,  wrote:
> @@ -4300,6 +4297,15 @@ int create_grant_host_mapping(uint64_t addr, unsigned 
> long frame,
>  return create_grant_va_mapping(addr, pte, current);
>  }
>  
> +int create_grant_host_mapping(uint64_t addr, unsigned long frame,
> +  unsigned int flags, unsigned int cache_flags)
> +{
> +if ( paging_mode_external(current->domain) )
> +return create_grant_p2m_mapping(addr, frame, flags, cache_flags);
> +
> +return create_grant_pv_mapping(addr, frame, flags, cache_flags);
> +}

I wonder whether this and its siblings wouldn't better become inline
functions.

Jan


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

[Xen-devel] [PATCH v2 0/3] x86/dpci: bind legacy PCI interrupts to PVHv2 Dom0

[Roger Pau Monne]

Hello,

The following patches allow binding bare-metal GSIs into a PVHv2 Dom0, by
snooping on the vIO APICs writes made by Dom0.

This new version has reduced the number of patches from 5 to 3, first two
patches introduce the necessary code to bind GSIs into a PVH Dom0, and patch 3
snoops on vIO APIC writes for unmask and binds the GSI to Dom0.

The series has been tested with a PVHv2 Dom0 on a box with 3 IO APICs,
although all devices are wired up into the first IO APIC sadly.

A branch with the changes can be found at:

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

Thanks, Roger.


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

[Xen-devel] [PATCH v2 3/3] x86/vioapic: bind interrupts to PVH Dom0

[Roger Pau Monne]

Add the glue in order to bind the PVH Dom0 GSI from bare metal. This is done
when Dom0 unmasks the vIO APIC pins, by fetching the current pin settings and
setting up the PIRQ, which will then be bound to Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v1:
 - Mask the pin on error (instead of panicking).
 - Factor out the Dom0 specific code into a function.
 - Use the newly introduced allocate_and_map_gsi_pirq instead of
   physdev_map_pirq.
---
 xen/arch/x86/hvm/vioapic.c | 70 ++
 1 file changed, 70 insertions(+)

diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
index abcc473c88..4544e11abe 100644
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -158,6 +158,62 @@ static int vioapic_read(
 return X86EMUL_OKAY;
 }
 
+static int vioapic_dom0_map_gsi(unsigned int gsi, unsigned int trig,
+unsigned int pol)
+{
+struct domain *d = current->domain;
+xen_domctl_bind_pt_irq_t pt_irq_bind = {
+.irq_type = PT_IRQ_TYPE_PCI,
+.machine_irq = gsi,
+.hvm_domid = DOMID_SELF,
+};
+int ret, pirq = gsi;
+
+ASSERT(is_hardware_domain(d));
+
+/* Interrupt has been unmasked, bind it now. */
+ret = mp_register_gsi(gsi, trig, pol);
+if ( ret && ret != -EEXIST )
+{
+gdprintk(XENLOG_WARNING, "vioapic: error registering GSI %u: %d\n",
+ gsi, ret);
+goto error;
+}
+else if ( ret )
+/* Already in use. */
+return 0;
+
+ret = allocate_and_map_gsi_pirq(d, , );
+if ( ret )
+{
+gdprintk(XENLOG_WARNING, "vioapic: error mapping GSI %u: %d\n",
+ gsi, ret);
+goto error;
+}
+
+pcidevs_lock();
+ret = pt_irq_create_bind(d, _irq_bind);
+pcidevs_unlock();
+if ( ret )
+{
+gdprintk(XENLOG_WARNING, "vioapic: error binding GSI %u: %d\n",
+ gsi, ret);
+goto error_unmap;
+}
+
+return 0;
+
+ error_unmap:
+pcidevs_lock();
+spin_lock(>event_lock);
+unmap_domain_pirq(d, pirq);
+spin_unlock(>event_lock);
+pcidevs_unlock();
+ error:
+ASSERT(ret);
+return ret;
+}
+
 static void vioapic_write_redirent(
 struct hvm_vioapic *vioapic, unsigned int idx,
 int top_word, uint32_t val)
@@ -188,6 +244,20 @@ static void vioapic_write_redirent(
 unmasked = unmasked && !ent.fields.mask;
 }
 
+if ( is_hardware_domain(d) && unmasked )
+{
+int ret;
+
+ret = vioapic_dom0_map_gsi(gsi, ent.fields.trig_mode,
+   ent.fields.polarity);
+if ( ret )
+{
+/* Mask the entry again. */
+ent.fields.mask = 1;
+unmasked = 0;
+}
+}
+
 *pent = ent;
 
 if ( gsi == 0 )
-- 
2.11.0 (Apple Git-81)


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

Re: [Xen-devel] [PATCH v2 for-next v2 1/8] mm: provide more grep fodders

[Jan Beulich]

>>> On 03.04.17 at 13:22,  wrote:
> Define several _* and *_x macros for better grep-ability. This also
> helps indexing tool like GNU Global.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Jan Beulich]

>>> On 19.04.17 at 09:41,  wrote:
> On Wed, Apr 19, 2017 at 08:17:14AM -0600, Jan Beulich wrote:
> On 19.04.17 at 08:40,  wrote:
>>> @@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic)
>>>  }
>>>  vlapic_set_reg(vlapic, APIC_ICR, 0);
>>>  vlapic_set_reg(vlapic, APIC_ICR2,0);
>>> -vlapic_set_reg(vlapic, APIC_LDR, 0);
>>> +/*
>>> + * LDR is read-only in x2APIC mode. Preserve its value when handling
>>> + * INIT signal in x2APIC mode.
>>> + */
>>> +if ( !vlapic_x2apic_mode(vlapic) )
>>
>>In order for this to work you need to ...
>>
>>> +vlapic_set_reg(vlapic, APIC_LDR, 0);
>>>  vlapic_set_reg(vlapic, APIC_TASKPRI, 0);
>>>  vlapic_set_reg(vlapic, APIC_TMICT,   0);
>>>  vlapic_set_reg(vlapic, APIC_TMCCT,   0);
>>> @@ -1275,6 +1280,22 @@ void vlapic_reset(struct vlapic *vlapic)
>>>  destroy_periodic_time(>pt);
>>>  }
>>>  
>>> +/* Reset the VLAPIC back to its power-on/reset state. */
>>> +void vlapic_reset(struct vlapic *vlapic)
>>> +{
>>> +const struct vcpu *v = vlapic_vcpu(vlapic);
>>> +
>>> +if ( !has_vlapic(v->domain) )
>>> +return;
>>> +
>>> +vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
>>> +vlapic_set_reg(vlapic, APIC_LDR, 0);
>>> +vlapic_do_init(vlapic);
>>> +
>>> +vlapic->hw.apic_base_msr &= ~(uint64_t)MSR_IA32_APICBASE_EXTD;
>>
>>... do this before calling vlapic_do_init() afaict (and I see no strong
>>reason why you would need a cast here)). Likely it is a good idea
>>then to also ...
> 
> Got it and will fix. The APIC_LDR is also cleared in vlapic_reset.
> Do you mean it will do a cast automatically? I don't know that before.
> I was afraid that the higher qword of ~MSR_IA32_APICBASE_EXTD will is 
> zero.

Depends on whether the value is signed (in which case it will be
sign extended) or unsigned (resulting in zero-extension). The
constant in this case is signed, so the high bits wouldn't be unduly
chopped off.

Jan


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

Re: [Xen-devel] [PATCH v4] ns16550: Add support for UART parameters to be specifed with name-value pairs

[Jan Beulich]

>>> On 18.04.17 at 18:07,  wrote:
> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -38,11 +38,28 @@
>   * can be specified in place of a numeric baud rate. Polled mode is specified
>   * by requesting irq 0.
>   */
> -static char __initdata opt_com1[30] = "";
> -static char __initdata opt_com2[30] = "";
> +static char __initdata opt_com1[128] = "";
> +static char __initdata opt_com2[128] = "";
>  string_param("com1", opt_com1);
>  string_param("com2", opt_com2);
>  
> +typedef enum e_serial_param_type {
> +baud,
> +bridge_bdf,
> +clock_hz,
> +data_bits,
> +device,
> +io_base,
> +irq,
> +parity,
> +port_bdf,
> +reg_shift,
> +reg_width,
> +stop_bits,
> +/* list all parameters before this line */
> +max_serial_params

Bad name: If "max", it should be "max_serial_param" and equal the
highest valid one. Otherwise you mean "num_serial_params". Also
no need for a typedef here.

> @@ -77,6 +94,31 @@ static struct ns16550 {
>  #endif
>  } ns16550_com[2] = { { 0 } };
>  
> +struct serial_param_var
> +{
> +const char *sp_name;

I think you would save storage (and even more so runtime one) if
you used name[12] here.

> +serial_param_type sp_type;

For both of them, not need for a K (or even older) style "sp_"
prefix.

> +static bool __init parse_positional(struct ns16550 *uart, char **str)
>  {
>  int baud;
> +const char *conf;
> +char *name_val_pos;
>  
> -/* No user-specified configuration? */
> -if ( (conf == NULL) || (*conf == '\0') )
> +conf = *str;
> +name_val_pos = strchr(conf, '=');
> +
> +/* finding the end of the positional parameters */
> +if ( name_val_pos )

Is this really needed? The while() below looks to be sufficient.

>  {
> -/* Some platforms may automatically probe the UART configuartion. */
> -if ( uart->baud != 0 )
> -goto config_parsed;
> -return;
> +while (name_val_pos > *str)

Coding style (more elsewhere - please take the time and look over
your patch yourself to eliminate all such issues).

> +static bool __init parse_namevalue_pairs(char *str, struct ns16550 *uart)
> +{
> +char *token, *start = str;
> +char param_value[16];
> +bool dev_set = false;
> +
> +if ( (str == NULL) || (*str == '\0') )
> +return true;
> +
> +/* strsep gives NULL when there are no tokens found */
> +do
> +{
> +/* when no tokens are found, start will be NULL */
> +token = strsep(, ",");
> +
> +switch( get_token(token, param_value) ) {
> +case baud:
> +uart->baud = simple_strtoul(param_value, NULL, 0);
> +break;
> +case bridge_bdf:

Please have blank lines between non-fall-through case blocks.

> +if ( !parse_pci(param_value, NULL, >ps_bdf[0],

Indentation.

> +>ps_bdf[1], >ps_bdf[2]))
> +PARSE_ERR_RET("Bad port PCI coordinates\n");
> +uart->ps_bdf_enable = 1;
> +break;
> +case clock_hz:
> +uart->clock_hz = (simple_strtoul(param_value, NULL, 0) << 4);
> +break;
> +case device:
> +if ( strncmp(param_value, "pci", 3) == 0 )
> +{
> +pci_uart_config(uart, 1/* skip AMT */, uart - ns16550_com);
> +dev_set = true;
> +}
> +else if ( strncmp(param_value, "amt", 3) == 0 )
> +{
> +pci_uart_config(uart, 0, uart - ns16550_com);
> +dev_set = true;
> +}
> +break;
> +case io_base:
> +if ( dev_set == true )

Pointless comparison of a bool value with "true".

> +static void __init ns16550_parse_port_config(
> +struct ns16550 *uart, const char *conf)
> +{
> +char cmdline[128];

Please don't use misleading variable names - this isn't intended to hold
an entire command line.

Jan

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

[Xen-devel] [xen-unstable-smoke test] 107540: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  5d1ad47ff7940d95c322667678a190c8607754b4
baseline version:
 xen  828aa3352f97b613bd06daf7eb1ae734262196be

Last test of basis   107527  2017-04-18 17:01:55 Z0 days
Testing same since   107540  2017-04-19 12:02:20 Z0 days1 attempts


People who touched revisions under test:
  Chao Gao 
  Jan Beulich 
  Razvan Cojocaru 
  Roger Pau Monné 

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



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

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

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

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


Pushing revision :

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

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 qemuuca55019dacb821cc675273237a5173fc67bf3230
baseline version:
 qemuu9c6b899f7a46893ab3b671e341a2234e9c0c060e

Last test of basis   107501  2017-04-18 13:18:16 Z1 days
Testing same since   107531  2017-04-18 23:46:16 Z0 days1 attempts


People who touched revisions under test:
  Fam Zheng 
  Jeff Cody 
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v2] x86/vlapic: Don't reset APIC ID when handling INIT signal

[Chao Gao]

On Wed, Apr 19, 2017 at 08:17:14AM -0600, Jan Beulich wrote:
 On 19.04.17 at 08:40,  wrote:
>> @@ -1257,7 +1257,12 @@ void vlapic_reset(struct vlapic *vlapic)
>>  }
>>  vlapic_set_reg(vlapic, APIC_ICR, 0);
>>  vlapic_set_reg(vlapic, APIC_ICR2,0);
>> -vlapic_set_reg(vlapic, APIC_LDR, 0);
>> +/*
>> + * LDR is read-only in x2APIC mode. Preserve its value when handling
>> + * INIT signal in x2APIC mode.
>> + */
>> +if ( !vlapic_x2apic_mode(vlapic) )
>
>In order for this to work you need to ...
>
>> +vlapic_set_reg(vlapic, APIC_LDR, 0);
>>  vlapic_set_reg(vlapic, APIC_TASKPRI, 0);
>>  vlapic_set_reg(vlapic, APIC_TMICT,   0);
>>  vlapic_set_reg(vlapic, APIC_TMCCT,   0);
>> @@ -1275,6 +1280,22 @@ void vlapic_reset(struct vlapic *vlapic)
>>  destroy_periodic_time(>pt);
>>  }
>>  
>> +/* Reset the VLAPIC back to its power-on/reset state. */
>> +void vlapic_reset(struct vlapic *vlapic)
>> +{
>> +const struct vcpu *v = vlapic_vcpu(vlapic);
>> +
>> +if ( !has_vlapic(v->domain) )
>> +return;
>> +
>> +vlapic_set_reg(vlapic, APIC_ID, (v->vcpu_id * 2) << 24);
>> +vlapic_set_reg(vlapic, APIC_LDR, 0);
>> +vlapic_do_init(vlapic);
>> +
>> +vlapic->hw.apic_base_msr &= ~(uint64_t)MSR_IA32_APICBASE_EXTD;
>
>... do this before calling vlapic_do_init() afaict (and I see no strong
>reason why you would need a cast here)). Likely it is a good idea
>then to also ...

Got it and will fix. The APIC_LDR is also cleared in vlapic_reset.
Do you mean it will do a cast automatically? I don't know that before.
I was afraid that the higher qword of ~MSR_IA32_APICBASE_EXTD will is 
zero.

>
>> +vlapic->hw.apic_base_msr |= MSR_IA32_APICBASE_ENABLE;
>
>... do this up front.
>
>> @@ -1489,8 +1510,7 @@ int vlapic_init(struct vcpu *v)
>>  
>>  vlapic_reset(vlapic);
>>  
>> -vlapic->hw.apic_base_msr = (MSR_IA32_APICBASE_ENABLE |
>> -APIC_DEFAULT_PHYS_BASE);
>> +vlapic->hw.apic_base_msr |= APIC_DEFAULT_PHYS_BASE;
>
>Perhaps better move this ahead of the call to vlapic_reset() then
>too.
>
>Remains the question (not answered by the SDM afaics): What
>happens to the base address during reset?

Actually, I don't know and that's also why I don't touch apic_base_msr in the
first verson. Will try to get a confirmation from hardware guys.

Thanks
Chao

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

Re: [Xen-devel] about fully UMIP support in Xen

[Andrew Cooper]

On 19/04/17 15:27, Jan Beulich wrote:
 On 19.04.17 at 16:17,  wrote:
>> On 19/04/17 15:06, Jan Beulich wrote:
>> On 19.04.17 at 15:49,  wrote:
 If a PV kernel is aware of UMIP and turns UMIP on, #GPs from userspace
 should be bounced to the kernel, and #GPs from kernel space (as it is
 ring-deprivileged) must be emulated and execute successfully.

 If Xen is using UMIP to protect itself, it needs to emulate and fake up
 the information to both guest userspace and kernelspace.

 If both Xen and the PV kernel turn on UMIP, Xen needs to bounce
 userspace #GPs to the guest kernel, and fake up information for the
 guest kernel.
>>> I disagree in one point: If the guest kernel enabled UMIP, it being
>>> PV it should take care not to execute any of the covered insns (it
>>> has no use for them anyway). I see no reason to emulate anything
>>> in that case - emulation is needed only to keep _unaware_
>>> environments working.
>> That will involve someone ensuring that new PVops get introduced and used.
>>
>> Amongst other things, the current Linux doublefault handler uses sgdt.
> But a PV guest would never get to see a #DF.

It currently doesn’t, but that is a mishap of the current PV ABI
behaviour.  A PV guest *should* see things like #NP for missing entries
in its virtual IDT or non-present segments, rather than the current
domain_crash() it gets, and with that comes the expectation of faults
combining to inject #DF.

~Andrew

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