Re: [Xen-devel] [PATCH] xen: Add RING_COPY_RESPONSE()

[Oleksandr Andrushchenko]

On 05/01/2018 12:54 AM, Marek Marczykowski-Górecki wrote:

Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
(i.e., by not considering that the other end may alter the data in the
shared ring while it is being inspected).  Safe usage of a response
generally requires taking a local copy.

I do not agree with that. Copying still doesn't make all the above safe
as nothing prevents the backend from overwriting the response while
frontend makes its local copy.



Provide a RING_COPY_RESPONSE() macro to use instead of
RING_GET_RESPONSE() and an open-coded memcpy().  This takes care of
ensuring that the copy is done correctly regardless of any possible
compiler optimizations.

Use a volatile source to prevent the compiler from reordering or
omitting the copy.

This is complementary to XSA155.

Signed-off-by: Marek Marczykowski-Górecki 
---
  xen/include/public/io/ring.h | 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/xen/include/public/io/ring.h b/xen/include/public/io/ring.h
index 30342fc8c0..230fc34cba 100644
--- a/xen/include/public/io/ring.h
+++ b/xen/include/public/io/ring.h
@@ -227,22 +227,25 @@ typedef struct __name##_back_ring __name##_back_ring_t
  #define RING_GET_REQUEST(_r, _idx)  \
  (&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].req))
  
+#define RING_GET_RESPONSE(_r, _idx) \

+(&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp))
+
  /*
- * Get a local copy of a request.
+ * Get a local copy of a request/response.
   *
- * Use this in preference to RING_GET_REQUEST() so all processing is
- * done on a local copy that cannot be modified by the other end.
+ * Use this in preference to RING_GET_REQUEST()/RING_GET_RESPONSE() so all
+ * processing is done on a local copy that cannot be modified by the other end.
   *
   * Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 may cause this
   * to be ineffective where _req is a struct which consists of only bitfields.
   */
-#define RING_COPY_REQUEST(_r, _idx, _req) do { \
+#define RING_COPY_(action, _r, _idx, _req) do {
\
/* Use volatile to force the copy into _req. */ \
-   *(_req) = *(volatile typeof(_req))RING_GET_REQUEST(_r, _idx);   \
+   *(_req) = *(volatile typeof(_req))RING_GET_##action(_r, _idx);  \
  } while (0)
  
-#define RING_GET_RESPONSE(_r, _idx) \

-(&((_r)->sring->ring[((_idx) & (RING_SIZE(_r) - 1))].rsp))
+#define RING_COPY_REQUEST(_r, _idx, _req) RING_COPY_(REQUEST, _r, _idx, _req)
+#define RING_COPY_RESPONSE(_r, _idx, _req) RING_COPY_(RESPONSE, _r, _idx, _req)
  
  /* Loop termination condition: Would the specified index overflow the ring? */

  #define RING_REQUEST_CONS_OVERFLOW(_r, _cons)   \



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

[Xen-devel] [linux-3.18 baseline-only test] 74655: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install  fail blocked in 74619
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail blocked in 74619
 test-armhf-armhf-libvirt14 saverestore-support-check fail blocked in 74619
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 74619
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1   fail blocked in 74619
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 74619
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 74619
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail blocked in 74619
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 74619
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux754ca08efd83eeb9cccdb109da2fa0b3a27c1172
baseline version:
 linux78db2bbfa06cc39707054093fbbc5e573a643d3e

Last test of basis74619  2018-04-15 05:19:59 Z   16 days
Testing same since74655  2018-05-01 03:24:31 Z1 days1 attempts


People who touched revisions under test:
  Aaron Ma 
  Al Viro 
  Alex Deucher 
  Alex Smith 
  Alexander Aring 
  Alexandre Belloni 
  Amir Goldstein 
  Andrew Morton 
  Arnaldo Carvalho de Melo 
  Artem Bityutskiy 
  Bin Liu 
  Bjorn Helgaas 
  Boris Brezillon 
  Christian König 
  Chunming Zhou 
  Cong Wang 
  Dan Carpenter 
  David Ahern 
  David S. Miller 
  Dong Aisheng 
  

Re: [Xen-devel] [PATCH 2/6] xen-netfront: copy response out of shared buffer before accessing it

[Oleksandr Andrushchenko]

On 05/01/2018 12:01 AM, Marek Marczykowski-Górecki wrote:

Make local copy of the response, otherwise backend might modify it while
frontend is already processing it - leading to time of check / time of
use issue.

This is complementary to XSA155.

Cc: sta...@vger.kernel.org
Signed-off-by: Marek Marczykowski-Górecki 
---
  drivers/net/xen-netfront.c | 51 +++
  1 file changed, 25 insertions(+), 26 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 4dd0668..dc99763 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -387,13 +387,13 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue)
rmb(); /* Ensure we see responses up to 'rp'. */
  
  		for (cons = queue->tx.rsp_cons; cons != prod; cons++) {

Side comment: the original concern was expressed on the above counters,
will those be addressed as a dedicated series?

-   struct xen_netif_tx_response *txrsp;
+   struct xen_netif_tx_response txrsp;
  
-			txrsp = RING_GET_RESPONSE(>tx, cons);

-   if (txrsp->status == XEN_NETIF_RSP_NULL)
+   RING_COPY_RESPONSE(>tx, cons, );
+   if (txrsp.status == XEN_NETIF_RSP_NULL)
continue;
  
IMO, there is still no guarantee you access consistent data after this 
change.

What if part of the response was ok when you started copying and
then, in the middle, backend poisons the end of the response?
This seems to be just like minimizing(?) chances to work with inconsistent
data rather than removing the possibility of such completely

-   id  = txrsp->id;
+   id  = txrsp.id;
skb = queue->tx_skbs[id].skb;
if (unlikely(gnttab_query_foreign_access(
queue->grant_tx_ref[id]) != 0)) {
@@ -741,7 +741,7 @@ static int xennet_get_extras(struct netfront_queue *queue,
 RING_IDX rp)
  
  {

-   struct xen_netif_extra_info *extra;
+   struct xen_netif_extra_info extra;
struct device *dev = >info->netdev->dev;
RING_IDX cons = queue->rx.rsp_cons;
int err = 0;
@@ -757,24 +757,23 @@ static int xennet_get_extras(struct netfront_queue *queue,
break;
}
  
-		extra = (struct xen_netif_extra_info *)

-   RING_GET_RESPONSE(>rx, ++cons);
+   RING_COPY_RESPONSE(>rx, ++cons, );
  
-		if (unlikely(!extra->type ||

-extra->type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
+   if (unlikely(!extra.type ||
+extra.type >= XEN_NETIF_EXTRA_TYPE_MAX)) {
if (net_ratelimit())
dev_warn(dev, "Invalid extra type: %d\n",
-   extra->type);
+   extra.type);
err = -EINVAL;
} else {
-   memcpy([extra->type - 1], extra,
-  sizeof(*extra));
+   memcpy([extra.type - 1], ,
+  sizeof(extra));
}
  
  		skb = xennet_get_rx_skb(queue, cons);

ref = xennet_get_rx_ref(queue, cons);
xennet_move_rx_slot(queue, skb, ref);
-   } while (extra->flags & XEN_NETIF_EXTRA_FLAG_MORE);
+   } while (extra.flags & XEN_NETIF_EXTRA_FLAG_MORE);
  
  	queue->rx.rsp_cons = cons;

return err;
@@ -784,28 +783,28 @@ static int xennet_get_responses(struct netfront_queue 
*queue,
struct netfront_rx_info *rinfo, RING_IDX rp,
struct sk_buff_head *list)
  {
-   struct xen_netif_rx_response *rx = >rx;
+   struct xen_netif_rx_response rx = rinfo->rx;
struct xen_netif_extra_info *extras = rinfo->extras;
struct device *dev = >info->netdev->dev;
RING_IDX cons = queue->rx.rsp_cons;
struct sk_buff *skb = xennet_get_rx_skb(queue, cons);
grant_ref_t ref = xennet_get_rx_ref(queue, cons);
-   int max = MAX_SKB_FRAGS + (rx->status <= RX_COPY_THRESHOLD);
+   int max = MAX_SKB_FRAGS + (rx.status <= RX_COPY_THRESHOLD);
int slots = 1;
int err = 0;
unsigned long ret;
  
-	if (rx->flags & XEN_NETRXF_extra_info) {

+   if (rx.flags & XEN_NETRXF_extra_info) {
err = xennet_get_extras(queue, extras, rp);
cons = queue->rx.rsp_cons;
}
  
  	for (;;) {

-   if (unlikely(rx->status < 0 ||
-rx->offset + rx->status > XEN_PAGE_SIZE)) {
+   if (unlikely(rx.status < 0 ||
+rx.offset + rx.status > XEN_PAGE_SIZE)) {
if (net_ratelimit())
 

[Xen-devel] Patch "x86/xen: Add pvh specific rsdp address retrieval function" has been added to the 4.16-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

x86/xen: Add pvh specific rsdp address retrieval function

to the 4.16-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 x86-xen-add-pvh-specific-rsdp-address-retrieval-function.patch
and it can be found in the queue-4.16 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


From foo@baz Tue May  1 14:59:18 PDT 2018
From: Juergen Gross 
Date: Mon, 19 Feb 2018 11:09:06 +0100
Subject: x86/xen: Add pvh specific rsdp address retrieval function

From: Juergen Gross 

[ Upstream commit b17d9d1df3c33a4f1d2bf397e2257aecf9dc56d4 ]

Add pvh_get_root_pointer() for Xen PVH guests to communicate the
address of the RSDP table given to the kernel via Xen start info.

This makes the kernel boot again in PVH mode after on recent Xen the
RSDP was moved to higher addresses. So up to that change it was pure
luck that the legacy method to locate the RSDP was working when
running as PVH mode.

Signed-off-by: Juergen Gross 
Reviewed-by: Andy Shevchenko 
Acked-by: Thomas Gleixner 
Acked-by: Rafael J. Wysocki 
Cc: Borislav Petkov 
Cc: Eric Biederman 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Kirill A. Shutemov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: boris.ostrov...@oracle.com
Cc: l...@kernel.org
Cc: linux-a...@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20180219100906.14265-4-jgr...@suse.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/x86/xen/enlighten_pvh.c |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -16,15 +17,20 @@
 /*
  * PVH variables.
  *
- * xen_pvh and pvh_bootparams need to live in data segment since they
- * are used after startup_{32|64}, which clear .bss, are invoked.
+ * xen_pvh pvh_bootparams and pvh_start_info need to live in data segment
+ * since they are used after startup_{32|64}, which clear .bss, are invoked.
  */
 bool xen_pvh __attribute__((section(".data"))) = 0;
 struct boot_params pvh_bootparams __attribute__((section(".data")));
+struct hvm_start_info pvh_start_info __attribute__((section(".data")));
 
-struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
+static u64 pvh_get_root_pointer(void)
+{
+   return pvh_start_info.rsdp_paddr;
+}
+
 static void __init init_pvh_bootparams(void)
 {
struct xen_memory_map memmap;
@@ -71,6 +77,8 @@ static void __init init_pvh_bootparams(v
 */
pvh_bootparams.hdr.version = 0x212;
pvh_bootparams.hdr.type_of_loader = (9 << 4) | 0; /* Xen loader */
+
+   x86_init.acpi.get_root_pointer = pvh_get_root_pointer;
 }
 
 /*


Patches currently in stable-queue which might be from jgr...@suse.com are

queue-4.16/x86-xen-add-pvh-specific-rsdp-address-retrieval-function.patch
queue-4.16/x86-mm-do-not-forbid-_page_rw-before-init-for-__ro_after_init.patch
queue-4.16/xen-acpi-off-by-one-in-read_acpi_id.patch
queue-4.16/x86-pgtable-don-t-set-huge-pud-pmd-on-non-leaf-entries.patch

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

[Xen-devel] [xen-4.9-testing baseline-only test] 74654: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74654 xen-4.9-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74654/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install  fail baseline untested
 test-armhf-armhf-libvirt-xsm 12 guest-start fail baseline untested
 test-armhf-armhf-xl-midway   12 guest-start fail baseline untested
 test-armhf-armhf-libvirt 12 guest-start fail baseline untested
 test-armhf-armhf-xl-credit2  12 guest-start fail baseline untested
 test-armhf-armhf-xl-xsm  12 guest-start fail baseline untested
 test-armhf-armhf-xl-multivcpu 12 guest-startfail baseline untested
 test-armhf-armhf-xl  12 guest-start fail baseline untested
 test-armhf-armhf-xl-rtds 12 guest-start fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1  fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail baseline 
untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail baseline 
untested
 test-armhf-armhf-xl-vhd  10 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw 10 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win10-i386 17 guest-stop  fail baseline untested
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  7866e115f9c624b0669997fcc393b489ef3c38a2
baseline version:
 xen  ad4fefdd088e47dcc017efefc4857e1610c832af

Last test of basis74491  2018-04-05 12:25:22 Z   26 days
Testing same since74654  2018-04-30 22:16:54 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f9dff90289507191f299331e44601c5ef83c1948
baseline version:
 ovmf 78e759910c8d3627f8ba6a0412b85f0868c1b203

Last test of basis   122482  2018-04-27 21:11:44 Z3 days
Testing same since   122532  2018-04-30 09:40:04 Z1 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   78e759910c..f9dff90289  f9dff90289507191f299331e44601c5ef83c1948 -> 
xen-tested-master

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

Re: [Xen-devel] 4.11.0 RC1 panic

[Manuel Bouyer]

On Mon, Apr 30, 2018 at 07:31:28AM -0600, Jan Beulich wrote:
> >>> On 25.04.18 at 16:42,  wrote:
> > On Wed, Apr 25, 2018 at 12:42:42PM +0200, Manuel Bouyer wrote:
> >> > Without line numbers associated with at least the top stack trace entry
> >> > I can only guess what it might be - could you give the patch below a try?
> >> > (This may not be the final patch, as I'm afraid there may be some race
> >> > here, but I'd have to work this out later.)
> >> 
> >> Yes, this works. thanks !
> >> I'll now put this version on the NetBSD testbed I'm running.
> >> This should put some pressure on it.
> > 
> > Running NetBSD tests in several guests I got:
> > (XEN) 
> > (XEN) 
> > (XEN) Panic on CPU 1:
> > (XEN) Assertion 'oc > 0' failed at mm.c:628
> > (XEN) 
> > (see attached file for complete report).
> 
> So in combination with your later reply I'm confused: Are you observing
> this with 64-bit guests as well (your later reply appears to hint towards
> 64-bit-ness), or (as the stack trace suggests) only 32-bit ones? Knowing
> this may already narrow areas where to look.

I've seen it a server where, I think, only 32bits domUs are running.
But the dom0 is a 64bits NetBSD anyway.


-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

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

Re: [Xen-devel] [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
>  Maybe the best way to approach this is
> to have two options that control how CCs are inserted into the cover
> letter and a separate one that controls how CCs are inserted into
> patches.

I don't mind the options.  I think I care about the default, which I
think should be to include all CCs in both bodies and headers.

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

On 01/05/2018, 16:16, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
> In the cover letter, the tool always insert at the top as it is a 
transient
> thing that does not end up in git.
> 
> On 01/05/2018, 13:52, "Ian Jackson"  wrote:
>
> As an aside, I guess with `-i ccbody' your tool still puts the CCs in
> the mail headers of the cover letter ?  Or will git-send-email do 
that ?
> 
> git-send-email does that.

These replies seem to be contradictory.

That's because I mis-read the question. So the correct answer is:
the tool does that. But it does this regardless of -i *

Also, IIRC someone wrote earlier in the thread that they prefer the
practice of including CCs in the body of the cover letter too.  So
assuming that the first reply is accurate, it may not be desirable.

That can be done easily. Maybe the best way to approach this is
to have two options that control how CCs are inserted into the cover
letter and a separate one that controls how CCs are inserted into
patches.

In that case I would probably rename 
--insert | -i to --insert-patch | -p with top, ccbody, none as admissible values
and
--insert-cover | -c with top, ccbody, none as admissible values


Cheers
Lars


In 

Lars
 

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

Re: [Xen-devel] Should PV frontend drivers trust the backends?

[Paul Durrant]

> -Original Message-
[snip]
> > So what happens if the backend servicing the VM's boot disk fails? Is it
> better to:
> >
> > a) BUG()/BSOD with some meaningful stack and code such that it's obvious
> that happened, so
> > b) cover up and wait until something further up the storage stack crashes
> the VM, probably with some error that's just a generic timeout
> >
> > I'm clearly advocating a) but it's possible b) may be more desirable in some
> scenarios. I think the choice is up to whoever is writing the frontend and no-
> one else should decide their policy for them.
> 
> But you know, BUG() isn't the only method for getting error message.
> I see in this thread proper logging is used as an excuse for crashing
> things - really, this is very poor excuse. You can use printk, or even
> WARN() or such.

On Windows? I think not.

> And if there are cases where the only way to get
> meaningful messages is crashing the whole thing, somethings is _really_
> wrong.

Forcing a BSOD really is sometime the best option on Windows.

> In many cases crashing the thing will actually make retrieving messages
> harder, not easier (remote systems, console not working etc).
> 

Again, forcing a BSOD in Windows can resulting in a meaningful crashdump that 
can take you straight to a diagnosis of the problem. Fixing things up and 
getting some form of arbitrary 'page in timeout' BSOD a couple of minutes later 
can make post mortem diagnosis a lot harder.

> > > > > > And, if my assumption is correct, we still do trust the contents of 
> > > > > > the
> > > > > > requests
> > > > > > and responses, e.g. the payload is still trusted.
> > > > > Why should the payload be any more trusted than the content of the
> > > shared ring? They are both shared with the backend and therefore can
> be
> > > corrupted to the same extent.
> > > > This is exactly my point: if we only try to protect from inconsistent
> > > > prod/cons then
> > > > this protection is still incomplete as the payload may be the source of
> > > > failure.
> > >
> > > Well, you can take extra measures, external to the driver, to
> > > protect against malicious payload (like encryption mentioned by Andrew,
> > > or dm-verity for block devices). But you can't do the same about the
> > > driver itself (ring handling etc).
> > >
> >
> > As I said, verification should be down to the layer that has the relevant
> information.
> >
> > > Of course backend will be able to perform a DoS to some extend in all
> > > the cases, at least by stopping responding to requests. But keep in mind
> > > that root fs is not the only device out there. There are also other
> > > block device, network interfaces etc. And misbehaving backend should
> > > _not_ be able to take over frontend domain in those cases. And ideally
> > > also shouldn't also be able to crash it (if device isn't critical for
> > > domU).
> > >
> >
> > I still think that is the choice of the frontend. Yes, they can be 
> > programmed
> defensively but for some usecases it may just not be that important.
> >
> > > If you want some real world use cases for this, here are two from Qubes
> > > OS:
> > >
> > > 1. Block devices - base system devices (/, /home equivalent etc) have
> > > backends in dom0 (*), but there is also an option to use block devices
> > > exported by other domains. For example the one handling USB
> controllers.
> > > So, when you plug USB stick, one domain handle all the USB nasty stuff,
> > > and export it as a plain device to another domain when user can mount
> > > LUKS container stored there. Whatever happens there, nothing from that
> > > USB stick touches dom0 at any time.
> > >
> > > 2. Network devices - there are no network backends in dom0 at all. There
> > > is one (or more) dedicated domain for handling NICs, then there is
> > > (possibly a tree of) domain(s) routing the traffic. In some cases a VM
> > > facing actual network (where the backend runs) is considered less
> > > trusted than a VM using that network (where the frontend runs).
> >
> > But, without revocable grants that backend could still DoS the frontend,
> right?
> 
> Yes, but in that case it should be enough to kill the backend (domain)
> and frontend domain should be good, right?
> What I mean, malicious/buggy backend should be able to do harm only to
> devices it controls. Not crashing the whole driver (affecting all
> devices of that kind), or the whole system.
> 
> And definitely arbitrary code execution or info leak also should not be
> possible. I hope we agree at least to this point, right?

It's a good idea to defend against it...

> 
> Of course this all is about what the driver itself. If upper layer is about
> to execute any payload it gets, then PV driver can do nothing about it.

...but as you point out here, it will likely always be possible at some level.

  Paul

> But as you've said, it should be up to the frontend [domain configuration].
> 
> > > BTW Since XSA-155 we do have some additional patches 

[Xen-devel] x86 Community Call - Wed May 9, 14:00 - 15:00 UTC - Call for agenda items

[Lars Kurth]

Hi all,

please find attached
a) Meeting details (just a link with timezones) – the meeting invite will 
follow when we have an agenda
    Gotomeeting, phone bridge details and slack channel will be sent with the 
meeting invite

== Meeting Details ==
Wed May 9, 14:00 - 15:00 UTC
Wed May 9, 15:00 - 16:00 BST (London)
Wed May 9, 16:00 - 17:00 CEST (Berlin)

Further International meeting times: 
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2018=5=9=14=0=0=224=24=179=136=37=33

b) Call for agenda items

The meeting minutes of the last call are at 
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg00857.html and 
https://docs.google.com/document/d/1oFfS9XB2i2T_p89kQ6fGTZIfu60qDJXPRtoyPs7fPOk/edit#heading=h.whkmnl81x2pf

Are there any new items to discuss?

In the tracking/action section, the following items probably need to be covered 
briefly. I am listing these below.
If things are progressing and need no further discussion, please let me know by 
Monday and I will just add a note
to the agenda/minutes. That would provide an opportunity to discuss other issues

Please search for your name with an @ before.

== AOB
ACTION (April - DONE): George to send list of phone numbers to Lars
ACTION (April - DONE): Lars to include list of phone numbers in invite
ACTION (April - DONE): Lars to include slack channel in invite

== [RFC XEN PATCH v4 00/41] Add vNVDIMM support to HVM domains
There are a few action's outstanding.
@George, @Royger: Please let me know whether we need further discussion or 
whether this is in hand/has not progressed.

== [PATCH RFC 00/10] x86 passthrough code cleanup
ACTION (April - DONE): Brian Wood to ping Suravee Suthikulpanit (AMD) 
@Wei: Not sure whether Suravee has responded

ACTION (April - DONE): Lars to propose fixing CC issue in xen.git:MAINTAINERS 
copying the R section entries from Linux.git:
ACTION (April - DONE): Lars to have a back-channel discussion with AMD on how 
to solve this. 
For now, CC Brian

== [PATCH 0/7] paravirtual IOMMU interface
ACTION (March): Paul to resend the series with a clear problem statement. It 
may also make sense for Andy, Paul and George to sit together
@Paul: let me know whether you want this on the agenda

== [PATCH v4 0/4] x86/cpuid: enable new cpu features
The agreement was to park until patches arrive, which as far as I can tell have 
not
@John, @Yang: please let me know if there is any progress and whether thus this 
item should be put onto the agenda

== PVHv2 Status (Royger)
Update: At the AB meeting it was confirmed that Boris will not be working on 
PVHv2 Linux for a while
@Royger: Anything to add here?

== PCI Emulation - Future Direction (Royger, Stefano, Julien)
We have a call set up 
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01809.html
@Royger, @Paul: Not sure whether you want to give an update to the larger group

== Recently Un-blocked Series/un-blocked dependencies
According to the minutes, the following series should not be blocked anymore
* AMD AVIC Series
* [RFC Patch v4 0/8] Extend resources to support more vcpus in single VM
* [RFC PATCH 0/8] Add guest CPU topology support

== Blocked Series
Please go through the minutes and let me know, whether
a) Anything has been unblocked
b) You want to raise an item in the list for discussion

The list of which appeared to blocked on a dependency seem to be
== [PATCH RFC 00/14] EPT-Based Sub-page Write Protection Support (Zhang Yi)

== Longer Term / Blocked
=== [PATCH RESEND v1 0/7] Intel Processor Trace virtulization enabling
ACTION (April): Lars to talk Intel, George & Wei with a view of whether a 
design/discussion could 
be arranged at the summit and whether it makes sense. It will need some 
preparation by the reviewer 
though.
@John, @George, @Wei: Are there new developments?

=== [RFC PATCH v2 00/17] RFC: SGX Virtualization design and draft patches
ACTION (April): Lars to think about this, discuss with Intel (CC 
kai.hu...@intel.com). 
I have not done that yet: also, this week is a holiday in China.

== Longer Term / Agreed to pause
=== [PATCH v4 00/28] add vIOMMU support with irq remapping function of virtual 
VT-d
@John: let me know whether this is still paused. If so, I propose not to discuss

Regards
Lars


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

Re: [Xen-devel] [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
> In the cover letter, the tool always insert at the top as it is a transient
> thing that does not end up in git.
> 
> On 01/05/2018, 13:52, "Ian Jackson"  wrote:
>
> As an aside, I guess with `-i ccbody' your tool still puts the CCs in
> the mail headers of the cover letter ?  Or will git-send-email do that ?
> 
> git-send-email does that.

These replies seem to be contradictory.

Also, IIRC someone wrote earlier in the thread that they prefer the
practice of including CCs in the body of the cover letter too.  So
assuming that the first reply is accurate, it may not be desirable.

Ian.

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

Re: [Xen-devel] Should PV frontend drivers trust the backends?

['Marek Marczykowski-Górecki']

On Tue, May 01, 2018 at 07:55:39AM +, Paul Durrant wrote:
> > -Original Message-
> > From: Marek Marczykowski-Górecki
> > [mailto:marma...@invisiblethingslab.com]
> > Sent: 30 April 2018 18:33
> > To: Oleksandr Andrushchenko 
> > Cc: Paul Durrant ; 'Juergen Gross'
> > ; xen-devel 
> > Subject: Re: [Xen-devel] Should PV frontend drivers trust the backends?
> > 
> > On Thu, Apr 26, 2018 at 11:47:41AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/26/2018 11:16 AM, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com]
> > > > > Sent: 26 April 2018 07:00
> > > > > To: Paul Durrant ; 'Juergen Gross'
> > > > > ; xen-devel 
> > > > > Subject: Re: [Xen-devel] Should PV frontend drivers trust the
> > backends?
> > > > >
> > > > > On 04/25/2018 04:47 PM, Paul Durrant wrote:
> > > > > > > -Original Message-
> > > > > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org]
> > On
> > > > > Behalf
> > > > > > > Of Juergen Gross
> > > > > > > Sent: 25 April 2018 13:43
> > > > > > > To: xen-devel 
> > > > > > > Subject: [Xen-devel] Should PV frontend drivers trust the
> > backends?
> > > > > > >
> > > > > > > This is a followup of a discussion on IRC:
> > > > > > >
> > > > > > > The main question of the discussion was: "Should frontend drivers
> > > > > > > trust their backends not doing malicious actions?"
> > > > > > >
> > > > > > > This IMO includes:
> > > > > > >
> > > > > > > 1. The data put by the backend on the ring page(s) is sane and
> > > > > > >  consistent, meaning that e.g. the response producer index is
> > always
> > > > > > >  ahead of the consumer index.
> > > > > > >
> > > > > > > 2. Response data won't be modified by the backend after the
> > producer
> > > > > > >  index has been incremented signaling the response is valid.
> > > > > > >
> > > > > > > 3. Response data is sane, e.g. an I/O data length is not larger 
> > > > > > > than
> > > > > > >  the buffer originally was.
> > > > > > >
> > > > > > > 4. When a response has been sent all grants belonging to the
> > request
> > > > > > >  have been unmapped again by the backend, meaning that the
> > frontend
> > > > > > >  can assume the grants can be removed without conflict.
> > > > > > >
> > > > > > > Today most frontend drivers (at least in the Linux kernel) seem to
> > > > > > > assume all of the above is true (there are some exceptions, but
> > never
> > > > > > > for all items):
> > > > > > >
> > > > > > > - they don't check sanity of ring index values
> > > > > > > - they don't copy response data into local memory before looking 
> > > > > > > at
> > it
> > > > > > > - they don't verify returned data length (or do so via BUG_ON())
> > > > > > > - they BUG() in case of a conflict when trying to remove a grant
> > > > > > >
> > > > > > > So the basic question is: should all Linux frontend drivers be
> > modified
> > > > > > > in order to be able to tolerate buggy or malicious backends? Or is
> > the
> > > > > > > list of trust above fine?
> > > > > > >
> > > > > > > IMO even in case the frontends do trust the backends to behave
> > sane this
> > > > > > > doesn't mean driver domains don't make sense. Driver domains still
> > make
> > > > > > > a Xen host more robust as they e.g. protect the host against 
> > > > > > > driver
> > > > > > > failures normally leading to a crash of dom0.
> > > > > > >
> > > > > > I see the general question as being analogous to 'should a Linux
> > device
> > > > > driver trust its hardware' and I think the answer for a general 
> > > > > purpose
> > OS like
> > > > > linux is 'yes'.
> > > > > > Now, having worked on fault tolerant systems in a past life, there 
> > > > > > are
> > > > > definitely cases where you want your OS not to implicitly trust its
> > peripheral
> > > > > hardware and hence special device drivers are used.
> > > > > So what do you do if counters provided by the untrusted HW are ok
> > > > > and the payload is not?
> > > > Well, that depends on whether there is actually any way to verify the
> > payload in a driver. Whatever layer in the system is responsible for the 
> > data
> > needs to verify its integrity in a fault tolerant system. Generally the 
> > driver can
> > only attempt to verify that it's hardware is working as expect and quiesce 
> > it if
> > not. For that reason, in the systems I worked on, the driver had the 
> > ability to
> > control FETs that disconnected peripheral h/w from the PCI bus.
> > > >
> > > > > > I think the same would apply for virtual machines in situations 
> > > > > > where
> > a
> > > > > driver domain is not wholly controlled by a host administrator or is 
> > > > > not
> > > > > trusted to the same extent as dom0 for other 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  0306a1311d02ea52b4a9a9bc339f8bab9354c5e3
baseline version:
 xen  2bc87d85c0a1b1fc13ede98ebe059e5a6e84d535

Last test of basis   122543  2018-04-30 17:00:28 Z0 days
Testing same since   122553  2018-05-01 13:00:56 Z0 days1 attempts


People who touched revisions under test:
  Brian Woods 
  Ian Jackson 
  Lars Kurth 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   2bc87d85c0..0306a1311d  0306a1311d02ea52b4a9a9bc339f8bab9354c5e3 -> smoke

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

Re: [Xen-devel] [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

On 01/05/2018, 13:52, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
> On 30/04/2018, 17:21, "Ian Jackson"  wrote:
> 
> When I do this, there is nothing that gets the CC for the cover letter
> right.  (I sometimes bodge it.)  Your tool already knows how to
> extract CCs from the individual non-cover-letter patches and add them
> to the cover letter.  That is the function I want - to do that, but
> not run get_maintainer.
> 
> That makes sense and can be easily done via an option: e.g.
> --insert cover|-i cover or a separate option. Let me know whether
> you have a preference regarding naming/options.

I think this is orthogonal to -i.  That is, a user who wants your tool
to only edit the cover letter might want either to have it add the CCs
only to the mail header, or into the body as well.

Perhaps --transfer-only aka -T ?  Not sure I can think of a good name.

I can do either: in fact looking at the code -i only operates on files that
are not the cover letter. 

So:
-i top: adds CC's to each *.patch except the cover letter
-i ccbody: adds CC's to the body of each *.patch file except the cover letter

Thus
-i none: could just not add anything to each *.patch file except the
 cover letter

I think that is probably the most logical way to do this
I probably need to clarify the scope of -i in the help section

In the cover letter, the tool always insert at the top as it is a transient
thing that does not end up in git.

As an aside, I guess with `-i ccbody' your tool still puts the CCs in
the mail headers of the cover letter ?  Or will git-send-email do that ?

git-send-email does that. No need to add extra logic
I will add a comment into the tool's code

Lars


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-libvirt 10 debian-install   fail REGR. vs. 118324

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

version targeted for testing:
 linux6da6c0db5316275015e8cc2959f12a17584aeb64
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z   96 days
Failing since118362  2018-01-26 16:56:17 Z   94 days   76 attempts
Testing same since   122521  2018-04-29 22:17:09 Z1 days1 attempts


3401 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
 

[Xen-devel] [xen-4.8-testing baseline-only test] 74653: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74653 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74653/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-xsm  12 guest-start fail baseline untested
 test-armhf-armhf-libvirt-xsm 12 guest-start fail baseline untested
 test-armhf-armhf-libvirt 12 guest-start fail baseline untested
 test-armhf-armhf-xl  12 guest-start fail baseline untested
 test-armhf-armhf-xl-multivcpu 12 guest-startfail baseline untested
 test-armhf-armhf-xl-credit2  12 guest-start fail baseline untested
 test-armhf-armhf-xl-midway   12 guest-start fail baseline untested
 test-armhf-armhf-xl-rtds 12 guest-start fail baseline untested
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1  fail baseline untested
 test-armhf-armhf-xl-vhd  10 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemut-win10-i386 16 guest-localmigrate/x10 fail baseline 
untested
 test-armhf-armhf-libvirt-raw 10 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail baseline untested
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  1052a2168ed62999b35319a435c16da884f5f0e2
baseline version:
 xen  08647952260725344f4e67d2190c2c4c8457cea2

Last test of basis74594  2018-04-13 17:55:40 Z   17 days
Testing same since74653  2018-04-30 20:51:30 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Kevin Tian 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   

[Xen-devel] [libvirt test] 122527: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  ce5aebeacd10a1c15cb3ee46a59c8b5ff235589e
baseline version:
 libvirt  f94e5b215720c91c60219f1694783a603f0b619c

Last test of basis   122455  2018-04-26 18:27:32 Z4 days
Testing same since   122494  2018-04-28 10:26:55 Z3 days2 attempts


People who touched revisions under test:
  Christian Ehrhardt 
  Daniel P. Berrangé 
  Laine Stump 
  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-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 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   pass
 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
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test 

Re: [Xen-devel] where can I find the 'address translation' code in Xen?

[Minjun Hong]

On Mon, Apr 30, 2018 at 10:13 PM, Andrew Cooper 
wrote:

> On 29/04/18 11:11, Minjun Hong wrote:
> > Hi.
> > I'm looking for a point where address translation (guest virtual
> > address to machine address) occurs in Xen.
> > Of course, I mean when TLB miss has occured.
>
> This question makes me wonder whether you are more familiar with PowerPC
> than x86.  In x86, the TLB is automatically maintained by hardware, and
> new entries will be populated as necessary.  All pagetable related
> errors result in a pagefault exception, which Xen handles.
>
> > I'm using a PV guest and I've found 'guest_walk_tables()' function in
> > "xen/arch/x86/mm/guest_walk.c".
> > However, in the comment of the function, it says "Walk the guest
> > pagetables, after the manner of a hardware walker".
> > I'm confused because I'm not sure if the function is called after the
> > 'hardware page table walker'.
>
> "after the manner" is an uncommon phrase in English, which AFAICT
> derives from Latin originally.  It means "in the style of", "in the same
> way as", etc.
>
> guest_walk_tables() is a function which tries to match the behaviour of
> the hardware pagewalker.  However, it is only used for cases where we
> can't use regular hardware support, such as emulation of instructions.
>
> ~Andrew
>

Thank you, Andrew.
Your answer is very helpful for me.

It appears that there is no code to be executed when address translations
of the guest occurs in Xen.
Frankly, I was expecting there may be an address translation when accessing
guest memory, and I wanted to find the code used in Xen at that time.
Is there any code I can use for this purpose in Xen? No matter how I look,
I could not find it in Xen with my background knowledge right now. So that
I need your help.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Jason Cooper]

add the link to xen-users thread of me talking to myself.  :-))

On Tue, May 01, 2018 at 12:37:51PM +, Jason Cooper wrote:
> When I was first digging into this, I started a thread on xen-users [1],
> I've attached my xl-reboot.sh script here so you can see exactly what
> I'm attempting to do:

[1] https://marc.info/?l=xen-users=152389443206023=2


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

Re: [Xen-devel] [PATCH for-4.11 2/2] Replace http: with https: in MAINTAINERs file

[Ian Jackson]

Wei Liu writes ("Re: [PATCH for-4.11 2/2] Replace http: with https: in 
MAINTAINERs file"):
> On Tue, May 01, 2018 at 01:34:01PM +0100, Lars Kurth wrote:
> > Requested by Ian Jackson, see
> > https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02286.html
> > 
> > The patch also fixes the location of linux-2.6.18-xen.hg (it is currently
> > pointing to an alias)
> 
> While at it do we want to change git: to https: as well?

SGTM, at least for the ones on xenbits (where the https urls are fully
supported).

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Ian Jackson]

Lars Kurth writes ("Re: [PATCH for-4.11 v2 2/2] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
> On 30/04/2018, 17:21, "Ian Jackson"  wrote:
> 
> When I do this, there is nothing that gets the CC for the cover letter
> right.  (I sometimes bodge it.)  Your tool already knows how to
> extract CCs from the individual non-cover-letter patches and add them
> to the cover letter.  That is the function I want - to do that, but
> not run get_maintainer.
> 
> That makes sense and can be easily done via an option: e.g.
> --insert cover|-i cover or a separate option. Let me know whether
> you have a preference regarding naming/options.

I think this is orthogonal to -i.  That is, a user who wants your tool
to only edit the cover letter might want either to have it add the CCs
only to the mail header, or into the body as well.

Perhaps --transfer-only aka -T ?  Not sure I can think of a good name.

As an aside, I guess with `-i ccbody' your tool still puts the CCs in
the mail headers of the cover letter ?  Or will git-send-email do that ?

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 2/2] Replace http: with https: in MAINTAINERs file

[Wei Liu]

On Tue, May 01, 2018 at 01:34:01PM +0100, Lars Kurth wrote:
> Requested by Ian Jackson, see
> https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02286.html
> 
> The patch also fixes the location of linux-2.6.18-xen.hg (it is currently
> pointing to an alias)


While at it do we want to change git: to https: as well?

It can be done with another patch.

Wei.

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

Re: [Xen-devel] [PATCH for-4.11 2/2] Replace http: with https: in MAINTAINERs file

[Ian Jackson]

Lars Kurth writes ("[PATCH for-4.11 2/2] Replace http: with https: in 
MAINTAINERs file"):
> Requested by Ian Jackson, see
> https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02286.html
> 
> The patch also fixes the location of linux-2.6.18-xen.hg (it is currently
> pointing to an alias)

Acked-by: Ian Jackson 

Also I already acked your 1/2.

I'll wait a bit longer before committing in case anyone else has
anything else to say.

Ian.

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

Re: [Xen-devel] [PATCH for-4.11 v3 0/2] Add Designated Reviewer (R:) to MAINTAINERS (plus a test case)

[Ian Jackson]

Lars Kurth writes ("[PATCH for-4.11 v3 0/2] Add Designated Reviewer (R:) to 
MAINTAINERS (plus a test case)"):
> This follows up from a conversation after the April x86 community call, in 
> which I had
> the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS 
> copying 
> the R section entries from Linux.git:MAINTAINERS (will need changes to 
> get_maintainers.pl also)

Thanks, both committed.  I edited the commit message to have
MAINTAINERS and (for patch 1) get_maintainer.pl at the start.

Ian.

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

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

[Boris Ostrovsky]

On 05/01/2018 07:31 AM, David Laight wrote:

From: Boris Ostrovsky

Sent: 30 April 2018 17:24
To: linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org
Cc: jgr...@suse.com; Boris Ostrovsky; sta...@vger.kernel.org
Subject: [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

Latest binutils release (2.29.1) will no longer allow proper computation
of GDT entries on 32-bits, with warning:

arch/x86/xen/xen-pvh.S: Assembler messages:
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (40 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (40 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
between 0 and 31)

Use explicit value of the entry instead of using GDT_ENTRY() macro.

...

  #ifdef CONFIG_X86_64
-   .quad GDT_ENTRY(0xa09a, 0, 0xf) /* __KERNEL_CS */
+   .quad 0x00af9a00/* __BOOT_CS */
  #else
-   .quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
+   .quad 0x00cf9a00/* __BOOT_CS */
  #endif
-   .quad GDT_ENTRY(0xc092, 0, 0xf) /* __KERNEL_DS */
+   .quad 0x00cf9200/* __BOOT_DS */
  gdt_end:


It has to be possible to fix the GDT_ENTRY() macro.
Even if you end up with one that generates two 32bit values.



Is it worth it though? We seem to be using GDT_ENTRY_INIT() everywhere 
and the only other reference that I see is in pm.c and it also probably 
ought to use GDT_ENTRY_INIT().





You've also changed the name in the comments.


Yes, I should mention this in the commit message.


-boris

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

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Jason Cooper]

Morning George,

On Tue, May 01, 2018 at 11:25:06AM +0100, George Dunlap wrote:
> On Mon, Apr 30, 2018 at 7:17 PM, Jason Cooper  wrote:
> > On Mon, Apr 30, 2018 at 05:38:55PM +0100, George Dunlap wrote:
> >> On Mon, Apr 30, 2018 at 5:16 PM, Jason Cooper  wrote:
> >> > On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> >> >> Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = 
> >> >> NO-CARRIER?"):
> >> >> > To implement reuse_domid in a sane way, either the toolstack needs to
> >> >> > manage all domids and always sets domid when creating domain or the
> >> >> > hypervisor needs to cooperate -- to have interface to reserve /
> >> >> > pre-allocate domids.
> >> >>
> >> >> I think this is entirely the wrong approach.
> >> >
> >> > Whew.  Glad I didn't start hacking yet...
> >> >
> >> >> I think the right answer is that this is simply a bug in the
> >> >> frontends.  frontends should cope if the backend path pointer in the
> >> >> frontend directory is updated, and should start reading the new
> >> >> backend instead.
> >> >
> >> > Ok, so I'm new to the guts of Xen.  The bug, at a high level, is that
> >> > "When a driver domain is rebooted (domid changed), previously connected
> >> > client domUs can't gain network connectivity to/through the driver
> >> > domain via 'xl network-attach client_domu mac=... bridge=...
> >> > backend=drv_dom'"
> >>
> >> Hang on -- just to clarify, something like the following doesn't work
> >> (or wouldn't, you suspect, work)?
> >>
> >> * Start driver domain
> >> * Start domU A with no network
> >
> > My setup is different here.  I include the vif = [... backend=...]
> > declaration in my domain config.
> >
> >> * xl network-attach A backend=drv_dom
> >
> > So I don't do this step manually.
> 
> Right, but you do the detach manually (as well as the subsequent
> attach after the driver domain
> 
> >
> >> * [do some stuff]
> >> * xl network-detach A [network devid]
> >> * Restart driver domain
> >> * xl network-attach A backend=drv_dom
> [snip]
> > Sorry, I get NO-CARRIER in the just rebooted driver domain.  And the
> > interface is still UP in domU A.
> 
> Wait, that sounds like a different problem than the one we thought you
> were talking about.  You're saying that the driver domain is losing
> connection to the *physical* network after reboot?

No, this has nothing to do with the physical nic that is
pic-passthrough'd.  It's as my subject line says: vifX.Y gets
NO-CARRIER.  Here's a snippet from 'ip link'

12: vif20.1:  mtu 1500 qdisc mq master br10 
qlen 32
link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff

> So what happens if you do the following:
> 
> * Boot your driver domain (but don't connect any guests)
> * From your driver domain, ping an off-host IP
> * Reboot the driver domain
> * Try pinging an off-host IP again
> 
> It sounds like maybe the second ping will fail?

I assume this is for debugging the (hopefully clarified) non-existent
problem with pci-passthrough.  fwiw, this particular driver domain is in
the middle of the diagram I did earlier in the thread.  It's a netfront
client to a driver domain which does have the pci-passthrough.

When I was first digging into this, I started a thread on xen-users [1],
I've attached my xl-reboot.sh script here so you can see exactly what
I'm attempting to do:

--->8
#!/bin/bash

if [ $# -ne 1 ]; then
echo >&2 "Usage: ${0##*/} domain"
exit 1
fi

DOM="$1"

# get the domain id
DOMID="`xl domid $DOM`"
[[ "$DOMID" =~ (^[0-9]+$) ]] || exit 1

tmp="`mktemp`"

# loop through frontends
while read frontend <&4; do
while read vif <&5; do
if [ "x$vif" = "x" ]; then
# stale frontend
echo >&2 "WARN: stale frontend ($frontend), removing"
xenstore-rm /local/domain/$DOMID/backend/vif/$frontend
continue
fi

# store info for afterwards
front="`xl domname $frontend`"
bridge="`xenstore-read 
/local/domain/$DOMID/backend/vif/$frontend/$vif/bridge`"
if [ "x$front" != "x" ] && [[ "$bridge" =~ (br[0-9][0-9]*) ]]; 
then
echo "$front bridge=$bridge backend=$DOM" >>"$tmp"

# remove the vif
echo >&2 "Removing $vif from $front"
xl -f network-detach $front $vif
fi
done 5< <(xenstore-list /local/domain/$DOMID/backend/vif/$frontend)
done 4< <(xenstore-list /local/domain/$DOMID/backend/vif)

# reboot the domain
xl shutdown -w $DOM || exit 2
sleep 1
xl create -c $DOM || exit 3

if [ "`cat $tmp | wc -c`" -eq 0 ]; then
rm -f $tmp
exit 0
fi

# reattach everything
echo
while read ln <&4; do
echo >&2 "re-attach [$ln]"
xl 

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

[Boris Ostrovsky]

On 05/01/2018 04:00 AM, Roger Pau Monné wrote:

On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:

And without it we can't use _BOOT_XX macros any longer so define new ones.


Not being that familiar with Linux internals I'm not sure I see the
benefit of this. Isn't there a risk that some other code is going to
use the __BOOT_XX defines?


The startup code we are jumping to loads their own GDT and I don't see 
any explicit references to segments.


The reason I added this patch was that since we are adding another 
segment descriptor (GS) we are now using PVH-specific GDT and so we are 
not sharing layout with other code anymore. (Also, the new GS segment 
overlaps with __BOOT_TSS so I kind of broke it already there, not 
unintentionally).


But if people think I should stick with __BOOT_XX I can drop this patch 
(and then probably move GS down one entry).



-boris

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

[Xen-devel] [PATCH for-4.11 0/2] MAINTAINERS cleanup

[Lars Kurth]

Patches cleaning up the MAINTAINERs file
- Replace xen.org with xenproject.org in URLs
- Replace http: with https: in URLs
  - Also fixes the location of linux-2.6.18-xen.hg

This was formerly part of
https://lists.xenproject.org/archives/html/xen-devel/2018-04/threads.html#02230

Lars Kurth (2):
  Replace occurances of xen.org with xenproject.org
  Replace http: with https: in MAINTAINERs file

 MAINTAINERS | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

-- 
2.13.0


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

[Xen-devel] [PATCH for-4.11 1/2] Replace occurances of xen.org with xenproject.org

[Lars Kurth]

This is a general clean-up activity. It also avoids mails being
sent to xen-devel@lists.xenproject.org and xen-de...@lists.xen.org
when used with add_maintainers.pl/git send-email

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Juergen Gross 
Signed-off-by: Lars Kurth 

Released-acked-by: Juergen Gross 
---
 MAINTAINERS | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index bbda4b9f43..90aa759145 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18,7 +18,7 @@ trivial patch so apply some common sense.
and variable names.  These aren't as silly as they seem. One
job the maintainers do is to keep things looking the same.
 
-   PLEASE see http://wiki.xen.org/wiki/Submitting_Xen_Patches for
+   PLEASE see http://wiki.xenproject.org/wiki/Submitting_Xen_Patches for
hints on how to submit a patch to xen-unstable in a suitable
form.
 
@@ -46,7 +46,7 @@ trivial patch so apply some common sense.
 The policy for inclusion in a Xen stable release is different to that
 for inclusion in xen-unstable.
 
-Please see http://wiki.xen.org/wiki/Xen_Maintenance_Releases for more
+Please see http://wiki.xenproject.org/wiki/Xen_Maintenance_Releases for more
 information.
 
 Backport requests should be made on the xen-devel@lists.xenproject.org
@@ -163,7 +163,7 @@ ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
 M: Stefano Stabellini 
 M: Julien Grall 
 S: Supported
-L: xen-de...@lists.xen.org
+L: xen-devel@lists.xenproject.org
 F: docs/misc/arm/
 F: xen/arch/arm/
 F: xen/drivers/char/arm-uart.c
@@ -290,7 +290,7 @@ MINI-OS
 M: Samuel Thibault 
 S: Supported
 L: minios-de...@lists.xenproject.org
-T: git git://xenbits.xen.org/mini-os.git
+T: git git://xenbits.xenproject.org/mini-os.git
 F: config/MiniOS.mk
 
 OCAML TOOLS
@@ -303,7 +303,7 @@ OVMF UPSTREAM
 M: Anthony PERARD 
 M: Wei Liu 
 S: Supported
-T: git git://xenbits.xen.org/ovmf.git
+T: git git://xenbits.xenproject.org/ovmf.git
 
 POWER MANAGEMENT
 M: Jan Beulich 
@@ -327,13 +327,13 @@ F:tools/python
 QEMU-DM
 M: Ian Jackson 
 S: Supported
-T: git git://xenbits.xen.org/qemu-xen-traditional.git
+T: git git://xenbits.xenproject.org/qemu-xen-traditional.git
 
 QEMU UPSTREAM
 M: Stefano Stabellini 
 M: Anthony Perard 
 S: Supported
-T: git git://xenbits.xen.org/qemu-xen.git
+T: git git://xenbits.xenproject.org/qemu-xen.git
 
 REMUS
 M: Shriram Rajagopalan 
@@ -361,7 +361,7 @@ F:  xen/common/sched*
 SEABIOS UPSTREAM
 M: Wei Liu 
 S: Supported
-T: git git://xenbits.xen.org/seabios.git
+T: git git://xenbits.xenproject.org/seabios.git
 
 STUB DOMAINS
 M: Samuel Thibault 
@@ -398,13 +398,13 @@ F:docs/misc/tmem*
 UNMODIFIED LINUX PV DRIVERS
 M: Jan Beulich 
 S: Obsolete
-L: xen-de...@lists.xen.org
+L: xen-devel@lists.xenproject.org
 F: unmodified_drivers/linux-2.6/
 
 USB PV DRIVERS
 M: Noboru Iwamatsu 
 S: Supported
-T: hg http://xenbits.xen.org/linux-2.6.18-xen.hg
+T: hg http://xenbits.xenproject.org/linux-2.6.18-xen.hg
 F: drivers/xen/usb*/
 
 VM EVENT, MEM ACCESS and MONITOR
@@ -441,7 +441,7 @@ X86 ARCHITECTURE
 M: Jan Beulich 
 M: Andrew Cooper 
 S: Supported
-L: xen-de...@lists.xen.org
+L: xen-devel@lists.xenproject.org
 F: xen/arch/x86/
 F: xen/include/asm-x86/
 F: xen/include/public/arch-x86/
@@ -513,7 +513,7 @@ M:  Konrad Rzeszutek Wilk 
 M: Stefano Stabellini 
 M: Tim Deegan 
 M: Wei Liu 
-L: xen-de...@lists.xen.org
+L: xen-devel@lists.xenproject.org
 S: Supported
 F: *
 F: */
-- 
2.13.0


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

[Xen-devel] [PATCH for-4.11 2/2] Replace http: with https: in MAINTAINERs file

[Lars Kurth]

Requested by Ian Jackson, see
https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg02286.html

The patch also fixes the location of linux-2.6.18-xen.hg (it is currently
pointing to an alias)

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Juergen Gross 
Signed-off-by: Lars Kurth 
---
 MAINTAINERS | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90aa759145..809ee4138a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18,7 +18,7 @@ trivial patch so apply some common sense.
and variable names.  These aren't as silly as they seem. One
job the maintainers do is to keep things looking the same.
 
-   PLEASE see http://wiki.xenproject.org/wiki/Submitting_Xen_Patches for
+   PLEASE see https://wiki.xenproject.org/wiki/Submitting_Xen_Patches for
hints on how to submit a patch to xen-unstable in a suitable
form.
 
@@ -46,7 +46,7 @@ trivial patch so apply some common sense.
 The policy for inclusion in a Xen stable release is different to that
 for inclusion in xen-unstable.
 
-Please see http://wiki.xenproject.org/wiki/Xen_Maintenance_Releases for more
+Please see https://wiki.xenproject.org/wiki/Xen_Maintenance_Releases for more
 information.
 
 Backport requests should be made on the xen-devel@lists.xenproject.org
@@ -389,7 +389,7 @@ F:  tools/
 
 TRANSCENDENT MEMORY (TMEM)
 M: Konrad Rzeszutek Wilk 
-W: http://oss.oracle.com/projects/tmem
+W: https://oss.oracle.com/projects/tmem
 S: Supported
 F: xen/common/tmem*
 F: xen/include/xen/tmem*
@@ -404,7 +404,7 @@ F:  unmodified_drivers/linux-2.6/
 USB PV DRIVERS
 M: Noboru Iwamatsu 
 S: Supported
-T: hg http://xenbits.xenproject.org/linux-2.6.18-xen.hg
+T: hg https://xenbits.xenproject.org/hg/linux-2.6.18-xen.hg
 F: drivers/xen/usb*/
 
 VM EVENT, MEM ACCESS and MONITOR
-- 
2.13.0


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

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

[Boris Ostrovsky]

On 05/01/2018 03:53 AM, Roger Pau Monné wrote:

On Mon, Apr 30, 2018 at 02:07:43PM -0400, Boris Ostrovsky wrote:

On 04/30/2018 12:57 PM, Roger Pau Monné wrote:

On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote:

Latest binutils release (2.29.1) will no longer allow proper computation
of GDT entries on 32-bits, with warning:

arch/x86/xen/xen-pvh.S: Assembler messages:
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (40 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (40 is not 
between 0 and 31)
arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
between 0 and 31)

Use explicit value of the entry instead of using GDT_ENTRY() macro.

Signed-off-by: Boris Ostrovsky 
Cc: sta...@vger.kernel.org
---
  arch/x86/xen/xen-pvh.S | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
index e1a5fbe..934f7d4 100644
--- a/arch/x86/xen/xen-pvh.S
+++ b/arch/x86/xen/xen-pvh.S
@@ -145,11 +145,11 @@ gdt_start:
.quad 0x/* NULL descriptor */
.quad 0x/* reserved */
  #ifdef CONFIG_X86_64
-   .quad GDT_ENTRY(0xa09a, 0, 0xf) /* __KERNEL_CS */
+   .quad 0x00af9a00/* __BOOT_CS */
  #else
-   .quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
+   .quad 0x00cf9a00/* __BOOT_CS */

Maybe it would be cleaner to use something like:


I actually considered all of these and ended up with a raw number
because it seems to be a convention in kernel (and Xen too, apparently)
to use raw values in .S files.

Kernel is using now GDT_ENTRY_INIT() which is a C macro. There is one
other location where GDT_INIT() is used (arch/x86/boot/pm.c) and,
incidentally, it also generates this warning IIRC.

I really don't want to move definition to C code just to use a macro ---
I don't think C code needs to be exposed to this GDT.




.word 0x /* limit */
.word 0  /* base */
.byte 0  /* base */
.byte 0x9a   /* access */
#ifdef CONFIG_X86_64
.byte 0xaf   /* flags plus limit */
#else
.byte 0xcf   /* flags plus limit */
#endif
.byte 0  /* base */



I, in fact, started with something like this. But if you repeat this 4
times you will probably see why I decided against it ;-)


Heh, right. Maybe a .macro to generate those? Or this is all too much
for just a couple of GDT entries anyway...



That's what I thought. Especially given that assembly code seems to be 
using raw values.




For long mode however you could use simpler values, AFAICT the code
segment in long mode could be simplified to:

0x00209a00

Because the base/limit have no effect.



True. However, we are sharing the DS (and later GS) descriptors between 
32- and 64-it modes. I can separate them if you think it makes sense.


-boris




In any case I'm not specially inclined either way, and maybe using
similar values for 32 and 64bit modes makes this easier to understand
(and decode if needed).

Roger.



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

Re: [Xen-devel] [For knowledge-sake] Understanding of couple of things under the hood

[Ajay Garg]

Thanks a ton Julien, that was mighty useful !!

On Tue, May 1, 2018 at 4:44 PM, Julien Grall  wrote:
>
>
> On 01/05/18 11:27, Ajay Garg wrote:
>>
>> Hi All.
>
>
> Hello,
>
>
>> I have been able to bring up xen on cubieboard2, using the following
>> script gathered from google :
>>
>> ###
>> # SUNXI Xen Boot Script
>> # Arch Linux ARM adaption of the cmd file which can be found at
>> http://openmirage.org/wiki/xen-on-cubieboard2
>>
>> # Addresses suitable for 1GB system, adjust as appropriate for a 2GB
>> system.
>> # Top of RAM: 0x8000
>> # Xen relocate addr   0x7fe0
>> setenv kernel_addr_r  0x7f60 # 10 MB
>> setenv fdt_addr   0x7ec0 #  2 MB
>> setenv xen_addr_r 0x7ea0 #  2 MB
>>
>> setenv fdt_high  0x # Load fdt in place instead of relocating
>>
>> # Load xen/xen to ${xen_addr_r}.
>> fatload mmc 0 ${xen_addr_r} /xen
>> setenv bootargs "dom0_mem=256M"
>>
>> # Load appropriate .dtb file to ${fdt_addr}
>> fatload mmc 0 ${fdt_addr} /sun7i-a20-cubieboard2.dtb
>> fdt addr ${fdt_addr} 0x4
>> fdt resize
>> fdt chosen
>> fdt set /chosen \#address-cells <1>
>> fdt set /chosen \#size-cells <1>
>>
>> # Load Linux arch/arm/boot/zImage to ${kernel_addr_r}
>> fatload mmc 0 ${kernel_addr_r} /zImage
>>
>> fdt mknod /chosen module@0
>> fdt set /chosen/module@0 compatible "xen,linux-zimage"
>> "xen,multiboot-module"
>> fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} >
>> fdt set /chosen/module@0 bootargs "console=hvc0 rw root=/dev/mmcblk0p2
>> rootwait  clk_ignore_unused"
>>
>> bootz ${xen_addr_r} - ${fdt_addr}
>> ###
>>
>>
>> I have been able to understand most of the workflow, except three things :
>>
>> a)
>> Is the relocation-address of xen, given by
>> # Xen relocate addr   0x7fe0
>> hardcoded? Or it is computed someway from ${kernel_addr_r},
>> {fdt_addr}, {xen_addr_r}?
>>
>> In the bootup logs, xen does relocate to 0x7fe0, so surely there
>> is some magic going ..
>
>
> Xen will always relocate towards the end of the memory. See get_xen_paddr()
> in xen/arch/arm/setup.c. As the placement of the binaries by U-boot will
> have an impact to the relocation address, you need to cleverly choose the
> different addresses.
>
>>
>>
>> b)
>> What does the argument 0x4 signify in the following :
>> fdt addr ${fdt_addr} 0x4
>>
>> I consulted https://www.denx.de/wiki/DULG/UBootCmdFDT, but did not
>> find anything about this third argument.
>
>
> It is explained in section 5.9.7.7. The length is optional and used to tell
> the size of the FDT. This is useful in case the original FDT is not big
> enough to create more properties/nodes.
>
>>
>>
>> c)
>> I assume filesize is the size of the kernel-binary, but how is it
>> determined in the following :
>> fdt set /chosen/module@0 reg <${kernel_addr_r}
>> 0x${filesize} >
>
>
> filesize will contain the size of the latest binary load in memory. The
> udpate will be done by fatload command.
>
> Cheers,
>
> --
> Julien Grall



-- 
Regards,
Ajay

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

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Wei Liu]

On Mon, Apr 30, 2018 at 04:16:09PM +, Jason Cooper wrote:
> Hi Ian,
> 
> On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> > Wei Liu writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = 
> > NO-CARRIER?"):
> > > To implement reuse_domid in a sane way, either the toolstack needs to
> > > manage all domids and always sets domid when creating domain or the
> > > hypervisor needs to cooperate -- to have interface to reserve /
> > > pre-allocate domids.
> > 
> > I think this is entirely the wrong approach.
> 
> Whew.  Glad I didn't start hacking yet...
> 
> > I think the right answer is that this is simply a bug in the
> > frontends.  frontends should cope if the backend path pointer in the
> > frontend directory is updated, and should start reading the new
> > backend instead.
> 
> Ok, so I'm new to the guts of Xen.  The bug, at a high level, is that
> "When a driver domain is rebooted (domid changed), previously connected
> client domUs can't gain network connectivity to/through the driver
> domain via 'xl network-attach client_domu mac=... bridge=...
> backend=drv_dom'"

This seems to be different from what I originally understood. I thought
you were just expecting the frontend to reconnect automatically.

At the risk of asking the obvious question: drv_dom is the name not
numeric domid, right?

> 
> This is due to the fact that the frontend net driver doesn't / can't
> follow the backend driver to the new domid in xenstore.
> 

This is strange. A new udev event should be initiated in DomU. It will
then scans xenstore for a _new_ network device. There should be a new
device from DomU's PoV, which means it doesn't need to know what backend
domid is. This should be already handled by core xenbus driver.

Also "backend-id" is already in a device's xenstore tree.

Wei.

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

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

[David Laight]

From: Boris Ostrovsky
> Sent: 30 April 2018 17:24
> To: linux-ker...@vger.kernel.org; xen-devel@lists.xenproject.org
> Cc: jgr...@suse.com; Boris Ostrovsky; sta...@vger.kernel.org
> Subject: [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant
> 
> Latest binutils release (2.29.1) will no longer allow proper computation
> of GDT entries on 32-bits, with warning:
> 
> arch/x86/xen/xen-pvh.S: Assembler messages:
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
> between 0 and 31)
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (40 is not 
> between 0 and 31)
> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
> between 0 and 31)
> arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
> between 0 and 31)
> arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (40 is not 
> between 0 and 31)
> arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
> between 0 and 31)
> 
> Use explicit value of the entry instead of using GDT_ENTRY() macro.
...
>  #ifdef CONFIG_X86_64
> - .quad GDT_ENTRY(0xa09a, 0, 0xf) /* __KERNEL_CS */
> + .quad 0x00af9a00/* __BOOT_CS */
>  #else
> - .quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
> + .quad 0x00cf9a00/* __BOOT_CS */
>  #endif
> - .quad GDT_ENTRY(0xc092, 0, 0xf) /* __KERNEL_DS */
> + .quad 0x00cf9200/* __BOOT_DS */
>  gdt_end:

It has to be possible to fix the GDT_ENTRY() macro.
Even if you end up with one that generates two 32bit values.

You've also changed the name in the comments.

David


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

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Wei Liu]

On Fri, Apr 27, 2018 at 05:27:29PM +, Jason Cooper wrote:
> Hi Wei Liu,
> 
> On Fri, Apr 27, 2018 at 05:58:17PM +0100, Wei Liu wrote:
> > On Fri, Apr 27, 2018 at 04:14:16PM +, Jason Cooper wrote:
> > > On Fri, Apr 27, 2018 at 04:52:57PM +0100, Andrew Cooper wrote:
> ...
> > > > xc_domain_create() takes a domid value by pointer.  Passing a value
> > > > other than zero will cause Xen to use that domid, rather than by
> > > > searching for the next free domid.
> > > > 
> > > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > > > index b5e27a7..7866092 100644
> > > > --- a/tools/libxl/libxl_create.c
> > > > +++ b/tools/libxl/libxl_create.c
> > > > @@ -583,6 +583,7 @@ int libxl__domain_make(libxl__gc *gc,
> > > > libxl_domain_config *d_config,
> > > >  goto out;
> > > >  }
> > > >  
> > > > +    *domid = atoi(getenv("OVERRIDE_DOMID") ?: "0");
> > > >  ret = xc_domain_create(ctx->xch, info->ssidref, handle, flags, 
> > > > domid,
> > > >     _config);
> > > >  if (ret < 0) {
> > > > 
> > > > This gross hack may get you somewhere (Entirely untested).
> > > 
> > > Gah!  Yep, that's just what I needed, thanks!  I don't suppose a patch
> > > series adding a 'domid' field to the domain config file would be
> > > rejected outright?  That would allow callers of xl to use key=value for
> > > reboot scripts like mine, and also allow for a static domid setup of the
> > > driver domains if folks want that.
> > 
> > Seems a bit  hacky to me. You also need to reserve a set of domids
> > before hand?
> 
> My thought of creating a domid config file variable was to do just as
> you say, reserve specific domids for specific guests.  I could even
> trigger an error if domid is set when driver_domain isn't.
> 
> Actually, I could slightly overload driver_domain, changing from a bool
> to a 'static domid'.  0 = not a driver domain, >0 is it's static domid
> assignment.
> 
> For backwards compatibility, 1 = next domid available, and >1 would be
> the static domid.  I'm not sure if I like that though.
> 
> The racey part is when a driver domain is shut down, how does a create
> thread know that that domid is reserved?

If a driver domain shuts down and another domain gets allocated that
domain id, your whole system is hosed.

It is even worse if you consider the security implication: some
potentially malicious guest can impersonate driver domain and sees what
other guests' data.

> 
> third option, tri-state:
> 
> driver_domain = 0   # not a driver domain
> driver_domain = 1   # is a driver domain, use next avail domid
> driver_domain = 2   # is a driver domain, re-use domid
> 

Let's shelve this UI discussion for now. I will have a look at the other
subthread.

Wei.

> Honestly, I'm not really liking any of these.  Perhaps 'xl
> network-detach ...' should be doing a better job of cleaning up?  Or,
> 'xl network-attach ...' should do a better job of re-attaching?
> 
> thx,
> 
> Jason.

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

Re: [Xen-devel] reboot driver domain, vifX.Y = NO-CARRIER?

[Wei Liu]

On Mon, Apr 30, 2018 at 06:14:15PM +, Jason Cooper wrote:
> On Mon, Apr 30, 2018 at 05:26:38PM +0100, Ian Jackson wrote:
> > Jason Cooper writes ("Re: [Xen-devel] reboot driver domain, vifX.Y = 
> > NO-CARRIER?"):
> > > On Mon, Apr 30, 2018 at 04:22:30PM +0100, Ian Jackson wrote:
> ...
> > > Ok, so I'm new to the guts of Xen.  The bug, at a high level, is that
> > > "When a driver domain is rebooted (domid changed), previously connected
> > > client domUs can't gain network connectivity to/through the driver
> > > domain via 'xl network-attach client_domu mac=... bridge=...
> > > backend=drv_dom'"
> > > 
> > > This is due to the fact that the frontend net driver doesn't / can't
> > > follow the backend driver to the new domid in xenstore.
> > 
> > Yes.
> > 
> > > > I'm a bit surprised that this doesn't already work.
> > > 
> > > I'm currently running Xen 4.9.1 as patched in the standard Gentoo
> > > ebuild.  I've been putting off upgrading to 4.9.2, now marked stable in
> > > portage, until I nail this down.  I'm happy to move to 4.10 if needed.
> > > 
> > > Do you think this is something that is definitely fixed in a more recent
> > > version of Xen?  I'm happy to test if so.  Is there a commit id I can
> > > look for?
> > 
> > I think that in my view (which others may disagree with) this is not a
> > bug in Xen but in the Linux kernel frontend.  So changing the Xen
> > version won't help.
> 
> I'm running vanilla v4.16.4 based on allnoconfig in all of these
> mini-domu's.  It doesn't look there's been any pertinent recent changes
> in drivers/net/xen-netfront.c since v4.16.
> 
> Based on an initial scan of the code, it looks like xen-netback watches
> for hotplug events on the frontend (xen-netback/xenbus.c:1041-1046 in
> connect()).  xen-netfront.c:1995-2036, netback_changed(), is the
> registered callback for netfront.
> 
> Is the xenbus netback/netfront state machine documented anywhere?
> include/xen/interface/io/netif.h has a great description of tx/rx queue
> setup and teardown, but doesn't seem to have anything specific to the
> high-level signalling that 'xl network-attach' would cause.
> 

Netback state machine is in
drivers/net/xen-netback/xenbus.c:set_backend_state.

But honestly I don't think that solves the general issue. It is a bit
unfortunately that Xen drivers don't have a unified state machine.

Wei.

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

Re: [Xen-devel] [For knowledge-sake] Understanding of couple of things under the hood

[Julien Grall]

On 01/05/18 11:27, Ajay Garg wrote:

Hi All.


Hello,


I have been able to bring up xen on cubieboard2, using the following
script gathered from google :

###
# SUNXI Xen Boot Script
# Arch Linux ARM adaption of the cmd file which can be found at
http://openmirage.org/wiki/xen-on-cubieboard2

# Addresses suitable for 1GB system, adjust as appropriate for a 2GB system.
# Top of RAM: 0x8000
# Xen relocate addr   0x7fe0
setenv kernel_addr_r  0x7f60 # 10 MB
setenv fdt_addr   0x7ec0 #  2 MB
setenv xen_addr_r 0x7ea0 #  2 MB

setenv fdt_high  0x # Load fdt in place instead of relocating

# Load xen/xen to ${xen_addr_r}.
fatload mmc 0 ${xen_addr_r} /xen
setenv bootargs "dom0_mem=256M"

# Load appropriate .dtb file to ${fdt_addr}
fatload mmc 0 ${fdt_addr} /sun7i-a20-cubieboard2.dtb
fdt addr ${fdt_addr} 0x4
fdt resize
fdt chosen
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>

# Load Linux arch/arm/boot/zImage to ${kernel_addr_r}
fatload mmc 0 ${kernel_addr_r} /zImage

fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} >
fdt set /chosen/module@0 bootargs "console=hvc0 rw root=/dev/mmcblk0p2
rootwait  clk_ignore_unused"

bootz ${xen_addr_r} - ${fdt_addr}
###


I have been able to understand most of the workflow, except three things :

a)
Is the relocation-address of xen, given by
# Xen relocate addr   0x7fe0
hardcoded? Or it is computed someway from ${kernel_addr_r},
{fdt_addr}, {xen_addr_r}?

In the bootup logs, xen does relocate to 0x7fe0, so surely there
is some magic going ..


Xen will always relocate towards the end of the memory. See 
get_xen_paddr() in xen/arch/arm/setup.c. As the placement of the 
binaries by U-boot will have an impact to the relocation address, you 
need to cleverly choose the different addresses.





b)
What does the argument 0x4 signify in the following :
fdt addr ${fdt_addr} 0x4

I consulted https://www.denx.de/wiki/DULG/UBootCmdFDT, but did not
find anything about this third argument.


It is explained in section 5.9.7.7. The length is optional and used to 
tell the size of the FDT. This is useful in case the original FDT is not 
big enough to create more properties/nodes.





c)
I assume filesize is the size of the kernel-binary, but how is it
determined in the following :
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} >


filesize will contain the size of the latest binary load in memory. The 
udpate will be done by fatload command.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant map/unmap

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 01 May 2018 11:30
> To: Paul Durrant 
> Cc: Roger Pau Monne ; Kevin Wolf
> ; Stefano Stabellini ; qemu-
> bl...@nongnu.org; qemu-de...@nongnu.org; Max Reitz
> ; Anthony Perard ; xen-
> de...@lists.xenproject.org; Wei Liu 
> Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of grant
> map/unmap
> 
> On Mon, Apr 30, 2018 at 03:30:02PM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Roger Pau Monne
> > > Sent: 30 April 2018 16:28
> > > To: Paul Durrant 
> > > Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> > > de...@nongnu.org; Anthony Perard ;
> Kevin
> > > Wolf ; Stefano Stabellini ;
> Max
> > > Reitz 
> > > Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of
> grant
> > > map/unmap
> > >
> > > On Mon, Apr 30, 2018 at 04:16:52PM +0100, Paul Durrant wrote:
> > > > > -Original Message-
> > > > > From: Roger Pau Monne
> > > > > Sent: 30 April 2018 16:12
> > > > > To: Paul Durrant 
> > > > > Cc: xen-devel@lists.xenproject.org; qemu-bl...@nongnu.org; qemu-
> > > > > de...@nongnu.org; Anthony Perard ;
> > > Kevin
> > > > > Wolf ; Stefano Stabellini
> ;
> > > Max
> > > > > Reitz 
> > > > > Subject: Re: [Xen-devel] [PATCH 2/4] block/xen_disk: remove use of
> > > grant
> > > > > map/unmap
> > > > >
> > > > > On Mon, Apr 30, 2018 at 01:01:37PM +0100, Paul Durrant wrote:
> > > > > > The grant copy operation was added to libxengnttab in Xen 4.8.0. If
> > > grant
> > > > > > copy is available then data from the guest will be copied rather 
> > > > > > than
> > > > > > mapped.
> > > > > > The xen_disk source can be significantly simplified by removing this
> > > now
> > > > > > redundant code.
> > > > >
> > > > > Hm, I know this is a PITA, but FreeBSD gntdev hasn't implemented the
> > > > > grant-copy operation yet.
> > > > >
> > > > > I could try to implement it, but I can't make any promises on the time
> > > > > ATM, since I'm quite busy.
> > > > >
> > > >
> > > > I guess we could carry a compat patch in QEMU that implements grant
> copy
> > > by doing a map/memcpy/unmap , but QEMU feels like the wrong place
> for
> > > that. I could try putting together a similar patch for the freebsd.c
> component
> > > of libxengnttab in the xen source rather than it simply failing with 
> > > ENOSYS
> as
> > > it does now. Would either of those help?
> > >
> > > Maybe this could be implemented in gnttab_core.c, so it can also be
> > > used by MiniOS and Linux versions not supporting the copy ioctl as a
> > > fallback?
> >
> > That sounds like a reasonable idea. I'll put something together so that it 
> > can
> go in early in 4.12.
> >
> 
> This will not work if XSM disallows grant map but allows grant copy.
> Not sure how important that is.

I think it's just 'tough' at that point. This is only compat and there'd be no 
change from using current QEMU (which would issue the grant maps directly).

  Cheers,

Paul

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

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

[Xen-devel] [For knowledge-sake] Understanding of couple of things under the hood

[Ajay Garg]

Hi All.

I have been able to bring up xen on cubieboard2, using the following
script gathered from google :

###
# SUNXI Xen Boot Script
# Arch Linux ARM adaption of the cmd file which can be found at
http://openmirage.org/wiki/xen-on-cubieboard2

# Addresses suitable for 1GB system, adjust as appropriate for a 2GB system.
# Top of RAM: 0x8000
# Xen relocate addr   0x7fe0
setenv kernel_addr_r  0x7f60 # 10 MB
setenv fdt_addr   0x7ec0 #  2 MB
setenv xen_addr_r 0x7ea0 #  2 MB

setenv fdt_high  0x # Load fdt in place instead of relocating

# Load xen/xen to ${xen_addr_r}.
fatload mmc 0 ${xen_addr_r} /xen
setenv bootargs "dom0_mem=256M"

# Load appropriate .dtb file to ${fdt_addr}
fatload mmc 0 ${fdt_addr} /sun7i-a20-cubieboard2.dtb
fdt addr ${fdt_addr} 0x4
fdt resize
fdt chosen
fdt set /chosen \#address-cells <1>
fdt set /chosen \#size-cells <1>

# Load Linux arch/arm/boot/zImage to ${kernel_addr_r}
fatload mmc 0 ${kernel_addr_r} /zImage

fdt mknod /chosen module@0
fdt set /chosen/module@0 compatible "xen,linux-zimage" "xen,multiboot-module"
fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} >
fdt set /chosen/module@0 bootargs "console=hvc0 rw root=/dev/mmcblk0p2
rootwait  clk_ignore_unused"

bootz ${xen_addr_r} - ${fdt_addr}
###


I have been able to understand most of the workflow, except three things :

a)
Is the relocation-address of xen, given by
   # Xen relocate addr   0x7fe0
hardcoded? Or it is computed someway from ${kernel_addr_r},
{fdt_addr}, {xen_addr_r}?

In the bootup logs, xen does relocate to 0x7fe0, so surely there
is some magic going ..


b)
What does the argument 0x4 signify in the following :
   fdt addr ${fdt_addr} 0x4

I consulted https://www.denx.de/wiki/DULG/UBootCmdFDT, but did not
find anything about this third argument.


c)
I assume filesize is the size of the kernel-binary, but how is it
determined in the following :
   fdt set /chosen/module@0 reg <${kernel_addr_r} 0x${filesize} >


Will be grateful for some help, as it will gain deeper understanding
of the ecosystem.


Thanks and Regards,
Ajay

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

Re: [Xen-devel] [PATCH] xen: Add RING_COPY_RESPONSE()

[Wei Liu]

On Mon, Apr 30, 2018 at 11:54:36PM +0200, Marek Marczykowski-Górecki wrote:
> Using RING_GET_RESPONSE() on a shared ring is easy to use incorrectly
> (i.e., by not considering that the other end may alter the data in the
> shared ring while it is being inspected).  Safe usage of a response
> generally requires taking a local copy.
> 
> Provide a RING_COPY_RESPONSE() macro to use instead of
> RING_GET_RESPONSE() and an open-coded memcpy().  This takes care of
> ensuring that the copy is done correctly regardless of any possible
> compiler optimizations.
> 
> Use a volatile source to prevent the compiler from reordering or
> omitting the copy.
> 
> This is complementary to XSA155.
> 
> Signed-off-by: Marek Marczykowski-Górecki 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 0/6] Fix XSA-155-like bugs in frontend drivers

[Wei Liu]

(Drop Linux lists and people)

On Mon, Apr 30, 2018 at 11:01:44PM +0200, Marek Marczykowski-Górecki wrote:
> Patches in original Xen Security Advisory 155 cared only about backend drivers
> while leaving frontend patches to be "developed and released (publicly) after
> the embargo date". This is said series.
> 
> Marek Marczykowski-Górecki (6):
>   xen: Add RING_COPY_RESPONSE()
>   xen-netfront: copy response out of shared buffer before accessing it
>   xen-netfront: do not use data already exposed to backend
>   xen-netfront: add range check for Tx response id
>   xen-blkfront: make local copy of response before using it
>   xen-blkfront: prepare request locally, only then put it on the shared ring
> 
>  drivers/block/xen-blkfront.c| 110 ++---
>  drivers/net/xen-netfront.c  |  61 +-
>  include/xen/interface/io/ring.h |  14 -
>  3 files changed, 106 insertions(+), 79 deletions(-)
> 
> base-commit: 6d08b06e67cd117f6992c46611dfb4ce267cd71e

If you're really paranoid you probably also want to consider
implementing more checks for frontend.

See https://xenbits.xen.org/xsa/advisory-39.html for a plethora of
potential issues.

Wei.

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

Re: [Xen-devel] [PATCH 4/6] xen-netfront: add range check for Tx response id

[Wei Liu]

On Mon, Apr 30, 2018 at 11:01:48PM +0200, Marek Marczykowski-Górecki wrote:
> Tx response ID is fetched from shared page, so make sure it is sane
> before using it as an array index.
> 
> CC: sta...@vger.kernel.org
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
>  drivers/net/xen-netfront.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index 934b8a4..55c9b25 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -394,6 +394,7 @@ static void xennet_tx_buf_gc(struct netfront_queue *queue)
>   continue;
>  
>   id  = txrsp.id;
> + BUG_ON(id >= NET_TX_RING_SIZE);

It is better to use ARRAY_SIZE here.

Wei.

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

[Xen-devel] [linux-4.9 test] 122519: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxba3cd5796223e0971d30e910e0d5b953576f8629
baseline version:
 linux5cd35f3eb5384f30d1a10d87f088bacd8839c22b

Last test of basis   122398  2018-04-24 19:39:50 Z6 days
Testing same since   122519  2018-04-29 19:42:21 Z1 days1 attempts


People who touched revisions under test:
  Alexander Aring 
  Andreas Kemnade 
  Arnaldo Carvalho de Melo 
  Benjamin 

Re: [Xen-devel] [PATCH v9 0/9] xen/x86: various XPTI speedups

[Andrew Cooper]

On 26/04/18 12:33, Juergen Gross wrote:
> This patch series aims at reducing the overhead of the XPTI Meltdown
> mitigation.

With just the first 3 patches of this series (in a bisection attempt),
on a XenServer build based off staging, XenRT finds the following:

(XEN) Assertion 'first_dirty != INVALID_DIRTY_IDX || !(pg[i].count_info & 
PGC_need_scrub)' failed at page_alloc.c:979
(XEN) [ Xen-4.11.0-6.0.0-d  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] 
page_alloc.c#alloc_heap_pages+0x371/0x6f2
(XEN) RFLAGS: 00010286   CONTEXT: hypervisor (d33v0)
(XEN) rax: 82e01307ade8   rbx: 0007   rcx: 8180
(XEN) rdx:    rsi: 01b5   rdi: 
(XEN) rbp: 8300952b7ba8   rsp: 8300952b7b18   r8:  8000
(XEN) r9:  82e01307ade8   r10: 0180   r11: 7fff
(XEN) r12:    r13: 024c2e83   r14: 
(XEN) r15: 82e01307add8   cr0: 80050033   cr4: 001526e0
(XEN) cr3: 000799c41000   cr2: 7fdaf5539000
(XEN) fsb:    gsb:    gss: 
(XEN) ds:    es:    fs:    gs:    ss:    cs: e008
(XEN) Xen code around  
(page_alloc.c#alloc_heap_pages+0x371/0x6f2):
(XEN)  ff 0f 0b 48 85 c9 79 31 <0f> 0b 48 c7 42 08 00 00 00 00 c7 42 10 00 00 00
(XEN) Xen stack trace from rsp=8300952b7b18:
(XEN)0001 830799cdd000  003037e9
(XEN)00010004 8300952b7b68 0001 830095738000
(XEN)8300952b7be8 8033bfe8 82e01295e540 1adc
(XEN)830756971770 0028  830799cdd000
(XEN) 830799cdd000 8300952b7be8 82d080229d4c
(XEN) 8300952b7d40  
(XEN)00a8 830799cdd000 8300952b7c98 82d080221d90
(XEN)0001 830799cdd000  99cdd000
(XEN)82e009cd0fd8 000e7b1f 8300952b7c88 0020
(XEN)8800e7b1fdd8 0002 0006 830799cdd000
(XEN)8300952b7c78 0039f480  008d
(XEN)8800e7b1fdd8 830799cdd000 0006 830799cdd000
(XEN)8300952b7db8 82d080223ad7 0046 830088ff9000
(XEN)8300952b7d18 82d08023cfaf 82c000230118 830842ceeb8c
(XEN)82e009f54db8 003bc78b 830842cd2770 830088ff9000
(XEN)  83085d6b9350 
(XEN)8300952b7d28 82d08023d766 8300952b7d58 82d08020c9a2
(XEN)830842cee000 830799cdd000 81adbec0 0200
(XEN)008d 82d0 81adbec0 0200
(XEN) 7ff0 83085d6b9350 0006
(XEN) Xen call trace:
(XEN)[] page_alloc.c#alloc_heap_pages+0x371/0x6f2
(XEN)[] alloc_domheap_pages+0xb7/0x157
(XEN)[] memory.c#populate_physmap+0x27e/0x4c9
(XEN)[] do_memory_op+0x2e2/0x2695
(XEN)[] hypercall.c#hvm_memory_op+0x36/0x60
(XEN)[] hvm_hypercall+0x5af/0x681
(XEN)[] vmx_vmexit_handler+0x1040/0x1e14
(XEN)[] vmx_asm_vmexit_handler+0xe8/0x250
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion 'first_dirty != INVALID_DIRTY_IDX || !(pg[i].count_info & 
PGC_need_scrub)' failed at page_alloc.c:979
(XEN) 

Running repeated tests on adjacent builds, we never see the assertion
failure without the patches (6 runs), and have so far seen for 3 of 4
runs (2 still pending) with the patches.

What is rather strange is that there is a lot of migration and
ballooning going on, but only for HVM (Debian Jessie, not that this
should matter) VMs.  dom0 will be the only PV domain in the system, and
is 64bit.

~Andrew

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

Re: [Xen-devel] [PATCH 6/6] xen-blkfront: prepare request locally, only then put it on the shared ring

[Roger Pau Monné]

On Tue, May 01, 2018 at 09:22:31AM +0100, Roger Pau Monné wrote:
> On Mon, Apr 30, 2018 at 11:01:50PM +0200, Marek Marczykowski-Górecki wrote:
> > struct request *req,
> > -   struct blkif_request **ring_req)
> > +   struct blkif_request *ring_req)
> >  {
> > unsigned long id;
> >  
> > -   *ring_req = RING_GET_REQUEST(>ring, rinfo->ring.req_prod_pvt);
> > -   rinfo->ring.req_prod_pvt++;
> > -
> > id = get_id_from_freelist(rinfo);
> > rinfo->shadow[id].request = req;
> > rinfo->shadow[id].status = REQ_WAITING;
> > rinfo->shadow[id].associated_id = NO_ASSOCIATED_ID;
> >  
> > -   (*ring_req)->u.rw.id = id;
> > +   ring_req->u.rw.id = id;
> >  
> > return id;
> >  }
> > @@ -545,23 +542,28 @@ static unsigned long blkif_ring_get_request(struct 
> > blkfront_ring_info *rinfo,
> >  static int blkif_queue_discard_req(struct request *req, struct 
> > blkfront_ring_info *rinfo)
> >  {
> > struct blkfront_info *info = rinfo->dev_info;
> > -   struct blkif_request *ring_req;
> > +   struct blkif_request ring_req = { 0 };
> > unsigned long id;
> >  
> > /* Fill out a communications ring structure. */
> > id = blkif_ring_get_request(rinfo, req, _req);
> 
> Maybe I'm missing something obvious here, but you are adding a struct
> allocated on the stack to the shadow ring copy, isn't this dangerous?

The above comment is wrong, you are storing a pointer to 'req' in the
shadow ring copy, which is fine and is not the ring request.

Roger.

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

Re: [Xen-devel] [PATCH 6/6] xen-blkfront: prepare request locally, only then put it on the shared ring

[Roger Pau Monné]

On Mon, Apr 30, 2018 at 11:01:50PM +0200, Marek Marczykowski-Górecki wrote:
> Do not reuse data which theoretically might be already modified by the
> backend. This is mostly about private copy of the request
> (info->shadow[id].req) - make sure the request saved there is really the
> one just filled.
>
> This is complementary to XSA155.
> 
> CC: sta...@vger.kernel.org
> Signed-off-by: Marek Marczykowski-Górecki 
> ---
>  drivers/block/xen-blkfront.c | 76 +
>  1 file changed, 44 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 3926811..b100b55 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -525,19 +525,16 @@ static int blkif_ioctl(struct block_device *bdev, 
> fmode_t mode,
>  
>  static unsigned long blkif_ring_get_request(struct blkfront_ring_info *rinfo,

The name of this function should be changed IMO, since you are no
longer getting a request from the ring, but just initializing a
request struct.

>   struct request *req,
> - struct blkif_request **ring_req)
> + struct blkif_request *ring_req)
>  {
>   unsigned long id;
>  
> - *ring_req = RING_GET_REQUEST(>ring, rinfo->ring.req_prod_pvt);
> - rinfo->ring.req_prod_pvt++;
> -
>   id = get_id_from_freelist(rinfo);
>   rinfo->shadow[id].request = req;
>   rinfo->shadow[id].status = REQ_WAITING;
>   rinfo->shadow[id].associated_id = NO_ASSOCIATED_ID;
>  
> - (*ring_req)->u.rw.id = id;
> + ring_req->u.rw.id = id;
>  
>   return id;
>  }
> @@ -545,23 +542,28 @@ static unsigned long blkif_ring_get_request(struct 
> blkfront_ring_info *rinfo,
>  static int blkif_queue_discard_req(struct request *req, struct 
> blkfront_ring_info *rinfo)
>  {
>   struct blkfront_info *info = rinfo->dev_info;
> - struct blkif_request *ring_req;
> + struct blkif_request ring_req = { 0 };
>   unsigned long id;
>  
>   /* Fill out a communications ring structure. */
>   id = blkif_ring_get_request(rinfo, req, _req);

Maybe I'm missing something obvious here, but you are adding a struct
allocated on the stack to the shadow ring copy, isn't this dangerous?

The pointer stored in the shadow ring copy is going to be invalid
after returning from this function.

The same comment applies to the other calls to blkif_ring_get_request
below that pass a ring_reg allocated on the stack.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] x86/microcode: Synchronize late microcode loading

[Chao Gao]

On Mon, Apr 30, 2018 at 09:25:26AM -0600, Jan Beulich wrote:
 On 25.04.18 at 13:46,  wrote:
>> @@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, 
>> size_t size)
>>  return err;
>>  }
>>  
>> -static long do_microcode_update(void *_info)
>> +/* Wait for all CPUs to rendezvous with a timeout (us) */
>> +static int wait_for_cpus(atomic_t *cnt, int timeout)
>
>unsigned int
>
>> +static int do_microcode_update(void *_info)
>> +{
>> +struct microcode_info *info = _info;
>> +unsigned int cpu = smp_processor_id();
>> +int ret;
>> +
>> +ret = wait_for_cpus(>cpu_in, MICROCODE_DEFAULT_TIMEOUT);
>> +if ( ret )
>> +return ret;
>> +/*
>> + * Logical threads which set the first bit in cpu_sibling_mask can do
>> + * the update. Other sibling threads just await the completion of
>> + * microcode update.
>> + */
>> +if ( cpumask_test_and_set_cpu(
>> +cpumask_first(per_cpu(cpu_sibling_mask, cpu)), >cpus) 
>> )
>> +ret = microcode_update_cpu(info->buffer, info->buffer_size);
>
>Isn't the condition inverted (i.e. missing a ! )?

Yes.

>
>Also I take it that you've confirmed that loading ucode in parallel on multiple
>cores of the same socket is not a problem? The comment in the last hunk
>suggests otherwise.

No. In microcode_update_cpu(), microcode_mutex makes the update
sequential.

>
>> +/*
>> + * Increase the wait timeout to a safe value here since we're 
>> serializing
>> + * the microcode update and that could take a while on a large number of
>> + * CPUs. And that is fine as the *actual* timeout will be determined by
>> + * the last CPU finished updating and thus cut short
>> + */
>> +if ( wait_for_cpus(>cpu_out, MICROCODE_DEFAULT_TIMEOUT *
>> +   num_online_cpus()) )
>> +panic("Timeout when finishing updating microcode");
>
>A 3s timeout (as an example for a system with 100 CPU threads) is still
>absurdly high to me, but considering you panic() anyway if you hit the
>timeout the question mainly is whether there's a slim chance for this to
>complete a brief moment before the timeout expires. If all goes well,
>you won't come close to even 1s, but as said before - there may be
>guests running, and they may become utterly confused if they don't
>get any time within a second or more.
>
>With you no longer doing things sequentially I don't, however, see why

No. It is still sequential. And only one thread in a core will try to
acquire the lock -- microcode_mutex.

>you need to scale the timeout by CPU count.

Maybe by the number of core. But I did't find an existing variable to
count cores.

>
>> +
>> +return ret;
>>  }
>
>You're losing this return value (once for every CPU making it into this
>function).

I don't understand this remark. This function is called by
stop_machine_run(). stop_machine_run() could return error if
any cpu failed during update. We don't care the specific CPU and
how many CPUs failed to do the update.

Thanks
Chao

>
>> @@ -318,26 +357,52 @@ int 
>> microcode_update(XEN_GUEST_HANDLE_PARAM(const_void) buf, unsigned long len)
>>  
>>  ret = copy_from_guest(info->buffer, buf, len);
>>  if ( ret != 0 )
>> -{
>> -xfree(info);
>> -return ret;
>> -}
>> +goto free;
>>  
>>  info->buffer_size = len;
>> -info->error = 0;
>> -info->cpu = cpumask_first(_online_map);
>> +
>> +/* cpu_online_map must not change during update */
>> +if ( !get_cpu_maps() )
>> +{
>> +ret = -EBUSY;
>> +goto free;
>> +}
>>  
>>  if ( microcode_ops->start_update )
>>  {
>>  ret = microcode_ops->start_update();
>>  if ( ret != 0 )
>> -{
>> -xfree(info);
>> -return ret;
>> -}
>> +goto put;
>>  }
>>  
>> -return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
>> +cpumask_empty(>cpus);
>
>DYM cpumask_clear()?
>
>> +atomic_set(>cpu_in, 0);
>> +atomic_set(>cpu_out, 0);
>> +
>> +/*
>> + * We intend to disable interrupt for long time, which may lead to
>> + * watchdog timeout.
>> + */
>> +watchdog_disable();
>> +/*
>> + * Late loading dance. Why the heavy-handed stop_machine effort?
>> + *
>> + * -HT siblings must be idle and not execute other code while the other
>> + *  sibling is loading microcode in order to avoid any negative
>> + *  interactions cause by the loading.
>> + *
>> + * -In addition, microcode update on the cores must be serialized until
>> + *  this requirement can be relaxed in the feature. Right now, this is
>> + *  conservative and good.
>
>This is the comment I've referred to above.
>
>Jan
>

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

[Xen-devel] [PATCH for-4.11 v3 0/2] Add Designated Reviewer (R:) to MAINTAINERS (plus a test case)

[Lars Kurth]

This follows up from a conversation after the April x86 community call, in 
which I had
the following action: Lars to propose fixing CC issue in xen.git:MAINTAINERS 
copying 
the R section entries from Linux.git:MAINTAINERS (will need changes to 
get_maintainers.pl also)

On 27/4/18 Juergen gave a RAB via IRC

Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Brian Woods 
Cc: Juergen Gross 

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

Lars Kurth (2):
  Add Designated Reviewer (R:) to MAINTAINERS file and add support for
it in get_maintainer.pl
  Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM

 MAINTAINERS   |  6 ++
 scripts/get_maintainer.pl | 24 +++-
 2 files changed, 17 insertions(+), 13 deletions(-)

-- 
2.13.0


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

[Xen-devel] [PATCH for-4.11 v3 1/2] Add Designated Reviewer (R:) to MAINTAINERS file and add support for it in get_maintainer.pl

[Lars Kurth]

The syntax has been copied from the Linux Maintainers file. I moved the 
following Linux
get_maintainer.pl patches to Xen, fixing up some merge issues (and a bug).

The get_maintainer.pl changes were based on the following git commits
* 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/scripts/get_maintainer.pl?id=
* c1c3f2c906e35bcb6e4cdf5b8e077660fead14fe
* 4f07510df2e8c47fd65b8ffaaf6c5d334d59d598

I also removed code related to
  P: Person (obsolete)
which is in the Linux MAINTAINER's file, but not ours. I may not have
caught all instances though.

I have tested on a number of files using mock entries in MAINTAINERS
using ./scripts/get_maintainer.pl -f ...

I also tested --nor to disable the support and it worked as expected.

Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Juergen Gross 
Signed-off-by: Lars Kurth 

Release-acked-by: Juergen Gross 
Acked-by: Wei Liu 
---
 MAINTAINERS   |  4 
 scripts/get_maintainer.pl | 24 +++-
 2 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 90aa759145..b12048935b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -60,6 +60,10 @@ appropriate branch.
 Descriptions of section entries:
 
M: Mail patches to: FullName 
+   R: Designated reviewer: FullName 
+  Reviewers should be CCed on patches.  However, they do not
+  have a formal governance role, and are listed here
+  simply because of their own request.
L: Mailing list that is relevant to this area
W: Web-page with status/info
T: SCM tree type and location.  Type is one of: git, hg, quilt, stgit.
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 3fb1ad4b69..d528da738c 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -21,6 +21,7 @@ my $xen_path = "./";
 my $email = 1;
 my $email_usename = 1;
 my $email_maintainer = 1;
+my $email_reviewer = 1;
 my $email_list = 1;
 my $email_subscriber_list = 0;
 my $email_git_penguin_chiefs = 0;
@@ -199,6 +200,7 @@ if (!GetOptions(
'mailmap!' => \$email_use_mailmap,
'drop_the_rest_supporter!' => 
\$email_drop_the_rest_supporter_if_supporter_found,
'm!' => \$email_maintainer,
+   'r!' => \$email_reviewer,
'n!' => \$email_usename,
'l!' => \$email_list,
's!' => \$email_subscriber_list,
@@ -257,7 +259,8 @@ if ($sections) {
 }
 
 if ($email &&
-($email_maintainer + $email_list + $email_subscriber_list +
+($email_maintainer + $email_reviewer +
+ $email_list + $email_subscriber_list +
  $email_git + $email_git_penguin_chiefs + $email_git_blame) == 0) {
 die "$P: Please select at least 1 email option\n";
 }
@@ -791,6 +794,7 @@ MAINTAINER field selection options:
 --hg-since => hg history to use (default: $email_hg_since)
 --interactive => display a menu (mostly useful if used with the --git 
option)
 --m => include maintainer(s) if any
+--r => include reviewer(s) if any
 --n => include name 'Full Name '
 --l => include list(s) if any
 --s => include subscriber only list(s) if any
@@ -817,7 +821,7 @@ Other options:
   --help => show this help information
 
 Default options:
-  [--email --nogit --git-fallback --m --n --l --multiline -pattern-depth=0
+  [--email --nogit --git-fallback --m --r --n --l --multiline -pattern-depth=0
--remove-duplicates --rolestats]
 
 Notes:
@@ -1080,21 +1084,15 @@ sub add_categories {
}
} elsif ($ptype eq "M") {
my ($name, $address) = parse_email($pvalue);
-   if ($name eq "") {
-   if ($i > 0) {
-   my $tv = $typevalue[$i - 1];
-   if ($tv =~ m/^([A-Z]):\s*(.*)/) {
-   if ($1 eq "P") {
-   $name = $2;
-   $pvalue = format_email($name, $address, 
$email_usename);
-   }
-   }
-   }
-   }
if ($email_maintainer) {
my $role = get_maintainer_role($i);
push_email_addresses($pvalue, $role);
}
+   } elsif ($ptype eq "R") {
+   my ($name, $address) = parse_email($pvalue);
+   if ($email_reviewer) {
+   push_email_addresses($pvalue, 

[Xen-devel] [PATCH for-4.11 v3 2/2] Add Brian Woods as Designated reviewer to AMD IOMMU and AMD SVM

[Lars Kurth]

This was discussed in an IRC discussion post the April x86 meeting.
On 27/4/18 Juergen gave a RAB via IRC

Cc: Lars Kurth 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Brian Woods 
Cc: Juergen Gross 
Signed-off-by: Lars Kurth 

Release-acked-by: Juergen Gross 
Acked-by: Brian Woods 
Acked-by: Wei Liu 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b12048935b..b86276dfd7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -146,12 +146,14 @@ F:tools/libacpi/
 
 AMD IOMMU
 M: Suravee Suthikulpanit 
+R: Brian Woods 
 S: Maintained
 F: xen/drivers/passthrough/amd/
 
 AMD SVM
 M: Boris Ostrovsky 
 M: Suravee Suthikulpanit 
+R: Brian Woods 
 S: Supported
 F: xen/arch/x86/hvm/svm/
 F: xen/arch/x86/cpu/vpmu_amd.c
-- 
2.13.0


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

Re: [Xen-devel] [PATCH 4/4] xen/PVH: Remove reserved entry in PVH GDT

[Roger Pau Monné]

On Mon, Apr 30, 2018 at 12:23:39PM -0400, Boris Ostrovsky wrote:
> And without it we can't use _BOOT_XX macros any longer so define new ones.

Not being that familiar with Linux internals I'm not sure I see the
benefit of this. Isn't there a risk that some other code is going to
use the __BOOT_XX defines?

Thanks, Roger.

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

Re: [Xen-devel] Should PV frontend drivers trust the backends?

[Paul Durrant]

> -Original Message-
> From: Marek Marczykowski-Górecki
> [mailto:marma...@invisiblethingslab.com]
> Sent: 30 April 2018 18:33
> To: Oleksandr Andrushchenko 
> Cc: Paul Durrant ; 'Juergen Gross'
> ; xen-devel 
> Subject: Re: [Xen-devel] Should PV frontend drivers trust the backends?
> 
> On Thu, Apr 26, 2018 at 11:47:41AM +0300, Oleksandr Andrushchenko wrote:
> > On 04/26/2018 11:16 AM, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Oleksandr Andrushchenko [mailto:andr2...@gmail.com]
> > > > Sent: 26 April 2018 07:00
> > > > To: Paul Durrant ; 'Juergen Gross'
> > > > ; xen-devel 
> > > > Subject: Re: [Xen-devel] Should PV frontend drivers trust the
> backends?
> > > >
> > > > On 04/25/2018 04:47 PM, Paul Durrant wrote:
> > > > > > -Original Message-
> > > > > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org]
> On
> > > > Behalf
> > > > > > Of Juergen Gross
> > > > > > Sent: 25 April 2018 13:43
> > > > > > To: xen-devel 
> > > > > > Subject: [Xen-devel] Should PV frontend drivers trust the
> backends?
> > > > > >
> > > > > > This is a followup of a discussion on IRC:
> > > > > >
> > > > > > The main question of the discussion was: "Should frontend drivers
> > > > > > trust their backends not doing malicious actions?"
> > > > > >
> > > > > > This IMO includes:
> > > > > >
> > > > > > 1. The data put by the backend on the ring page(s) is sane and
> > > > > >  consistent, meaning that e.g. the response producer index is
> always
> > > > > >  ahead of the consumer index.
> > > > > >
> > > > > > 2. Response data won't be modified by the backend after the
> producer
> > > > > >  index has been incremented signaling the response is valid.
> > > > > >
> > > > > > 3. Response data is sane, e.g. an I/O data length is not larger than
> > > > > >  the buffer originally was.
> > > > > >
> > > > > > 4. When a response has been sent all grants belonging to the
> request
> > > > > >  have been unmapped again by the backend, meaning that the
> frontend
> > > > > >  can assume the grants can be removed without conflict.
> > > > > >
> > > > > > Today most frontend drivers (at least in the Linux kernel) seem to
> > > > > > assume all of the above is true (there are some exceptions, but
> never
> > > > > > for all items):
> > > > > >
> > > > > > - they don't check sanity of ring index values
> > > > > > - they don't copy response data into local memory before looking at
> it
> > > > > > - they don't verify returned data length (or do so via BUG_ON())
> > > > > > - they BUG() in case of a conflict when trying to remove a grant
> > > > > >
> > > > > > So the basic question is: should all Linux frontend drivers be
> modified
> > > > > > in order to be able to tolerate buggy or malicious backends? Or is
> the
> > > > > > list of trust above fine?
> > > > > >
> > > > > > IMO even in case the frontends do trust the backends to behave
> sane this
> > > > > > doesn't mean driver domains don't make sense. Driver domains still
> make
> > > > > > a Xen host more robust as they e.g. protect the host against driver
> > > > > > failures normally leading to a crash of dom0.
> > > > > >
> > > > > I see the general question as being analogous to 'should a Linux
> device
> > > > driver trust its hardware' and I think the answer for a general purpose
> OS like
> > > > linux is 'yes'.
> > > > > Now, having worked on fault tolerant systems in a past life, there are
> > > > definitely cases where you want your OS not to implicitly trust its
> peripheral
> > > > hardware and hence special device drivers are used.
> > > > So what do you do if counters provided by the untrusted HW are ok
> > > > and the payload is not?
> > > Well, that depends on whether there is actually any way to verify the
> payload in a driver. Whatever layer in the system is responsible for the data
> needs to verify its integrity in a fault tolerant system. Generally the 
> driver can
> only attempt to verify that it's hardware is working as expect and quiesce it 
> if
> not. For that reason, in the systems I worked on, the driver had the ability 
> to
> control FETs that disconnected peripheral h/w from the PCI bus.
> > >
> > > > > I think the same would apply for virtual machines in situations where
> a
> > > > driver domain is not wholly controlled by a host administrator or is not
> > > > trusted to the same extent as dom0 for other reasons; i.e. they should
> have
> > > > specialist frontends.
> > > > I believe we might be able to express some common strategy for the
> > > > frontends.
> > > > I do understand though that it all needs to be decided on case by case
> > > > basis,
> > > > but common things could still be there, e.g. if prod/cons counters are
> > > > not in sync
> > > > what a frontend 

Re: [Xen-devel] [PATCH 1/4] xen/PVH: Replace GDT_ENTRY with explicit constant

[Roger Pau Monné]

On Mon, Apr 30, 2018 at 02:07:43PM -0400, Boris Ostrovsky wrote:
> On 04/30/2018 12:57 PM, Roger Pau Monné wrote:
> > On Mon, Apr 30, 2018 at 12:23:36PM -0400, Boris Ostrovsky wrote:
> >> Latest binutils release (2.29.1) will no longer allow proper computation
> >> of GDT entries on 32-bits, with warning:
> >>
> >> arch/x86/xen/xen-pvh.S: Assembler messages:
> >> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
> >> between 0 and 31)
> >> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (40 is not 
> >> between 0 and 31)
> >> arch/x86/xen/xen-pvh.S:150: Warning: shift count out of range (32 is not 
> >> between 0 and 31)
> >> arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
> >> between 0 and 31)
> >> arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (40 is not 
> >> between 0 and 31)
> >> arch/x86/xen/xen-pvh.S:152: Warning: shift count out of range (32 is not 
> >> between 0 and 31)
> >>
> >> Use explicit value of the entry instead of using GDT_ENTRY() macro.
> >>
> >> Signed-off-by: Boris Ostrovsky 
> >> Cc: sta...@vger.kernel.org
> >> ---
> >>  arch/x86/xen/xen-pvh.S | 6 +++---
> >>  1 file changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/arch/x86/xen/xen-pvh.S b/arch/x86/xen/xen-pvh.S
> >> index e1a5fbe..934f7d4 100644
> >> --- a/arch/x86/xen/xen-pvh.S
> >> +++ b/arch/x86/xen/xen-pvh.S
> >> @@ -145,11 +145,11 @@ gdt_start:
> >>.quad 0x/* NULL descriptor */
> >>.quad 0x/* reserved */
> >>  #ifdef CONFIG_X86_64
> >> -  .quad GDT_ENTRY(0xa09a, 0, 0xf) /* __KERNEL_CS */
> >> +  .quad 0x00af9a00/* __BOOT_CS */
> >>  #else
> >> -  .quad GDT_ENTRY(0xc09a, 0, 0xf) /* __KERNEL_CS */
> >> +  .quad 0x00cf9a00/* __BOOT_CS */
> > Maybe it would be cleaner to use something like:
> 
> I actually considered all of these and ended up with a raw number
> because it seems to be a convention in kernel (and Xen too, apparently) 
> to use raw values in .S files.
> 
> Kernel is using now GDT_ENTRY_INIT() which is a C macro. There is one
> other location where GDT_INIT() is used (arch/x86/boot/pm.c) and,
> incidentally, it also generates this warning IIRC.
> 
> I really don't want to move definition to C code just to use a macro ---
> I don't think C code needs to be exposed to this GDT.
> 
> 
> >
> > .word 0x /* limit */
> > .word 0  /* base */
> > .byte 0  /* base */
> > .byte 0x9a   /* access */
> > #ifdef CONFIG_X86_64
> > .byte 0xaf   /* flags plus limit */
> > #else
> > .byte 0xcf   /* flags plus limit */
> > #endif
> > .byte 0  /* base */
> 
> 
> I, in fact, started with something like this. But if you repeat this 4
> times you will probably see why I decided against it ;-)

Heh, right. Maybe a .macro to generate those? Or this is all too much
for just a couple of GDT entries anyway...

For long mode however you could use simpler values, AFAICT the code
segment in long mode could be simplified to:

0x00209a00

Because the base/limit have no effect.

In any case I'm not specially inclined either way, and maybe using
similar values for 32 and 64bit modes makes this easier to understand
(and decode if needed).

Roger.

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 qemuu6f0c4706b35dead265509115ddbd2a8d1af516c1
baseline version:
 qemuu27e757e29cc79f3f104d2a84d17cdb3b4c11c8ff

Last test of basis   122357  2018-04-23 11:07:12 Z7 days
Failing since122394  2018-04-24 16:40:23 Z6 days4 attempts
Testing same since   122484  2018-04-27 21:42:25 Z3 days2 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alexey Perevalov 
  Anthony PERARD 
  BALATON Zoltan 
  Bharata B Rao 
  Cédric Le Goater 
  David Gibson 
  Dr. David Alan Gilbert 
  Elie Tournier