Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

[Oleksandr Andrushchenko]

On 01/20/2017 12:22 AM, Stefano Stabellini wrote:

On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Signed-off-by: Oleksandr Andrushchenko 
---
  xen/include/public/io/kbdif.h | 216 ++
  1 file changed, 216 insertions(+)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index c00faa3af5d2..8d8ba9af1cb1 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -57,6 +57,12 @@
   *  Backends, which support reporting of absolute coordinates for pointer
   *  device should set this to 1.
   *
+ * feature-multi-touch
+ *  Values: 
+ *
+ *  Backends, which support reporting of multi-touch events
+ *  should set this to 1.
+ *
   *- Pointer Device Parameters 
   *
   * width
@@ -87,6 +93,11 @@
   *  Request backend to report absolute pointer coordinates
   *  (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
   *
+ * request-multi-touch
+ *  Values: 
+ *
+ *  Request backend to report multi-touch events.
+ *
   *--- Request Transport Parameters ---
   *
   * event-channel
@@ -106,6 +117,30 @@
   *
   *  OBSOLETE, not recommended for use.
   *  PFN of the shared page.
+ *
+ *--- Multi-touch Device Parameters ---
+ *
+ * Every multi-touch input device uses a dedicated event frontend/backend
+ * connection configured via XenStore properties under
+ * XENKBD_PATH_MTOUCH folder.

This sentence doesn't seem to match the rest of the patch:

lets break it into smaller parts

it looks
like multi-touch devices use the same ring and evtchn used by the
pointer and keyboard.


*Every* multi-touch input device uses a *dedicated* event frontend/backend
*connection*
So, it is clearly stated that there is a dedicated/separate connection
(which consists of a ring and corresponding event channel: here we have
already discussed this part: http://marc.info/?l=xen-devel=148412731428686):


+ * Every multi-touch input device uses a dedicated event ring and is

For clarity I would say "Every multi-touch input device uses a dedicated
frontend/backend connection". That includes a ring, an event channel,
and xenstore entries.





Also, it is not clear whether multiple multitouch devices are supported
with a single frontend/backend connection (as you described in
http://marc.info/?l=xen-devel=148412731428686) or not. Please clarify.

Same as above:

*Every* multi-touch input device uses a *dedicated* event frontend/backend
*connection*



If only one device is supported, do we need a XENKBD_PATH_MTOUCH folder?

For consistency and simplicity: at 
http://marc.info/?l=xen-devel=148412731428686 I have an example of how 
XenStore entries look like. If you define multiple mtouch devices then 
you'll iterate over folder contents, e.g.


/local/domain/11/device/vkbd/0/mtouch/0/width = "3200"
/local/domain/11/device/vkbd/0/mtouch/1/width = "6400"

So, you'll have something like for (i = 0; i < num_mtouch_devices; i++) 
{ process(i); } If you have a single mtouch device nothing changes. 
Thus, I see no reason in making any difference for single or 
multiple-devices.



The values below are per emulated multi-touch
+ * input device:
+ *
+ * num-contacts
+ *  Values: 
+ *
+ *  Number of simultaneous touches reported.
+ *
+ * width
+ *  Values: 
+ *
+ *  Width of the touch area to be used by the frontend
+ *  while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ * height
+ *  Values: 
+ *
+ *  Height of the touch area to be used by the frontend
+ *  while reporting input events, pixels, [0; UINT32_MAX].
   */
  
  /*

@@ -116,6 +151,16 @@
  #define XENKBD_TYPE_RESERVED   2
  #define XENKBD_TYPE_KEY3
  #define XENKBD_TYPE_POS4
+#define XENKBD_TYPE_MTOUCH 5
+
+/* Multi-touch event sub-codes */
+
+#define XENKBD_MT_EV_DOWN  0
+#define XENKBD_MT_EV_UP1
+#define XENKBD_MT_EV_MOTION2
+#define XENKBD_MT_EV_SYN   3
+#define XENKBD_MT_EV_SHAPE 4
+#define XENKBD_MT_EV_ORIENT5
  
  /*

   * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS.
@@ -124,11 +169,17 @@
  #define XENKBD_DRIVER_NAME "vkbd"
  
  #define XENKBD_FIELD_FEAT_ABS_POINTER  "feature-abs-pointer"

+#define XENKBD_FIELD_FEAT_MTOUCH   "feature-multi-touch"
  #define XENKBD_FIELD_REQ_ABS_POINTER   "request-abs-pointer"
+#define XENKBD_FIELD_REQ_MTOUCH"request-multi-touch"
  #define XENKBD_FIELD_RING_GREF "page-gref"
  #define XENKBD_FIELD_EVT_CHANNEL   "event-channel"
  #define XENKBD_FIELD_WIDTH "width"
  #define XENKBD_FIELD_HEIGHT"height"
+#define 

[Xen-devel] [qemu-mainline test] 104296: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuab4b92760498e097ff668f0e9c83aa87a2ec1128
baseline version:
 qemuu23eb9e6b6d5315171cc15969bbc755f258004df0

Last test of basis   104241  2017-01-18 05:52:33 Z2 days
Testing same since   104296  2017-01-19 11:11:54 Z0 days1 attempts


People who touched revisions under test:
  Lluís Vilanova 
  Marc-André Lureau 
  Peter Maydell 
  Stefan Hajnoczi 

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

Re: [Xen-devel] [PATCH v1 1/2] xen/kbdif: update protocol documentation

[Oleksandr Andrushchenko]

On 01/19/2017 08:56 PM, Stefano Stabellini wrote:

On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Signed-off-by: Oleksandr Andrushchenko 
---
  xen/include/public/io/kbdif.h | 248 +-
  1 file changed, 221 insertions(+), 27 deletions(-)

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index 2d2aebdd3f28..c00faa3af5d2 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -26,46 +26,226 @@
  #ifndef __XEN_PUBLIC_IO_KBDIF_H__
  #define __XEN_PUBLIC_IO_KBDIF_H__
  
-/* In events (backend -> frontend) */

+/*
+ *
+ * Feature and Parameter Negotiation
+ *
+ *
+ * The two halves of a para-virtual driver utilize nodes within the

within "XenStore", drop "the"

Aside from this minor this:

Reviewed-by: Stefano Stabellini 

Thanks,
with this change done, can I put your Reviewed-by
into the next version of this patch?



+ * XenStore to communicate capabilities and to negotiate operating parameters.
+ * This section enumerates these nodes which reside in the respective front and
+ * backend portions of XenStore, following XenBus convention.
+ *
+ * All data in XenStore is stored as strings.  Nodes specifying numeric
+ * values are encoded in decimal. Integer value ranges listed below are
+ * expressed as fixed sized integer types capable of storing the conversion
+ * of a properly formated node string, without loss of information.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ * Features supported 
+ *
+ * Capable backend advertises supported features by publishing
+ * corresponding entries in XenStore and puts 1 as the value of the entry.
+ * If a feature is not supported then 0 must be set or feature entry omitted.
+ *
+ * feature-abs-pointer
+ *  Values: 
+ *
+ *  Backends, which support reporting of absolute coordinates for pointer
+ *  device should set this to 1.
+ *
+ *- Pointer Device Parameters 
+ *
+ * width
+ *  Values: 
+ *
+ *  Maximum X coordinate (width) to be used by the frontend
+ *  while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ * height
+ *  Values: 
+ *
+ *  Maximum Y coordinate (height) to be used by the frontend
+ *  while reporting input events, pixels, [0; UINT32_MAX].
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *-- Feature request -
+ *
+ * Capable frontend requests features from backend via setting corresponding
+ * entries to 1 in XenStore. Requests for features not advertised as supported
+ * by the backend have no effect.
+ *
+ * request-abs-pointer
+ *  Values: 
+ *
+ *  Request backend to report absolute pointer coordinates
+ *  (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: 
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * page-gref
+ *  Values: 
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  a sole page in a single page sized event ring buffer.
+ *
+ * page-ref
+ *  Values: 
+ *
+ *  OBSOLETE, not recommended for use.
+ *  PFN of the shared page.
+ */
  
  /*

- * Frontends should ignore unknown in events.
+ * EVENT CODES.
   */
  
-/* Pointer movement event */

-#define XENKBD_TYPE_MOTION  1
-/* Event type 2 currently not used */
-/* Key event (includes pointer buttons) */
-#define XENKBD_TYPE_KEY 3
+#define XENKBD_TYPE_MOTION 1
+#define XENKBD_TYPE_RESERVED   2
+#define XENKBD_TYPE_KEY3
+#define XENKBD_TYPE_POS4
+
  /*
- * Pointer position event
- * Capable backend sets feature-abs-pointer in xenstore.
- * Frontend requests ot instead of XENKBD_TYPE_MOTION by setting
- * request-abs-update in xenstore.
+ * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS.
+ */
+
+#define XENKBD_DRIVER_NAME "vkbd"
+
+#define XENKBD_FIELD_FEAT_ABS_POINTER  "feature-abs-pointer"
+#define XENKBD_FIELD_REQ_ABS_POINTER   "request-abs-pointer"
+#define 

Re: [Xen-devel] [PATCH v5 2/9] x86/iommu: add IOMMU entries for p2m_mmio_direct pages

[Tian, Kevin]

> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: Friday, January 20, 2017 1:30 AM
> 
> There's nothing wrong with allowing the domain to perform DMA transfers to
> MMIO areas that it already can access from the CPU, and this allows us to
> remove the hack in set_identity_p2m_entry for PVH Dom0.
> 
> Signed-off-by: Roger Pau Monné 
[...]
> @@ -840,6 +840,10 @@ static inline unsigned int p2m_get_iommu_flags(p2m_type_t
> p2mt)
>  case p2m_grant_map_ro:
>  flags = IOMMUF_readable;
>  break;
> +case p2m_mmio_direct:
> +flags = IOMMUF_readable;
> +if ( rangeset_contains_singleton(mmio_ro_ranges, mfn_x(mfn)) )
> +flags |= IOMMUF_writable;

I suppose you meant !rangeset_contains_singleton...

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

[Xen-devel] [linux-3.18 test] 104291: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
104271 pass in 104291
 test-armhf-armhf-xl-arndale  11 guest-startfail pass in 104271
 test-amd64-amd64-xl-qemuu-ovmf-amd64 15 guest-localmigrate/x10 fail pass in 
104271
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail pass in 104271
 test-armhf-armhf-libvirt-raw 10 guest-startfail pass in 104271

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 104271 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 104271 never 
pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 104271 never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 104271 never 
pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 linux8433e5c9c8304b750c519ce3e0940dab675f6573
baseline version:
 linux1e20e732ffa107e21f2089ce56e32d99b9229944

Last test of basis   103983  2016-12-28 03:30:38 Z   23 days
Testing same since   104271  2017-01-18 20:47:21 Z1 days2 attempts


People who touched revisions under test:
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Aleksa Sarai 
  Alex Deucher 
  Alex Porosanu 
  Alexander Duyck 
  Andy Grover 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Hutchings 
  Benjamin Marzinski 
  Bjorn Helgaas 
  Bryant G Ly 
  Chandan Rajendra 
  Con Kolivas 
  Con Kolivas 
  Dan Carpenter 
  Dan O'Donovan 
  Daniel Vetter 
  Daniele Palmas 
  Dave Chinner 

Re: [Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

On 1/19/17 8:34 PM, Daniel Kiper wrote:

> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 84cf44d..b8f727a 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S

> -2:  /* Reserve 64kb for the trampoline */
> -sub $0x1000,%ecx
> +/* Reserve memory for the trampoline. */

/* Reserve memory for the trampoline and the low memory stack */

> +sub $((MB_TRAMPOLINE_SIZE+MB_TRAMPOLINE_STACK_SIZE)>>4),%ecx
>  
>  /* From arch/x86/smpboot.c: start_eip had better be page-aligned! */
>  xor %cl, %cl

> diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
> index 62c010e..c1285ad 100644
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h

> @@ -550,7 +551,12 @@ static void __init efi_arch_memory_setup(void)
>  
>  /* Allocate space for trampoline (in first Mb). */
>  cfg.addr = 0x10;
> -cfg.size = trampoline_end - trampoline_start;
> +
> +if ( efi_enabled(EFI_LOADER) )
> +cfg.size = trampoline_end - trampoline_start;
> +else
> +cfg.size = MB_TRAMPOLINE_SIZE + MB_TRAMPOLINE_STACK_SIZE + MBI_SIZE;

Why MBI_SIZE? I don't see that being copied in that region or living there?

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images

[Doug Goldstein]

On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Add multiboot2 protocol support for relocatable images. Only GRUB2 with
> "multiboot2: Add support for relocatable images" patch understands
> that feature. Older multiboot protocol (regardless of version)
> compatible loaders ignore it and everything works as usual.
> 
> Signed-off-by: Daniel Kiper 
> Acked-by: Jan Beulich 
> Reviewed-by: Doug Goldstein 

FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs()

[Doug Goldstein]

On 1/19/17 8:34 PM, Daniel Kiper wrote:
> This way macro name better describes its function.
> Currently it is used to calculate symbol offset in
> relation to the beginning of Xen image mapping.
> However, value returned by sym_offs() for a given
> symbol is not always equal its physical address.
> 
> There is no functional change.
> 
> Suggested-by: Jan Beulich 
> Signed-off-by: Daniel Kiper 
> Acked-by: Jan Beulich 
> Reviewed-by: Doug Goldstein 

FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of...

[Doug Goldstein]

On 1/19/17 8:34 PM, Daniel Kiper wrote:
> ..calculating its value during runtime.
> 
> Signed-off-by: Daniel Kiper 
> Acked-by: Jan Beulich 
> Reviewed-by: Doug Goldstein 

FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB

[Doug Goldstein]

On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Subsequent patches introducing relocatable early boot code play with
> page tables using 2 MiB huge pages. If load address is not aligned at
> 2 MiB then code touching such page tables must have special cases for
> start and end of Xen image memory region. So, let's make life easier
> and move default load address from 1 MiB to 2 MiB. This way page table
> code will be nice and easy. Hence, there is a chance that it will be
> less error prone too... :-)))
> 
> Additionally, drop first 2 MiB mapping from Xen image mapping.
> It is no longer needed.
> 
> Signed-off-by: Daniel Kiper 
> Reviewed-by: Jan Beulich 
> Reviewed-by: Doug Goldstein 

FWIW, I can't find where I offered my R-b for this patch. Its part of
the series I've said fails on my hardware.

-- 
Doug Goldstein



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm 18 leak-check/check fail REGR. vs. 104223

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  12ec20c732a63f26dc243a847343b8b796c2d88c
baseline version:
 xen  5ad98e3c7fa92f46d77a788e1109b7d282bd1256

Last test of basis   104223  2017-01-17 19:14:55 Z2 days
Failing since104236  2017-01-18 04:20:35 Z1 days3 attempts
Testing same since   104290  2017-01-19 09:21:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Eric DeVolder 
  George Dunlap 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  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
 

Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

On Thu, Jan 19, 2017 at 09:25:08AM -0500, Doug Goldstein wrote:
> On 1/19/17 6:56 AM, Daniel Kiper wrote:
> >> Can you tell me what were the fixes to the relocation code?
> >
> > Unfortunately I have not received any details from you. Just vague
> > statements that it does not work. So, I am not able to say anything
> > about that. If you provide more details I am happy to help.
>
> We discussed this on your original v11 thread. It fails on Intel NUCs,
> Lenovo T430, Dell PowerEdge something (I'm on vacation so I can't see
> the model number), HP Proliant ML10, QEMU (with OVMF) and some other

Do you use QEMU with KVM enabled? I was hit twice by an issue (I do not
remember the detail right now) when OVMF was running in KVM. When I disabled
KVM then everything worked without any issue. It does not happen often but...

> broads that I don't remember the model number off of my head. Its about
> a dozen machines all together. They fail in two different ways:
>
> - the other CPUs are reported as stuck and the machine boots but 'xl
> info' reports 1 available CPU.
> - when the non-CPUs are brought up it dies when setting paging back into
> cr0.
>
> Every single machine fails in one of these two ways.

Hmmm... I have not seen that anywhere. And nobody except you reported such
issue. Is it happening with GRUB2 and/or iPXE?

Anyway, I have just released v12. It contains various fixes including
yours. I hope that I have not missed anything. Please take a look.

In the meantime I will try to find one of machines mentioned above and
reproduce this issue there.

Daniel

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

[Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Daniel Kiper]

Hi,

I am sending twelfth version of multiboot2 protocol support for
legacy BIOS and EFI platforms. This patch series release contains
fixes for all known/confirmed issues.

The final goal is xen.efi binary file which could be loaded by EFI
loader, multiboot (v1) protocol (only on legacy BIOS platforms) and
multiboot2 protocol. This way we will have:
  - smaller Xen code base,
  - one code base for xen.gz and xen.efi,
  - one build method for xen.gz and xen.efi;
xen.efi will be extracted from xen(-syms)
file using objcopy or special custom tool,
  - xen.efi build will not so strongly depend
on a given GCC and binutils version.

Here is short list of changes since v11:
  - changed patches: 02, 05, 08, 10.

Patch "x86/boot: implement early command line parser in C" was moved
to the beginning of this patch series. It was requested by Jan.

If you are not interested in this patch series at all please
drop me a line and I will remove you from distribution list.

Daniel

 .gitignore|5 +-
 xen/arch/x86/Makefile |6 +-
 xen/arch/x86/Rules.mk |3 +
 xen/arch/x86/boot/Makefile|   12 +-
 xen/arch/x86/boot/build32.mk  |2 +
 xen/arch/x86/boot/cmdline.S   |  367 
---
 xen/arch/x86/boot/cmdline.c   |  340 
+++
 xen/arch/x86/boot/defs.h  |   58 +
 xen/arch/x86/boot/edd.S   |3 -
 xen/arch/x86/boot/head.S  |  543 
++
 xen/arch/x86/boot/reloc.c |  151 +--
 xen/arch/x86/boot/trampoline.S|   22 +++-
 xen/arch/x86/boot/video.S |7 --
 xen/arch/x86/boot/wakeup.S|4 +-
 xen/arch/x86/boot/x86_64.S|   44 +++
 xen/arch/x86/efi/Makefile |   12 +-
 xen/arch/x86/efi/efi-boot.h   |   72 ---
 xen/arch/x86/efi/stub.c   |   38 ++
 xen/arch/x86/setup.c  |   24 ++--
 xen/arch/x86/x86_64/asm-offsets.c |   15 +++
 xen/arch/x86/xen.lds.S|   13 +-
 xen/common/efi/boot.c |   64 ++
 xen/common/efi/runtime.c  |9 ++
 xen/include/asm-x86/config.h  |5 +
 xen/include/asm-x86/page.h|2 +-
 xen/include/xen/config.h  |1 +
 xen/include/xen/multiboot2.h  |  182 
 27 files changed, 1491 insertions(+), 513 deletions(-)

Daniel Kiper (10):
  x86/boot: implement early command line parser in C
  x86: add multiboot2 protocol support
  efi: build xen.gz with EFI code
  efi: create new early memory allocator
  x86: add multiboot2 protocol support for EFI platforms
  x86: change default load address from 1 MiB to 2 MiB
  x86/setup: use XEN_IMG_OFFSET instead of...
  x86: make Xen early boot code relocatable
  x86/boot: rename sym_phys() to sym_offs()
  x86: add multiboot2 protocol support for relocatable images


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

[Xen-devel] [PATCH v12 09/10] x86/boot: rename sym_phys() to sym_offs()

[Daniel Kiper]

This way macro name better describes its function.
Currently it is used to calculate symbol offset in
relation to the beginning of Xen image mapping.
However, value returned by sym_offs() for a given
symbol is not always equal its physical address.

There is no functional change.

Suggested-by: Jan Beulich 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v8 - suggestions/fixes:
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S   |   38 +++---
 xen/arch/x86/boot/trampoline.S |2 +-
 xen/arch/x86/boot/wakeup.S |4 ++--
 xen/arch/x86/boot/x86_64.S |   18 +-
 4 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index f94a4ac..bbc7cdd 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -12,9 +12,9 @@
 .text
 .code32
 
-#define sym_phys(sym) ((sym) - __XEN_VIRT_START)
-#define sym_esi(sym)  sym_phys(sym)(%esi)
-#define sym_fs(sym)   %fs:sym_phys(sym)
+#define sym_offs(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_offs(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_offs(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
@@ -97,7 +97,7 @@ multiboot2_header_start:
 
 /* EFI64 Multiboot2 entry point. */
 mb2ht_init MB2_HT(ENTRY_ADDRESS_EFI64), MB2_HT(OPTIONAL), \
-   sym_phys(__efi64_mb2_start)
+   sym_offs(__efi64_mb2_start)
 
 /* Multiboot2 header end tag. */
 mb2ht_init MB2_HT(END), MB2_HT(REQUIRED)
@@ -110,7 +110,7 @@ multiboot2_header_start:
 gdt_boot_descr:
 .word   7*8-1
 gdt_boot_base:
-.long   sym_phys(trampoline_gdt)
+.long   sym_offs(trampoline_gdt)
 .long   0 /* Needed for 64-bit lgdt */
 
 .align 4
@@ -130,23 +130,23 @@ efi_platform:
 .section .init.text, "ax", @progbits
 
 bad_cpu:
-add $sym_phys(.Lbad_cpu_msg),%esi   # Error message
+add $sym_offs(.Lbad_cpu_msg),%esi   # Error message
 jmp .Lget_vtb
 not_multiboot:
-add $sym_phys(.Lbad_ldr_msg),%esi   # Error message
+add $sym_offs(.Lbad_ldr_msg),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_st:
-add $sym_phys(.Lbad_ldr_nst),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nst),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_ih:
-add $sym_phys(.Lbad_ldr_nih),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nih),%esi   # Error message
 jmp .Lget_vtb
 .Lmb2_no_bs:
-add $sym_phys(.Lbad_ldr_nbs),%esi   # Error message
+add $sym_offs(.Lbad_ldr_nbs),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lmb2_efi_ia_32:
-add $sym_phys(.Lbad_efi_msg),%esi   # Error message
+add $sym_offs(.Lbad_efi_msg),%esi   # Error message
 xor %edi,%edi   # No VGA text buffer
 jmp .Lsend_chr
 .Lget_vtb:
@@ -351,7 +351,7 @@ __start:
 cli
 
 /* Load default Xen image load base address. */
-mov $sym_phys(__image_base__),%esi
+mov $sym_offs(__image_base__),%esi
 
 /* Bootloaders may set multiboot{1,2}.mem_lower to a nonzero value. */
 xor %edx,%edx
@@ -502,8 +502,8 @@ trampoline_setup:
 jnz 1f
 
 /* Initialize BSS (no nasty surprises!). */
-mov $sym_phys(__bss_start),%edi
-mov $sym_phys(__bss_end),%ecx
+mov $sym_offs(__bss_start),%edi
+mov $sym_offs(__bss_end),%ecx
 push%fs
 pop %es
 sub %edi,%ecx
@@ -576,22 +576,22 @@ trampoline_setup:
 
 /* Apply relocations to bootstrap trampoline. */
 mov sym_fs(trampoline_phys),%edx
-mov $sym_phys(__trampoline_rel_start),%edi
+mov $sym_offs(__trampoline_rel_start),%edi
 1:
 mov %fs:(%edi),%eax
 add %edx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_rel_stop),%edi
+cmp $sym_offs(__trampoline_rel_stop),%edi
 jb  1b
 
 /* Patch in the trampoline segment. */
 shr $4,%edx
-mov $sym_phys(__trampoline_seg_start),%edi
+mov $sym_offs(__trampoline_seg_start),%edi
 1:
 mov %fs:(%edi),%eax
 mov %dx,%fs:(%edi,%eax)
 add $4,%edi
-cmp $sym_phys(__trampoline_seg_stop),%edi
+cmp $sym_offs(__trampoline_seg_stop),%edi
 jb  1b
 
 /* Do not parse command line on EFI platform here. */
@@ -617,7 +617,7 @@ trampoline_setup:
 push%eax
 
 /* Copy bootstrap 

[Xen-devel] [PATCH v12 08/10] x86: make Xen early boot code relocatable

[Daniel Kiper]

Every multiboot protocol (regardless of version) compatible image must
specify its load address (in ELF or multiboot header). Multiboot protocol
compatible loader have to load image at specified address. However, there
is no guarantee that the requested memory region (in case of Xen it starts
at 2 MiB and ends at ~5 MiB) where image should be loaded initially is a RAM
and it is free (legacy BIOS platforms are merciful for Xen but I found at
least one EFI platform on which Xen load address conflicts with EFI boot
services; it is Dell PowerEdge R820 with latest firmware). To cope with that
problem we must make Xen early boot code relocatable and help boot loader to
relocate image in proper way by suggesting, not requesting specific load
addresses as it is right now, allowed address ranges. This patch does former.
It does not add multiboot2 protocol interface which is done in "x86: add
multiboot2 protocol support for relocatable images" patch.

This patch changes following things:
  - %esi register is used as a storage for Xen image load base address;
it is mostly unused in early boot code and preserved during C functions
calls in 32-bit mode,
  - %fs is used as base for Xen data relative addressing in 32-bit code
if it is possible; %esi is used for that thing during error printing
because it is not always possible to properly and efficiently
initialize %fs.

Signed-off-by: Daniel Kiper 
---
v12 - suggestions/fixes:
- store Xen image load base address directly into %esi,
- store Xen image load base address after x86_32_switch
  (suggested by Doug Goldstein),
- improve commit message.

v8 - suggestions/fixes:
   - use shld instead of mov and shr in BOOT_FS segment
 descriptor base address initialization
 (suggested by Jan Beulich),
   - simplify code updating frame addresses in page tables
 (suggested by Jan Beulich),
   - print Xen image base addresses using "%#lx" format
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - leave static mapping of first
 16 MiB in l2_identmap as is
 (suggested by Jan Beulich),
   - use xen_phys_start instead of xen_img_load_base_addr
 (suggested by Daniel Kiper and Jan Beulich),
   - simplify BOOT_FS segment descriptor
 base address initialization
 (suggested by Jan Beulich),
   - fix BOOT_FS segment limit
 (suggested by Jan Beulich),
   - do not rename sym_phys in this patch
 (suggested by Jan Beulich),
   - rename esi_offset/fs_offset to
 sym_esi/sym_fs respectively
 (suggested by Jan Beulich),
   - use add instead of lea in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not relocate Xen image if boot loader did work for us
 (suggested by Andrew Cooper and Jan Beulich),
   - initialize xen_img_load_base_addr in EFI boot code too,
   - properly initialize trampoline_xen_phys_start,
   - calculate Xen image load base address in
 x86_64 code ourselves,
 (suggested by Jan Beulich),
   - change how and when Xen image base address is printed,
   - use %fs instead of %esi for relative addressing
 (suggested by Andrew Cooper and Jan Beulich),
   - create esi_offset and fs_offset() macros in assembly,
   - calculate  mkelf32 argument automatically,
   - optimize and cleanup code,
   - improve comments,
   - improve commit message.

v3 - suggestions/fixes:
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - simplify Xen image load base address calculation
 (suggested by Jan Beulich),
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - use %esi instead of %fs for relative addressing;
 this way we get shorter and simpler code,
   - rename some variables and constants
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/head.S  |  157 +
 xen/arch/x86/boot/trampoline.S|5 ++
 xen/arch/x86/boot/x86_64.S|   21 +++--
 xen/arch/x86/setup.c  |   14 ++--
 xen/arch/x86/x86_64/asm-offsets.c |3 +
 xen/include/asm-x86/page.h|2 +-
 6 files changed, 152 insertions(+), 50 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 22bd68d..f94a4ac 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -13,12 +13,15 @@
 .code32
 
 #define sym_phys(sym) ((sym) - __XEN_VIRT_START)
+#define sym_esi(sym)  sym_phys(sym)(%esi)
+#define sym_fs(sym)   %fs:sym_phys(sym)
 
 #define BOOT_CS320x0008
 #define BOOT_CS640x0010
 

[Xen-devel] [PATCH v12 01/10] x86/boot: implement early command line parser in C

[Daniel Kiper]

Current early command line parser implementation in assembler
is very difficult to change to relocatable stuff using segment
registers. This requires a lot of changes in very weird and
fragile code. So, reimplement this functionality in C. This
way code will be relocatable out of the box (without playing
with segment registers) and much easier to maintain.

Additionally, put all common cmdline.c and reloc.c definitions
into defs.h header. This way we do not duplicate needlessly
some stuff.

And finally remove unused xen/include/asm-x86/config.h
header from reloc.c dependencies.

Suggested-by: Andrew Cooper 
Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v7 - suggestions/fixes:
   - add min() macro
 (suggested by Jan Beulich),
   - add padding to early_boot_opts_t
 in more standard way
 (suggested by Jan Beulich),
   - simplify defs.h dependencies
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - put common cmdline.c and reloc.c
 definitions into defs.h header
 (suggested by Jan Beulich),
   - use xen/include/xen/stdbool.h
 and bool type from it instead
 of own defined bool_t
 (suggested by Jan Beulich),
   - define delim_chars as constant
 (suggested by Jan Beulich),
   - properly align trampoline.S:early_boot_opts struct
 (suggested by Jan Beulich),
   - fix overflow check in strtoui()
 (suggested by Jan Beulich),
   - remove unused xen/include/asm-x86/config.h
 header from reloc.c dependencies,
   - improve commit message.

v4 - suggestions/fixes:
   - move to stdcall calling convention
 (suggested by Jan Beulich),
   - define bool_t and use it properly
 (suggested by Jan Beulich),
   - put list of delimiter chars into
 static const char[]
 (suggested by Jan Beulich),
   - use strlen() instead of strlen_opt()
 (suggested by Jan Beulich),
   - change strtoi() to strtoui() and
 optimize it a bit
 (suggested by Jan Beulich),
   - define strchr() and use it in strtoui()
 (suggested by Jan Beulich),
   - optimize vga_parse()
 (suggested by Jan Beulich),
   - move !cmdline check from assembly to C
 (suggested by Jan Beulich),
   - remove my name from copyright (Oracle requirement)
 (suggested by Konrad Rzeszutek Wilk).

v3 - suggestions/fixes:
   - optimize some code
 (suggested by Jan Beulich),
   - put VESA data into early_boot_opts_t members
 (suggested by Jan Beulich),
   - rename some functions and variables
 (suggested by Jan Beulich),
   - move around video.h include in xen/arch/x86/boot/trampoline.S
 (suggested by Jan Beulich),
   - fix coding style
 (suggested by Jan Beulich),
   - fix build with older GCC
 (suggested by Konrad Rzeszutek Wilk),
   - remove redundant comments
 (suggested by Jan Beulich),
   - add some comments
   - improve commit message
 (suggested by Jan Beulich).
---
 .gitignore |5 +-
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/boot/Makefile |   11 +-
 xen/arch/x86/boot/build32.mk   |2 +
 xen/arch/x86/boot/cmdline.S|  367 
 xen/arch/x86/boot/cmdline.c|  340 +
 xen/arch/x86/boot/defs.h   |   58 +++
 xen/arch/x86/boot/edd.S|3 -
 xen/arch/x86/boot/head.S   |9 +
 xen/arch/x86/boot/reloc.c  |9 +-
 xen/arch/x86/boot/trampoline.S |   15 ++
 xen/arch/x86/boot/video.S  |7 -
 12 files changed, 438 insertions(+), 390 deletions(-)
 delete mode 100644 xen/arch/x86/boot/cmdline.S
 create mode 100644 xen/arch/x86/boot/cmdline.c
 create mode 100644 xen/arch/x86/boot/defs.h

diff --git a/.gitignore b/.gitignore
index 7689596..f41c3d0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -252,9 +252,10 @@ xen/arch/arm/xen.lds
 xen/arch/x86/asm-offsets.s
 xen/arch/x86/boot/mkelf32
 xen/arch/x86/xen.lds
+xen/arch/x86/boot/cmdline.S
 xen/arch/x86/boot/reloc.S
-xen/arch/x86/boot/reloc.bin
-xen/arch/x86/boot/reloc.lnk
+xen/arch/x86/boot/*.bin
+xen/arch/x86/boot/*.lnk
 xen/arch/x86/efi.lds
 xen/arch/x86/efi/check.efi
 xen/arch/x86/efi/disabled
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 7f6b5d7..007dced 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -220,5 +220,5 @@ clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
-   rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+   rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
index 5fdb5ae..6d20646 100644
--- a/xen/arch/x86/boot/Makefile
+++ b/xen/arch/x86/boot/Makefile
@@ -1,8 +1,15 @@
 obj-bin-y += head.o
 
-RELOC_DEPS = 

[Xen-devel] [PATCH v12 04/10] efi: create new early memory allocator

[Daniel Kiper]

There is a problem with place_string() which is used as early memory
allocator. It gets memory chunks starting from start symbol and goes
down. Sadly this does not work when Xen is loaded using multiboot2
protocol because then the start lives on 1 MiB address and we should
not allocate a memory from below of it. So, I tried to use mem_lower
address calculated by GRUB2. However, this solution works only on some
machines. There are machines in the wild (e.g. Dell PowerEdge R820)
which uses first ~640 KiB for boot services code or data... :-(((
Hence, we need new memory allocator for Xen EFI boot code which is
quite simple and generic and could be used by place_string() and
efi_arch_allocate_mmap_buffer(). I think about following solutions:

1) We could use native EFI allocation functions (e.g. AllocatePool()
   or AllocatePages()) to get memory chunk. However, later (somewhere
   in __start_xen()) we must copy its contents to safe place or reserve
   it in e820 memory map and map it in Xen virtual address space. This
   means that the code referring to Xen command line, loaded modules and
   EFI memory map, mostly in __start_xen(), will be further complicated
   and diverge from legacy BIOS cases. Additionally, both former things
   have to be placed below 4 GiB because their addresses are stored in
   multiboot_info_t structure which has 32-bit relevant members.

2) We may allocate memory area statically somewhere in Xen code which
   could be used as memory pool for early dynamic allocations. Looks
   quite simple. Additionally, it would not depend on EFI at all and
   could be used on legacy BIOS platforms if we need it. However, we
   must carefully choose size of this pool. We do not want increase Xen
   binary size too much and waste too much memory but also we must fit
   at least memory map on x86 EFI platforms. As I saw on small machine,
   e.g. IBM System x3550 M2 with 8 GiB RAM, memory map may contain more
   than 200 entries. Every entry on x86-64 platform is 40 bytes in size.
   So, it means that we need more than 8 KiB for EFI memory map only.
   Additionally, if we use this memory pool for Xen and modules command
   line storage (it would be used when xen.efi is executed as EFI application)
   then we should add, I think, about 1 KiB. In this case, to be on safe
   side, we should assume at least 64 KiB pool for early memory allocations.
   Which is about 4 times of our earlier calculations. However, during
   discussion on Xen-devel Jan Beulich suggested that just in case we should
   use 1 MiB memory pool like it is in original place_string() implementation.
   So, let's use 1 MiB as it was proposed. If we think that we should not
   waste unallocated memory in the pool on running system then we can mark
   this region as __initdata and move all required data to dynamically
   allocated places somewhere in __start_xen().

2a) We could put memory pool into .bss.page_aligned section. Then allocate
memory chunks starting from the lowest address. After init phase we can
free unused portion of the memory pool as in case of .init.text or 
.init.data
sections. This way we do not need to allocate any space in image file and
freeing of unused area in the memory pool is very simple.

Now #2a solution is implemented because it is quite simple and requires
limited number of changes, especially in __start_xen().

New allocator is quite generic and can be used on ARM platforms too.
Though it is not enabled on ARM yet due to lack of some prereq.
List of them is placed before ebmalloc code.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Acked-by: Julien Grall 
Reviewed-by: Doug Goldstein 
---
v11 - suggestions/fixes:
- #ifdef only EBMALLOC_SIZE from ebmalloc machinery
  (suggested by Jan Beulich).

v10 - suggestions/fixes:
- remove unneeded ARM free_ebmalloc_unused_mem() stub.

v9 - suggestions/fixes:
   - call free_ebmalloc_unused_mem() from efi_init_memory()
 instead of xen/arch/arm/setup.c:init_done()
 (suggested by Jan Beulich),
   - improve comments.

v8 - suggestions/fixes:
   - disable whole ebmalloc machinery on ARM platforms,
   - add comment saying what should be done before
 enabling ebmalloc on ARM,
 (suggested by Julien Grall),
   - move ebmalloc code before efi-boot.h inclusion and
 remove unneeded forward declaration
 (suggested by Jan Beulich),
   - remove free_ebmalloc_unused_mem() call from
 xen/arch/arm/setup.c:init_done()
 (suggested by Julien Grall),
   - improve commit message.

v7 - suggestions/fixes:
   - enable most of ebmalloc machinery on ARM platforms
 (suggested by Jan Beulich),
   - remove unneeded cast
 (suggested by Jan Beulich),
   - wrap long line
 (suggested by Jan Beulich),
   - improve commit message.

v6 - suggestions/fixes:
   - optimize ebmalloc allocator,
   - move ebmalloc machinery to 

[Xen-devel] [PATCH v12 02/10] x86: add multiboot2 protocol support

[Daniel Kiper]

Add multiboot2 protocol support. Alter min memory limit handling as we
now may not find it from either multiboot (v1) or multiboot2.

This way we are laying the foundation for EFI + GRUB2 + Xen development.

Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
  (suggested by Doug Goldstein).

v9 - suggestions/fixes:
   - use .L label instead of numeric one in multiboot2 data scanning loop;
 I hope that this change does not invalidate Jan's Reviewed-by
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use sizeof(/) instead of sizeof()
 if it is possible
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - rename mbi_mbi/mbi2_mbi to mbi_reloc/mbi2_reloc respectively
 (suggested by Jan Beulich),
   - initialize mbi_out->flags using "|=" instead of "="
 (suggested by Jan Beulich),
   - use sizeof(*mmap_dst) instead of sizeof(memory_map_t)
 if it makes sense
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - do not index mbi_out_mods[] beyond its end
 (suggested by Andrew Cooper),
   - reduce number of casts
 (suggested by Andrew Cooper and Jan Beulich),
   - add braces to increase code readability
 (suggested by Andrew Cooper).

v5 - suggestions/fixes:
   - check multiboot2_tag_mmap_t.entry_size before
 multiboot2_tag_mmap_t.entries[] use
 (suggested by Jan Beulich),
   - properly index multiboot2_tag_mmap_t.entries[]
 (suggested by Jan Beulich),
   - use "type name[]" instad of "type name[0]"
 in xen/include/xen/multiboot2.h
 (suggested by Jan Beulich),
   - remove unneeded comment
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - avoid assembly usage in xen/arch/x86/boot/reloc.c,
   - fix boundary check issue and optimize
 for() loops in mbi2_mbi(),
   - move to stdcall calling convention,
   - remove unneeded typeof() from ALIGN_UP() macro
 (suggested by Jan Beulich),
   - add and use NULL definition in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - add :req to some .macro arguments
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - add .L to multiboot2_header_end label
 (suggested by Jan Beulich),
   - add .L to multiboot2_proto label
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - reorder reloc() arguments
 (suggested by Jan Beulich),
   - remove .L from multiboot2 header labels
 (suggested by Andrew Cooper, Jan Beulich and Konrad Rzeszutek Wilk),
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - create modules data if modules count != 0
 (suggested by Jan Beulich),
   - improve macros
 (suggested by Jan Beulich),
   - reduce number of casts
 (suggested by Jan Beulich),
   - use const if possible
 (suggested by Jan Beulich),
   - drop static and __used__ attribute from reloc()
 (suggested by Jan Beulich),
   - remove isolated/stray __packed attribute from
 multiboot2_memory_map_t type definition
 (suggested by Jan Beulich),
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments
 (suggested by Konrad Rzeszutek Wilk),
   - remove hard tabs
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - simplify assembly in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - do not include include/xen/compiler.h
 in xen/arch/x86/boot/reloc.c
 (suggested by Jan Beulich),
   - do not read data beyond the end of multiboot2 information
 (suggested by Jan Beulich).

v2 - not fixed yet:
   - dynamic dependency generation for xen/arch/x86/boot/reloc.S;
 this requires more work; I am not sure that it pays because
 potential patch requires more changes than addition of just
 multiboot2.h to Makefile
 (suggested by Jan Beulich),
   - isolated/stray __packed attribute usage for multiboot2_memory_map_t
 (suggested by Jan Beulich).
---
 xen/arch/x86/boot/Makefile|3 +-
 xen/arch/x86/boot/head.S  |  107 ++-
 xen/arch/x86/boot/reloc.c |  144 +--
 xen/arch/x86/x86_64/asm-offsets.c |9 ++
 xen/include/xen/multiboot2.h  |  169 +
 5 files changed, 422 insertions(+), 10 deletions(-)
 create mode 100644 xen/include/xen/multiboot2.h

diff --git 

[Xen-devel] [PATCH v12 10/10] x86: add multiboot2 protocol support for relocatable images

[Daniel Kiper]

Add multiboot2 protocol support for relocatable images. Only GRUB2 with
"multiboot2: Add support for relocatable images" patch understands
that feature. Older multiboot protocol (regardless of version)
compatible loaders ignore it and everything works as usual.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v12 - suggestions/fixes:
- replace TABs with spaces in xen/include/xen/multiboot2.h
  (suggested by Doug Goldstein).

v9 - suggestions/fixes:
   - use .L labels instead of numeric ones in multiboot2 data scanning loop
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - do not get Xen image load base address from
 multiboot2 information in x86_64 code
 (suggested by Jan Beulich),
   - improve label names
 (suggested by Jan Beulich),
   - improve comments,
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - use %esi and %r15d instead of %ebp to store
 Xen image load base address,
   - rename some types and constants,
   - reformat xen/include/xen/multiboot2.h
 (suggested by Konrad Rzeszutek Wilk),
   - improve comments,
   - improve commit message
 (suggested by Konrad Rzeszutek Wilk).
---
 xen/arch/x86/boot/head.S  |   16 
 xen/arch/x86/x86_64/asm-offsets.c |1 +
 xen/include/xen/multiboot2.h  |   13 +
 3 files changed, 30 insertions(+)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index bbc7cdd..fd0238b 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -82,6 +82,13 @@ multiboot2_header_start:
 /* Align modules at page boundry. */
 mb2ht_init MB2_HT(MODULE_ALIGN), MB2_HT(REQUIRED)
 
+/* Load address preference. */
+mb2ht_init MB2_HT(RELOCATABLE), MB2_HT(OPTIONAL), \
+   sym_offs(start), /* Min load address. */ \
+   0x, /* The end of image max load address (4 GiB - 
1). */ \
+   0x20, /* Load address alignment (2 MiB). */ \
+   MULTIBOOT2_LOAD_PREFERENCE_HIGH
+
 /* Console flags tag. */
 mb2ht_init MB2_HT(CONSOLE_FLAGS), MB2_HT(OPTIONAL), \
MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED
@@ -383,6 +390,15 @@ __start:
 cmp %edi,MB2_fixed_total_size(%ebx)
 jbe trampoline_bios_setup
 
+/* Get Xen image load base address from Multiboot2 information. */
+cmpl$MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR,MB2_tag_type(%ecx)
+jne .Lmb2_mem_lower
+
+mov MB2_load_base_addr(%ecx),%esi
+sub $XEN_IMG_OFFSET,%esi
+jmp .Lmb2_next_tag
+
+.Lmb2_mem_lower:
 /* Get mem_lower from Multiboot2 information. */
 cmpl$MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO,MB2_tag_type(%ecx)
 cmove   MB2_mem_lower(%ecx),%edx
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 87e573a..85639e4 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -174,6 +174,7 @@ void __dummy__(void)
 OFFSET(MB2_fixed_total_size, multiboot2_fixed_t, total_size);
 OFFSET(MB2_tag_type, multiboot2_tag_t, type);
 OFFSET(MB2_tag_size, multiboot2_tag_t, size);
+OFFSET(MB2_load_base_addr, multiboot2_tag_load_base_addr_t, 
load_base_addr);
 OFFSET(MB2_mem_lower, multiboot2_tag_basic_meminfo_t, mem_lower);
 OFFSET(MB2_efi64_st, multiboot2_tag_efi64_t, pointer);
 OFFSET(MB2_efi64_ih, multiboot2_tag_efi64_ih_t, pointer);
diff --git a/xen/include/xen/multiboot2.h b/xen/include/xen/multiboot2.h
index a3e3119..5acd225 100644
--- a/xen/include/xen/multiboot2.h
+++ b/xen/include/xen/multiboot2.h
@@ -59,11 +59,17 @@
 #define MULTIBOOT2_HEADER_TAG_EFI_BS7
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI32   8
 #define MULTIBOOT2_HEADER_TAG_ENTRY_ADDRESS_EFI64   9
+#define MULTIBOOT2_HEADER_TAG_RELOCATABLE   10
 
 /* Header tag flags. */
 #define MULTIBOOT2_HEADER_TAG_REQUIRED  0
 #define MULTIBOOT2_HEADER_TAG_OPTIONAL  1
 
+/* Where image should be loaded (suggestion not requirement). */
+#define MULTIBOOT2_LOAD_PREFERENCE_NONE 0
+#define MULTIBOOT2_LOAD_PREFERENCE_LOW  1
+#define MULTIBOOT2_LOAD_PREFERENCE_HIGH 2
+
 /* Header console tag console_flags. */
 #define MULTIBOOT2_CONSOLE_FLAGS_CONSOLE_REQUIRED   1
 #define MULTIBOOT2_CONSOLE_FLAGS_EGA_TEXT_SUPPORTED 2
@@ -90,6 +96,7 @@
 #define MULTIBOOT2_TAG_TYPE_EFI_BS  18
 #define MULTIBOOT2_TAG_TYPE_EFI32_IH19
 #define MULTIBOOT2_TAG_TYPE_EFI64_IH20
+#define MULTIBOOT2_TAG_TYPE_LOAD_BASE_ADDR  21
 
 /* Multiboot 2 tag alignment. */
 #define MULTIBOOT2_TAG_ALIGN8
@@ -120,6 +127,12 @@ typedef struct {
 typedef struct {
 u32 

[Xen-devel] [PATCH v12 06/10] x86: change default load address from 1 MiB to 2 MiB

[Daniel Kiper]

Subsequent patches introducing relocatable early boot code play with
page tables using 2 MiB huge pages. If load address is not aligned at
2 MiB then code touching such page tables must have special cases for
start and end of Xen image memory region. So, let's make life easier
and move default load address from 1 MiB to 2 MiB. This way page table
code will be nice and easy. Hence, there is a chance that it will be
less error prone too... :-)))

Additionally, drop first 2 MiB mapping from Xen image mapping.
It is no longer needed.

Signed-off-by: Daniel Kiper 
Reviewed-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v8 - suggestions/fixes:
   - drop first 2 MiB mapping from Xen image mapping
 (suggested by Jan Beulich),
   - improve commit message.

v7 - suggestions/fixes:
   - minor cleanups
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile  |2 +-
 xen/arch/x86/Rules.mk  |3 +++
 xen/arch/x86/boot/head.S   |8 
 xen/arch/x86/boot/x86_64.S |5 +++--
 xen/arch/x86/setup.c   |3 ++-
 xen/arch/x86/xen.lds.S |2 +-
 6 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 08e9f7b..e5b840e 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -90,7 +90,7 @@ all_symbols =
 endif
 
 $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
-   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 0x10 \
+   ./boot/mkelf32 $(notes_phdrs) $(TARGET)-syms $(TARGET) 
$(XEN_IMG_OFFSET) \
   `$(NM) $(TARGET)-syms | sed -ne 's/^\([^ ]*\) . 
__2M_rwdata_end$$/0x\1/p'`
 
 ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o 
$(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
index 42be4bc..36e6386 100644
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -1,9 +1,12 @@
 
 # x86-specific definitions
 
+XEN_IMG_OFFSET := 0x20
+
 CFLAGS += -I$(BASEDIR)/include
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
 CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
+CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
 CFLAGS += '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$(subst 
$(BASEDIR)/,,$(CURDIR))/$@))'
 
 # Prevent floating-point variables from creeping into Xen.
diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index b8f727a..22bd68d 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -482,14 +482,6 @@ trampoline_setup:
 mov %eax,sym_phys(boot_tsc_stamp)
 mov %edx,sym_phys(boot_tsc_stamp+4)
 
-/*
- * During boot, hook 4kB mappings of first 2MB of memory into L2.
- * This avoids mixing cachability for the legacy VGA region, and is
- * corrected when Xen relocates itself.
- */
-mov $sym_phys(l1_identmap)+__PAGE_HYPERVISOR,%edi
-mov %edi,sym_phys(l2_xenmap)
-
 /* Apply relocations to bootstrap trampoline. */
 mov sym_phys(trampoline_phys),%edx
 mov $sym_phys(__trampoline_rel_start),%edi
diff --git a/xen/arch/x86/boot/x86_64.S b/xen/arch/x86/boot/x86_64.S
index 139b2ca..7890374 100644
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/boot/x86_64.S
@@ -121,8 +121,9 @@ GLOBAL(l2_identmap)
  * page.
  */
 GLOBAL(l2_xenmap)
-idx = 0
-.rept 8
+.quad 0
+idx = 1
+.rept 7
 .quad sym_phys(__image_base__) + (idx << L2_PAGETABLE_SHIFT) + 
(PAGE_HYPERVISOR | _PAGE_PSE)
 idx = idx + 1
 .endr
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d4b7d25..e6f6ef1 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -999,7 +999,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * Undo the temporary-hooking of the l1_identmap.  __2M_text_start
  * is contained in this PTE.
  */
-BUG_ON(l2_table_offset((unsigned long)_erodata) ==
+BUG_ON(using_2M_mapping() &&
+   l2_table_offset((unsigned long)_erodata) ==
l2_table_offset((unsigned long)_stext));
 *pl2e++ = l2e_from_pfn(xen_phys_start >> PAGE_SHIFT,
PAGE_HYPERVISOR_RX | _PAGE_PSE);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 3a02b2b..f9cdfc1 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -55,7 +55,7 @@ SECTIONS
   __2M_text_start = .; /* Start of 2M superpages, mapped RX. */
 #endif
 
-  . = __XEN_VIRT_START + MB(1);
+  . = __XEN_VIRT_START + XEN_IMG_OFFSET;
   _start = .;
   .text : {
 _stext = .;/* Text and read-only data */
-- 
1.7.10.4


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

[Xen-devel] [PATCH v12 05/10] x86: add multiboot2 protocol support for EFI platforms

[Daniel Kiper]

This way Xen can be loaded on EFI platforms using GRUB2 and
other boot loaders which support multiboot2 protocol.

Signed-off-by: Daniel Kiper 
---
v12 - suggestions/fixes:
- rename __efi64_start to __efi64_mb2_start
  (suggested by Andrew Cooper),
- use efi_arch_memory_setup() machinery as trampoline
  et consortes main memory allocator
  (suggested by Doug Goldstein),
- allocate space for mbi struct in efi_arch_memory_setup() too;
  this thing was not taken into account in earlier releases,
- revert trampoline et consortes fallback memory allocator code
  in efi_arch_process_memory_map() to current upstream state
  (suggested by Doug Goldstein),
- further simplify efi_arch_pre_exit_boot() code,
- call efi_arch_memory_setup() from efi_multiboot2()
  (suggested by Doug Goldstein),
- fix asembly call argument in xen/arch/x86/efi/stub.c
  (suggested by Andrew Cooper),
- add ASSERT() for trampoline size
  (suggested by Doug Goldstein),
- add KB() macro
  (suggested by Doug Goldstein),
- improve comments
  (suggested by Andrew Cooper and Doug Goldstein).

v10 - suggestions/fixes:
- replace ljmpl with lretq
  (suggested by Andrew Cooper),
- introduce efi_platform to increase code readability
  (suggested by Andrew Cooper).

v9 - suggestions/fixes:
   - use .L labels instead of numeric ones in multiboot2 data scanning loops
 (suggested by Jan Beulich).

v8 - suggestions/fixes:
   - use __bss_start(%rip)/__bss_end(%rip) instead of
 of .startof.(.bss)(%rip)/$.sizeof.(.bss) because
 latter is not tested extensively in different
 built environments yet
 (suggested by Andrew Cooper),
   - fix multiboot2 data scanning loop in x86_32 code
 (suggested by Jan Beulich),
   - add check for extra mem for mbi data if Xen is loaded
 via multiboot2 protocol on EFI platform
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v7 - suggestions/fixes:
   - do not allocate twice memory for trampoline if we were
 loaded via multiboot2 protocol on EFI platform,
   - wrap long line
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich).

v6 - suggestions/fixes:
   - improve label names in assembly
 error printing code
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups and fixes
 (suggested by Jan Beulich).

v4 - suggestions/fixes:
   - remove redundant BSS alignment,
   - update BSS alignment check,
   - use __set_bit() instead of set_bit() if possible
 (suggested by Jan Beulich),
   - call efi_arch_cpu() from efi_multiboot2()
 even if the same work is done later in
 other place right now
 (suggested by Jan Beulich),
   - xen/arch/x86/efi/stub.c:efi_multiboot2()
 fail properly on EFI platforms,
   - do not read data beyond the end of multiboot2
 information in xen/arch/x86/boot/head.S
 (suggested by Jan Beulich),
   - use 32-bit registers in x86_64 code if possible
 (suggested by Jan Beulich),
   - multiboot2 information address is 64-bit
 in x86_64 code, so, treat it is as is
 (suggested by Jan Beulich),
   - use cmovcc if possible,
   - leave only one space between rep and stosq
 (suggested by Jan Beulich),
   - improve error handling,
   - improve early error messages,
 (suggested by Jan Beulich),
   - improve early error messages printing code,
   - improve label names
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - various minor cleanups.

v3 - suggestions/fixes:
   - take into account alignment when skipping multiboot2 fixed part
 (suggested by Konrad Rzeszutek Wilk),
   - improve segment registers initialization
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich and Konrad Rzeszutek Wilk),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - generate multiboot2 header using macros
 (suggested by Jan Beulich),
   - switch CPU to x86_32 mode before
 jumping to 32-bit code
 (suggested by Andrew Cooper),
   - reduce code changes to increase patch readability
 (suggested by Jan Beulich),
   - improve comments
 (suggested by Jan Beulich),
   - ignore MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO tag on EFI platform
 and find on my own multiboot2.mem_lower value,
   - stop execution if EFI platform is detected
 in legacy BIOS path.
---
 xen/arch/x86/boot/head.S  |  268 ++---
 xen/arch/x86/efi/efi-boot.h   |   61 -
 xen/arch/x86/efi/stub.c   |   38 ++
 xen/arch/x86/x86_64/asm-offsets.c |2 +
 xen/arch/x86/xen.lds.S|7 +-
 xen/common/efi/boot.c |   11 ++
 xen/include/asm-x86/config.h  |5 +
 xen/include/xen/config.h  |1 +
 8 files changed, 366 

[Xen-devel] [PATCH v12 07/10] x86/setup: use XEN_IMG_OFFSET instead of...

[Daniel Kiper]

..calculating its value during runtime.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
 xen/arch/x86/setup.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index e6f6ef1..24b4b23 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -943,7 +943,6 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 l4_pgentry_t *pl4e;
 l3_pgentry_t *pl3e;
 l2_pgentry_t *pl2e;
-uint64_t load_start;
 int i, j, k;
 
 /* Select relocation address. */
@@ -957,9 +956,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * with a barrier(). After this we must *not* modify static/global
  * data until after we have switched to the relocated pagetables!
  */
-load_start = (unsigned long)_start - XEN_VIRT_START;
 barrier();
-move_memory(e + load_start, load_start, _end - _start, 1);
+move_memory(e + XEN_IMG_OFFSET, XEN_IMG_OFFSET, _end - _start, 1);
 
 /* Walk initial pagetables, relocating page directory entries. */
 pl4e = __va(__pa(idle_pg_table));
-- 
1.7.10.4


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

[Xen-devel] [PATCH v12 03/10] efi: build xen.gz with EFI code

[Daniel Kiper]

Build xen.gz with EFI code. We need this to support multiboot2
protocol on EFI platforms.

If we wish to load non-ELF file using multiboot (v1) or multiboot2 then
it must contain "linear" (or "flat") representation of code and data.
This is requirement of both boot protocols. Currently, PE file contains
many sections which are not "linear" (one after another without any holes)
or even do not have representation in a file (e.g. BSS). From EFI point
of view everything is OK and works. However, this file layout cannot be
properly interpreted by multiboot protocols family. In theory there is
a chance that we could build proper PE file (from multiboot protocols POV)
using current build system. However, it means that xen.efi further diverge
from Xen ELF file (in terms of contents and build method). On the other
hand ELF has all needed properties. So, it means that this is good starting
point for further development. Additionally, I think that this is also good
starting point for further xen.efi code and build optimizations. It looks
that there is a chance that finally we can generate xen.efi directly from
Xen ELF using just simple objcopy or other tool. This way we will have one
Xen binary which can be loaded by three boot protocols: EFI native loader,
multiboot (v1) and multiboot2.

Signed-off-by: Daniel Kiper 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 
---
v6 - suggestions/fixes:
   - improve efi_enabled() checks in efi_runtime_call()
 (suggested by Jan Beulich).

v5 - suggestions/fixes:
   - properly calculate efi symbol address in
 xen/arch/x86/xen.lds.S (I hope that this
 change does not invalidate Jan's ACK).

v4 - suggestions/fixes:
   - functions should return -ENOSYS instead
 of -EOPNOTSUPP if EFI runtime services
 are not available
 (suggested by Jan Beulich),
   - remove stale bits from xen/arch/x86/Makefile
 (suggested by Jan Beulich).

v3 - suggestions/fixes:
   - check for EFI platform in EFI code
 (suggested by Jan Beulich),
   - fix Makefiles
 (suggested by Jan Beulich),
   - improve commit message
 (suggested by Jan Beulich).

v2 - suggestions/fixes:
   - build EFI code only if it is supported in a given build environment
 (suggested by Jan Beulich).
---
 xen/arch/x86/Makefile |2 +-
 xen/arch/x86/efi/Makefile |   12 
 xen/arch/x86/xen.lds.S|4 ++--
 xen/common/efi/boot.c |3 +++
 xen/common/efi/runtime.c  |9 +
 5 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 007dced..08e9f7b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -219,6 +219,6 @@ efi/mkreloc: efi/mkreloc.c
 clean::
rm -f asm-offsets.s *.lds boot/*.o boot/*~ boot/core boot/mkelf32
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
-   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi 
efi/disabled efi/mkreloc
+   rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.efi efi/disabled efi/mkreloc
rm -f boot/cmdline.S boot/reloc.S boot/*.lnk boot/*.bin
rm -f note.o
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index ad3fdf7..442f3fc 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -1,18 +1,14 @@
 CFLAGS += -fshort-wchar
 
-obj-y += stub.o
-
-create = test -e $(1) || touch -t 19990101 $(1)
-
 efi := y$(shell rm -f disabled)
 efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c 
check.c 2>disabled && echo y))
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
-efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
-
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+efi := $(if $(efi),$(shell rm disabled)y)
 
 %.o: %.ihex
$(OBJCOPY) -I ihex -O binary $< $@
 
-stub.o: $(extra-y)
+obj-y := stub.o
+obj-$(efi) := boot.init.o compat.o relocs-dummy.o runtime.o
+extra-$(efi) += buildid.o
 nogcov-$(efi) += stub.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 7676de9..b0b1c9b 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,10 +270,10 @@ SECTIONS
   .pad : {
 . = ALIGN(MB(16));
   } :text
-#else
-  efi = .;
 #endif
 
+  efi = DEFINED(efi) ? efi : .;
+
   /* Sections to be discarded */
   /DISCARD/ : {
*(.exit.text)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index 3e5e4ab..df8c702 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -1251,6 +1251,9 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif
 
+if ( !efi_enabled(EFI_BOOT) )
+return;
+
 printk(XENLOG_INFO "EFI memory map:%s\n",
map_bs ? " (mapping BootServices)" : "");
 for ( i = 0; i < efi_memmap_size; i += efi_mdesc_size )
diff --git a/xen/common/efi/runtime.c 

Re: [Xen-devel] [PATCH] swiotlb-xen: update dev_addr after swapping pages

[Stefano Stabellini]

On Thu, 19 Jan 2017, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 19, 2017 at 06:58:46PM -0500, Boris Ostrovsky wrote:
> > On 01/19/2017 01:39 PM, Stefano Stabellini wrote:
> > > In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
> > > page is not suitable, we swap it for another page from the swiotlb 
> > > pool.
> > >
> > > In these cases, we don't update the previously calculated dma address
> > > for the page before calling xen_dma_map_page. Thus, we end up calling
> > > xen_dma_map_page passing the wrong dev_addr, resulting in
> > > xen_dma_map_page mistakenly assuming that the page is foreign when it is
> > > local.
> > >
> > > Fix the bug by updating dev_addr appropriately.
> > >
> > > This change has no effect on x86, because xen_dma_map_page is a stub
> > > there.
> > >
> > > Signed-off-by: Stefano Stabellini 
> > > Signed-off-by: Pooya Keshavarzi 
> > > Tested-by: Pooya Keshavarzi 
> > 
> > Reviewed-by: Boris Ostrovsky 
> 
> Acked-by: Konrad Rzeszutek Wilk 
> 
> I can carry it via my swiotlb.git tree or if there are some extra
> things on the Xen tree - it can go through that?

It might be best to go via swiotlb.git: I don't think we have anything
on the Xen tree at the moment -- Juergen has just sent a pull request
for it.

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

Re: [Xen-devel] [PATCH] swiotlb-xen: update dev_addr after swapping pages

[Konrad Rzeszutek Wilk]

On Thu, Jan 19, 2017 at 06:58:46PM -0500, Boris Ostrovsky wrote:
> On 01/19/2017 01:39 PM, Stefano Stabellini wrote:
> > In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
> > page is not suitable, we swap it for another page from the swiotlb 
> > pool.
> >
> > In these cases, we don't update the previously calculated dma address
> > for the page before calling xen_dma_map_page. Thus, we end up calling
> > xen_dma_map_page passing the wrong dev_addr, resulting in
> > xen_dma_map_page mistakenly assuming that the page is foreign when it is
> > local.
> >
> > Fix the bug by updating dev_addr appropriately.
> >
> > This change has no effect on x86, because xen_dma_map_page is a stub
> > there.
> >
> > Signed-off-by: Stefano Stabellini 
> > Signed-off-by: Pooya Keshavarzi 
> > Tested-by: Pooya Keshavarzi 
> 
> Reviewed-by: Boris Ostrovsky 

Acked-by: Konrad Rzeszutek Wilk 

I can carry it via my swiotlb.git tree or if there are some extra
things on the Xen tree - it can go through that?

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

Re: [Xen-devel] [PATCH] swiotlb-xen: update dev_addr after swapping pages

[Boris Ostrovsky]

On 01/19/2017 01:39 PM, Stefano Stabellini wrote:
> In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
> page is not suitable, we swap it for another page from the swiotlb 
> pool.
>
> In these cases, we don't update the previously calculated dma address
> for the page before calling xen_dma_map_page. Thus, we end up calling
> xen_dma_map_page passing the wrong dev_addr, resulting in
> xen_dma_map_page mistakenly assuming that the page is foreign when it is
> local.
>
> Fix the bug by updating dev_addr appropriately.
>
> This change has no effect on x86, because xen_dma_map_page is a stub
> there.
>
> Signed-off-by: Stefano Stabellini 
> Signed-off-by: Pooya Keshavarzi 
> Tested-by: Pooya Keshavarzi 

Reviewed-by: Boris Ostrovsky 

>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index f905d6e..f8afc6d 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -414,9 +414,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, 
> struct page *page,
>   if (map == SWIOTLB_MAP_ERROR)
>   return DMA_ERROR_CODE;
>  
> + dev_addr = xen_phys_to_bus(map);
>   xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
>   dev_addr, map & ~PAGE_MASK, size, dir, 
> attrs);
> - dev_addr = xen_phys_to_bus(map);
>  
>   /*
>* Ensure that the address returned is DMA'ble
> @@ -575,13 +575,14 @@ void xen_swiotlb_unmap_page(struct device *hwdev, 
> dma_addr_t dev_addr,

Interesting that git diff picked xen_swiotlb_unmap_page() here instead
of xen_swiotlb_map_sg_attrs()

-boris

 

>   sg_dma_len(sgl) = 0;
>   return 0;
>   }
> + dev_addr = xen_phys_to_bus(map);
>   xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
>   dev_addr,
>   map & ~PAGE_MASK,
>   sg->length,
>   dir,
>   attrs);
> - sg->dma_address = xen_phys_to_bus(map);
> + sg->dma_address = dev_addr;
>   } else {
>   /* we are not interested in the dma_addr returned by
>* xen_dma_map_page, only in the potential cache 
> flushes executed


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

[Xen-devel] [ovmf baseline-only test] 68398: tolerable trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i3863 host-install(3)   broken baseline untested
 build-amd64   3 host-install(3)   broken baseline untested
 build-i386-pvops  3 host-install(3)   broken baseline untested
 build-i386-xsm3 host-install(3)   broken baseline untested
 build-amd64-pvops 3 host-install(3)   broken baseline untested
 build-amd64-xsm   3 host-install(3)   broken baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 5ab0ffc9f64f5a539a9bdb50446b7fbf92b845d6
baseline version:
 ovmf 88fd27e5b2cae68ff5a11cd5560ef5f98d001c42

Last test of basis68395  2017-01-19 05:18:18 Z0 days
Testing same since68398  2017-01-19 17:19:17 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

broken-step build-i386 host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386-pvops host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)
broken-step build-amd64-xsm host-install(3)

Push not applicable.


commit 5ab0ffc9f64f5a539a9bdb50446b7fbf92b845d6
Author: Star Zeng 
Date:   Fri Jan 13 16:14:54 2017 +0800

ShellPkg SmbiosView: Add missing decoding of SlotType AGP8X

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=344

SlotType AGP8X was added in SMBIOS spec 2.3.4, but the decoding
of it is missing. I found it when I am adding SMBIOS spec 3.1.0
support.

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

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

Re: [Xen-devel] xennet_start_xmit assumptions

[Sowmini Varadhan]

On (01/19/17 13:47), Sowmini Varadhan wrote:
> > Specifically I'm talking about the dev_validate_header() check.
> > That is supposed to protect us from these kinds of situations.
> 
> ah, but I run my pf_packet application as root, so I have 
> capable(CAP_SYS_RAWIO), so I slip through the dev_validate_header()
> check.

and in that light, should dev_validate_header()
always return false if len == 0?

that will take care of all the send paths in af_packet.c
but it impacts all drivers as well (even though it is the
logically correct thing to do..)

--Sowmini


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

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

[Stefano Stabellini]

On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/include/public/io/kbdif.h | 216 
> ++
>  1 file changed, 216 insertions(+)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index c00faa3af5d2..8d8ba9af1cb1 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -57,6 +57,12 @@
>   *  Backends, which support reporting of absolute coordinates for pointer
>   *  device should set this to 1.
>   *
> + * feature-multi-touch
> + *  Values: 
> + *
> + *  Backends, which support reporting of multi-touch events
> + *  should set this to 1.
> + *
>   *- Pointer Device Parameters 
> 
>   *
>   * width
> @@ -87,6 +93,11 @@
>   *  Request backend to report absolute pointer coordinates
>   *  (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
>   *
> + * request-multi-touch
> + *  Values: 
> + *
> + *  Request backend to report multi-touch events.
> + *
>   *--- Request Transport Parameters 
> ---
>   *
>   * event-channel
> @@ -106,6 +117,30 @@
>   *
>   *  OBSOLETE, not recommended for use.
>   *  PFN of the shared page.
> + *
> + *--- Multi-touch Device Parameters 
> ---
> + *
> + * Every multi-touch input device uses a dedicated event frontend/backend
> + * connection configured via XenStore properties under
> + * XENKBD_PATH_MTOUCH folder. 

This sentence doesn't seem to match the rest of the patch: it looks
like multi-touch devices use the same ring and evtchn used by the
pointer and keyboard.

Also, it is not clear whether multiple multitouch devices are supported
with a single frontend/backend connection (as you described in
http://marc.info/?l=xen-devel=148412731428686) or not. Please clarify.

If only one device is supported, do we need a XENKBD_PATH_MTOUCH folder?



> The values below are per emulated multi-touch
> + * input device:
> + *
> + * num-contacts
> + *  Values: 
> + *
> + *  Number of simultaneous touches reported.
> + *
> + * width
> + *  Values: 
> + *
> + *  Width of the touch area to be used by the frontend
> + *  while reporting input events, pixels, [0; UINT32_MAX].
> + *
> + * height
> + *  Values: 
> + *
> + *  Height of the touch area to be used by the frontend
> + *  while reporting input events, pixels, [0; UINT32_MAX].
>   */
>  
>  /*
> @@ -116,6 +151,16 @@
>  #define XENKBD_TYPE_RESERVED   2
>  #define XENKBD_TYPE_KEY3
>  #define XENKBD_TYPE_POS4
> +#define XENKBD_TYPE_MTOUCH 5
> +
> +/* Multi-touch event sub-codes */
> +
> +#define XENKBD_MT_EV_DOWN  0
> +#define XENKBD_MT_EV_UP1
> +#define XENKBD_MT_EV_MOTION2
> +#define XENKBD_MT_EV_SYN   3
> +#define XENKBD_MT_EV_SHAPE 4
> +#define XENKBD_MT_EV_ORIENT5
>  
>  /*
>   * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS.
> @@ -124,11 +169,17 @@
>  #define XENKBD_DRIVER_NAME "vkbd"
>  
>  #define XENKBD_FIELD_FEAT_ABS_POINTER  "feature-abs-pointer"
> +#define XENKBD_FIELD_FEAT_MTOUCH   "feature-multi-touch"
>  #define XENKBD_FIELD_REQ_ABS_POINTER   "request-abs-pointer"
> +#define XENKBD_FIELD_REQ_MTOUCH"request-multi-touch"
>  #define XENKBD_FIELD_RING_GREF "page-gref"
>  #define XENKBD_FIELD_EVT_CHANNEL   "event-channel"
>  #define XENKBD_FIELD_WIDTH "width"
>  #define XENKBD_FIELD_HEIGHT"height"
> +#define XENKBD_FIELD_NUM_CONTACTS  "num-contacts"
> +
> +/* Path entries */
> +#define XENKBD_PATH_MTOUCH "mtouch"
>  
>  /* OBSOLETE, not recommended for use */
>  #define XENKBD_FIELD_RING_REF  "page-ref"
> @@ -248,6 +299,170 @@ struct xenkbd_position
>  int32_t rel_z;
>  };
>  
> +/*
> + * Multi-touch event and its sub-types
> + *
> + * All multi-touch event packets have common header:
> + *
> + * 01 2   3octet
> + * +++++
> + * |  _TYPE_MTOUCH  |   event_type   |   contact_id   |reserved| 4
> + * +++++
> + * | reserved  | 8
> + * +++++
> + *
> + * event_type - unt8_t, multi-touch event sub-type, XENKBD_MT_EV_???
> + * contact_id - unt8_t, ID of the contact

If multiple devices are supported, don't we need a per multitouch device
ID to identify the source?


> + * Touch interactions can 

Re: [Xen-devel] [PATCH 2/2] xen/kbdif: add multi-touch support

[Stefano Stabellini]

On Wed, 11 Jan 2017, Oleksandr Andrushchenko wrote:
> On 01/11/2017 02:29 AM, Stefano Stabellini wrote:
> > On Tue, 10 Jan 2017, Oleksandr Andrushchenko wrote:
> > > On 01/07/2017 12:37 AM, Stefano Stabellini wrote:
> > > > On Fri, 6 Jan 2017, Oleksandr Andrushchenko wrote:
> > > > > From: Oleksandr Andrushchenko 
> > > > > 
> > > > > Signed-off-by: Oleksandr Andrushchenko
> > > > > 
> > > > > ---
> > > > >xen/include/public/io/kbdif.h | 228
> > > > > ++
> > > > >1 file changed, 228 insertions(+)
> > > > > 
> > > > > diff --git a/xen/include/public/io/kbdif.h
> > > > > b/xen/include/public/io/kbdif.h
> > > > > index 0e19a40..1b446f9 100644
> > > > > --- a/xen/include/public/io/kbdif.h
> > > > > +++ b/xen/include/public/io/kbdif.h
> > > > > @@ -57,6 +57,12 @@
> > > > > *  Backends, which support reporting of absolute coordinates
> > > > > for
> > > > > pointer
> > > > > *  device should set this to 1.
> > > > > *
> > > > > + * feature-multi-touch
> > > > > + *  Values: 
> > > > > + *
> > > > > + *  Backends, which support reporting of multi-touch events
> > > > > + *  should set this to 1.
> > > > > + *
> > > > > *- Pointer Device Parameters
> > > > > 
> > > > > *
> > > > > * width
> > > > > @@ -87,6 +93,11 @@
> > > > > *  Request from backend to report absolute pointer coordinates
> > > > > *  (XENKBD_TYPE_POS) instead of relative ones
> > > > > (XENKBD_TYPE_MOTION).
> > > > > *
> > > > > + * request-multi-touch
> > > > > + *  Values: 
> > > > > + *
> > > > > + *  Request from backend to report multi-touch events.
> > > > I think in English should be "request backend to report multi-touch
> > > > events". Same above.
> > > Done
> > > > > + *
> > > > > *--- Request Transport Parameters
> > > > > ---
> > > > > *
> > > > > * event-channel
> > > > > @@ -107,6 +118,43 @@
> > > > > *  OBSOLETE, not recommended for use.
> > > > > *  A unique (within the guest domain given) value identifying
> > > > > event
> > > > > *  channel and page reference pair.
> > > > > + *
> > > > > + *--- Multi-touch Device Parameters
> > > > > ---
> > > > > + *
> > > > > + * Every multi-touch input device uses a dedicated event ring and is
> > > > For clarity I would say "Every multi-touch input device uses a dedicated
> > > > frontend/backend connection". That includes a ring, an event channel,
> > > > and xenstore entries.
> > > > 
> > > Done
> > > > > + * configured via XenStore properties under XENKBD_PATH_MTOUCH
> > > > > folder.
> > > > I don't understand why we need a new xenstore folder. Why do we need
> > > > XENKBD_PATH_MTOUCH?
> > > This is just another (IMO, cleaner) approach to define
> > > properties in XenStore for multiple instances.
> > > Let's see what vif does on my PC:
> > > /local/domain/11/device/vif/0/queue-0/tx-ring-ref = "2304"
> > > ...
> > > /local/domain/11/device/vif/0/queue-1/tx-ring-ref = "2306"
> > > ...
> > > /local/domain/11/device/vif/0/queue-2/tx-ring-ref = "2308"
> > > ...
> > > /local/domain/11/device/vif/0/queue-3/tx-ring-ref = "2310"
> > > ...
> > > /local/domain/11/device/vif/0/request-rx-copy = "1"
> > > 
> > > We have folders "queue-%d" per queue which in my case are
> > > 
> > > under XENKBD_PATH_MTOUCH.
> > > 
> > > /local/domain/11/device/vkbd/0/mtouch/0/width = "3200"
> > > /local/domain/11/device/vkbd/0/mtouch/0/height = "3200"
> > > /local/domain/11/device/vkbd/0/mtouch/0/num-contacts = "5"
> > > /local/domain/11/device/vkbd/0/mtouch/1/width = "6400"
> > > /local/domain/11/device/vkbd/0/mtouch/1/height = "6400"
> > > /local/domain/11/device/vkbd/0/mtouch/1/num-contacts = "10"
> > > 
> > > Namely, instead of "mtouch-%d" I use "mtouch/%d/.
> > > This is just like using "/local/domain/%d" but not
> > > "/local/domain-%d", so "mtouch/%d" seem to be more
> > > consistent.
> > I agree that mtouch/%d is better than mtouch-%d, but it's only necessary
> > if we have more than one mtouch per vkbd. I would configure it so that
> > one can only have one mtouch per vkbd:
> > 
> >/local/domain/11/device/vkbd/0/mtouch/width = "3200"
> >/local/domain/11/device/vkbd/0/mtouch/height = "3200"
> >/local/domain/11/device/vkbd/1/mtouch/width = "6400"
> >/local/domain/11/device/vkbd/1/mtouch/height = "6400"
> correct me if I'm wrong, but this notation implies
> multiple drivers support, not a single driver with
> multiple devices.
> If so, *DISCLAIMER* *Linux* I see no simple solution to
> do that in the front driver.
> Could you please clarify?

I am not familiar with the multitouch driver infrastructure in Linux.
Why is it easier to advertise multiple multitouch devices under a single
xenstore connection? I would have thought it 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 59254
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 59254
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumprun-i386  3 host-install(3)   broken baseline untested
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot   fail baseline untested
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail baseline untested
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail baseline untested
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linuxfb1d8e0e2c50f374cfc244564decfc3f0a336cb4
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  560 days
Failing since 59348  2015-07-10 04:24:05 Z  559 days  218 attempts
Testing same since   104282  2017-01-19 04:22:15 Z0 days1 attempts


7505 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsfail
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl  fail
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  

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

[Boris Ostrovsky]

>
> So I can see 2 solutions:
> 1) Increase the timeout
> 2) Only build the kernel on the Arndales. Though they are known to
> be unreliable in the colo :/
>
> Any opinions?

I'd vote for (1). Alternatively we could cross-compile on an x86 box.

-boris


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

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

[Julien Grall]

Hi,

On 19/01/2017 20:15, Boris Ostrovsky wrote:



So this appears to be a pretty slow, 2-core box:

[ 0.049778] SMP: Total of 2 processors activated (96.00 BogoMIPS).


For comparison, my (old-ish) phone is 4 x 26 BogoMIPS. So it's
theoretically faster than this server.


The ARM32 platforms we have in the colo are not server but development 
board :). Some of them are based on early revision of cores and can be 
really really really really ... slow.




-boris



Julien --- how does 2.5 hours for kernel build sound to you? (make -j4
all modules)


I would not be surprised that it takes 2.5 hours for a make allmodules 
on both the Cubietruck and Arndale.


I have looked at the Linux-3.18 test flights, I know that this thread is 
linux-linus but not other flight log can be found. So surprisingly the 
time betwen the last two flights of Linus 3.18 has doubled (see [1] and 
[2]).


The major difference is a Cubietruck is used on the latest version and a 
Arndale on the previous one. I am be surprised that the Cubietruck is 
slower than the Arndale. Oh well..


The interesting bit is the build time on the Cubietruck is very close to 
the threshold. It is likely that the latest kernel have more modules to 
build which increased the time to build.


So I can see 2 solutions:
1) Increase the timeout
	2) Only build the kernel on the Arndales. Though they are known to be 
unreliable in the colo :/


Any opinions?

Cheers,

[1] 
http://logs.test-lab.xenproject.org/osstest/logs/104271/build-armhf-pvops/info.html
[2] 
http://logs.test-lab.xenproject.org/osstest/logs/103983/build-armhf-pvops/info.html


--
Julien Grall

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

[Xen-devel] [distros-debian-wheezy test] 68397: trouble: blocked/broken

[Platform Team regression test user]

flight 68397 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68397/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 68362
 build-armhf   3 host-install(3) broken REGR. vs. 68362
 build-i3863 host-install(3) broken REGR. vs. 68362
 build-amd64   3 host-install(3) broken REGR. vs. 68362
 build-i386-pvops  3 host-install(3) broken REGR. vs. 68362
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 68362

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a

baseline version:
 flight   68362

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

[Julien Grall]

Hello,

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

On Thu, 19 Jan 2017, Roger Pau Monné wrote:

On Wed, Jan 18, 2017 at 07:13:23PM +, Julien Grall wrote:

Hi,

On 18/01/17 19:05, Stefano Stabellini wrote:

On Wed, 18 Jan 2017, Roger Pau Monné wrote:

On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:

a) One option is to provide a Xen specific implementation of
acpi_os_ioremap in Linux. I think this is the cleanest approach, but
unfortunately, it doesn't cover cases where ioremap is used directly. (2)
is one of such cases, see
arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
see drivers/acpi/apei/bert.c:bert_init.


This is basically the same as b) from Xen's PoV, the only difference is where
you would call the hypercall from Dom0 to establish stage-2 mappings.


Right, but it is important from the Linux point of view, this is why I
am asking the Linux maintainers.



b) Otherwise, we could write an alternative implementation of ioremap
on arm64. The Xen specific ioremap would request a stage-2 mapping
first, then create the stage-1 mapping as usual. However, this means
issuing an hypercall for every ioremap call.


This seems fine to me, and at present is the only way to get something working.
As you said not being able to discover OperationRegions from Xen means that
there's a chance some MMIO might not be added to the stage-2 mappings.

Then what's the initial memory map state when Dom0 is booted? There are no MMIO
mappings at all, and Dom0 must request mappings for everything?


Yes


To give more context here, the UEFI memory map does not report all the MMIO
regions. So there is no possibility to map MMIO at boot.


I've been able to get a Dom0 booting on x86 by mapping all the regions marked
as ACPI in the memory map, plus the BARs of PCI devices and the MCFG areas.


But how do you find the BAR? Is it by reading the BAR from the config 
space when a PCI is added?


Also, you are assuming that the MCFG will describe the host controller. 
This is the case only when host controller available at boot. So you may 
miss some here.


Furthermore, on ARM we have other static tables (such as GTDT) contain 
MMIO region to map.


Lastly, all devices are not PCI and you may have platform devices. The 
platform devices will only be described in the ASL. Just in case, those 
regions are not necessarily described in UEFI memory map.


So you need DOM0 to tell the list of regions.


But
this is not really optimal, since as Stefano says:

 1. If there are new tables that contain memory regions that should be mapped to
   Dom0, Xen will need to be updated in order to work on those systems.
 2. ATM it's not possible for Xen to know all the OperationRegions described in
   the ACPI DSDT/SSDT tables.

I'm not that worried about 1, since the user will also need a newish Dom0
kernel in order to access those devices, and it doesn't seem like new ACPI
tables appear out of the blue everyday. It however puts more pressure on Xen in
order to aggressively track ACPI changes.

In order to fix 2 an AML parser would need to be added to Xen.


This brings me to another possible solution: we could map everything
beforehand in Xen as you wrote, then use a), an alternative
implementation of acpi_os_ioremap, to fix problem 2.
In this scheme, 1. remains unfixed.


This solution will not work on ARM (see why above). It is not the first 
time we have this discussion, so it is probably time to document in the 
tree how ACPI is working with Xen on ARM/x86. This would avoid us to 
come back again in the future on why an hypercall from Dom0 is required 
to map MMIO.




I think this is suboptimal, but it is a possibility.



What happens to ACPI tables crafted for Dom0 that reside in RAM? That would
apply to the STAO and to the other tables that are crafted for Dom0 at build
time. Should Dom0 also request stage-2 mappings for them, and Xen simply ignore
those calls?


The ACPI (and UEFI) tables are mapped by Xen


I think Royger's point is DOM0 cannot tell whether a region has been mapped
by Xen or not.

The function ioremap will be used to map anything (it is the leaf of all
mapping functions), and will call Xen no matter the address passed. It could
be a RAM region, HW device region, emulated device region.


Exactly, from a guest OS PoV it would request those mappings for all device
memory regions. But from Xen's perspective, those request might be made against
at least 3 different types of p2m regions:

 - Regions trapped by emulated devices inside of Xen: no direct MMIO mapping
   should be established in this case.
 - RAM regions that belong to Xen-crafted ACPI tables (STAO, MADT...).
 - Real MMIO regions that should be passed through.

Right now AFAIK Xen doesn't track any of this information, so we would need
additional non-trivial logic in order to account for all this inside the
hypervisor.


I think this is something we'll have 

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

[Boris Ostrovsky]

> So this appears to be a pretty slow, 2-core box:
>
> [ 0.049778] SMP: Total of 2 processors activated (96.00 BogoMIPS).

For comparison, my (old-ish) phone is 4 x 26 BogoMIPS. So it's
theoretically faster than this server.

-boris

>
> Julien --- how does 2.5 hours for kernel build sound to you? (make -j4
> all modules)
>
>
> -boris
>
>
>


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

[Xen-devel] [PATCH 0/2] Fix and adjustment to tools/fuzz

[Wei Liu]

Wei Liu (2):
  tools/fuzz: fix compilation after 897129d
  tools/fuzz: make sure targets are always built

 tools/fuzz/Makefile  | 6 ++
 tools/fuzz/libelf/Makefile   | 3 +++
 tools/fuzz/x86_instruction_emulator/Makefile | 5 -
 3 files changed, 9 insertions(+), 5 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] tools/fuzz: fix compilation after 897129d

[Wei Liu]

We need to add -D__XEN_TOOLS__ so that the correct register names are
generated.

Signed-off-by: Wei Liu 
---
 tools/fuzz/x86_instruction_emulator/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index a97f507..505de39 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -14,7 +14,7 @@ x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h:
 x86_emulate.c x86_emulate.h: %:
[ -L $* ] || ln -sf $(XEN_ROOT)/tools/tests/x86_emulator/$*
 
-CFLAGS += $(CFLAGS_xeninclude)
+CFLAGS += $(CFLAGS_xeninclude) -D__XEN_TOOLS__
 
 x86_emulate.o: x86_emulate.c x86_emulate.h x86_emulate/x86_emulate.c 
x86_emulate/x86_emulate.h
 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] tools/fuzz: make sure targets are always built

[Wei Liu]

Invocation of `make' in top-level directory would end up invoking the
install target.

Adjust fuzzing target makefiles a bit so that they are always build in
that situation.

Signed-off-by: Wei Liu 
---
 tools/fuzz/Makefile  | 6 ++
 tools/fuzz/libelf/Makefile   | 3 +++
 tools/fuzz/x86_instruction_emulator/Makefile | 3 +++
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/tools/fuzz/Makefile b/tools/fuzz/Makefile
index ce00b82..986fbb8 100644
--- a/tools/fuzz/Makefile
+++ b/tools/fuzz/Makefile
@@ -5,7 +5,5 @@ SUBDIRS-y :=
 SUBDIRS-y += libelf
 SUBDIRS-y += x86_instruction_emulator
 
-.PHONY: all clean distclean
-all clean distclean: %: subdirs-%
-
-install:
+.PHONY: all clean distclean install
+all clean distclean install: %: subdirs-%
diff --git a/tools/fuzz/libelf/Makefile b/tools/fuzz/libelf/Makefile
index 0e9d40a..c73ce44 100644
--- a/tools/fuzz/libelf/Makefile
+++ b/tools/fuzz/libelf/Makefile
@@ -29,3 +29,6 @@ distclean: clean
 .PHONY: clean
 clean:
rm -f *.o *.a
+
+.PHONY: install
+install: all
diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index 505de39..20431b0 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -34,3 +34,6 @@ distclean: clean
 .PHONY: clean
 clean:
rm -f *.a *.o
+
+.PHONY: install
+install: all
-- 
2.1.4


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

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

[Boris Ostrovsky]

On 01/19/2017 01:07 PM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237: 
> regressions - FAIL"):
>> On 01/18/2017 10:05 AM, osstest service owner wrote:
>>>  build-armhf-pvops 5 kernel-build  fail REGR. vs. 
>>> 59254
>> ARM build seems to be caused by some sort of a timeout. The script
>> allows about 2.5 hours for the build to complete and it looks like it is
>> close to finishing it. Hard to say why it takes that long but I see no
>> build errors --- IIUIC the build is aborted due to the timeout.
> 2.5 hours!  How long should it take do you think ?

I don't have much experience with ARM HW but on my x86_64 desktop it's
under 5 minutes. Of course, we may have different config files but still...

And those 2.5 hours is almost all for the actual build --- from what I
see git clones are done pretty quickly.

>
> I mean, I can increase the timeout, but this already seems quite
> unreasonable.

So this appears to be a pretty slow, 2-core box:

[ 0.049778] SMP: Total of 2 processors activated (96.00 BogoMIPS).

Julien --- how does 2.5 hours for kernel build sound to you? (make -j4
all modules)


-boris




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

Re: [Xen-devel] [PATCH v1 1/2] xen/kbdif: update protocol documentation

[Stefano Stabellini]

On Thu, 19 Jan 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/include/public/io/kbdif.h | 248 
> +-
>  1 file changed, 221 insertions(+), 27 deletions(-)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 2d2aebdd3f28..c00faa3af5d2 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -26,46 +26,226 @@
>  #ifndef __XEN_PUBLIC_IO_KBDIF_H__
>  #define __XEN_PUBLIC_IO_KBDIF_H__
>  
> -/* In events (backend -> frontend) */
> +/*
> + 
> *
> + * Feature and Parameter Negotiation
> + 
> *
> + *
> + * The two halves of a para-virtual driver utilize nodes within the

within "XenStore", drop "the"

Aside from this minor this:

Reviewed-by: Stefano Stabellini 


> + * XenStore to communicate capabilities and to negotiate operating 
> parameters.
> + * This section enumerates these nodes which reside in the respective front 
> and
> + * backend portions of XenStore, following XenBus convention.
> + *
> + * All data in XenStore is stored as strings.  Nodes specifying numeric
> + * values are encoded in decimal. Integer value ranges listed below are
> + * expressed as fixed sized integer types capable of storing the conversion
> + * of a properly formated node string, without loss of information.
> + *
> + 
> *
> + *Backend XenBus Nodes
> + 
> *
> + *
> + * Features supported 
> 
> + *
> + * Capable backend advertises supported features by publishing
> + * corresponding entries in XenStore and puts 1 as the value of the entry.
> + * If a feature is not supported then 0 must be set or feature entry omitted.
> + *
> + * feature-abs-pointer
> + *  Values: 
> + *
> + *  Backends, which support reporting of absolute coordinates for pointer
> + *  device should set this to 1.
> + *
> + *- Pointer Device Parameters 
> 
> + *
> + * width
> + *  Values: 
> + *
> + *  Maximum X coordinate (width) to be used by the frontend
> + *  while reporting input events, pixels, [0; UINT32_MAX].
> + *
> + * height
> + *  Values: 
> + *
> + *  Maximum Y coordinate (height) to be used by the frontend
> + *  while reporting input events, pixels, [0; UINT32_MAX].
> + *
> + 
> *
> + *Frontend XenBus Nodes
> + 
> *
> + *
> + *-- Feature request 
> -
> + *
> + * Capable frontend requests features from backend via setting corresponding
> + * entries to 1 in XenStore. Requests for features not advertised as 
> supported
> + * by the backend have no effect.
> + *
> + * request-abs-pointer
> + *  Values: 
> + *
> + *  Request backend to report absolute pointer coordinates
> + *  (XENKBD_TYPE_POS) instead of relative ones (XENKBD_TYPE_MOTION).
> + *
> + *--- Request Transport Parameters 
> ---
> + *
> + * event-channel
> + *  Values: 
> + *
> + *  The identifier of the Xen event channel used to signal activity
> + *  in the ring buffer.
> + *
> + * page-gref
> + *  Values: 
> + *
> + *  The Xen grant reference granting permission for the backend to map
> + *  a sole page in a single page sized event ring buffer.
> + *
> + * page-ref
> + *  Values: 
> + *
> + *  OBSOLETE, not recommended for use.
> + *  PFN of the shared page.
> + */
>  
>  /*
> - * Frontends should ignore unknown in events.
> + * EVENT CODES.
>   */
>  
> -/* Pointer movement event */
> -#define XENKBD_TYPE_MOTION  1
> -/* Event type 2 currently not used */
> -/* Key event (includes pointer buttons) */
> -#define XENKBD_TYPE_KEY 3
> +#define XENKBD_TYPE_MOTION 1
> +#define XENKBD_TYPE_RESERVED   2
> +#define XENKBD_TYPE_KEY3
> +#define XENKBD_TYPE_POS4
> +
>  /*
> - * Pointer position event
> - * Capable backend sets feature-abs-pointer in xenstore.
> - * Frontend requests ot instead of XENKBD_TYPE_MOTION by setting
> - * request-abs-update in xenstore.
> + * CONSTANTS, XENSTORE FIELD AND PATH NAME STRINGS, HELPERS.
> + */
> +
> +#define XENKBD_DRIVER_NAME "vkbd"
> +
> +#define 

Re: [Xen-devel] xennet_start_xmit assumptions

[Sowmini Varadhan]

On (01/19/17 11:37), David Miller wrote:
> 
> I thought we had code which made sure that at least a minimal
> link layer header was present in the SKB?
> 
> Specifically I'm talking about the dev_validate_header() check.
> That is supposed to protect us from these kinds of situations.

ah, but I run my pf_packet application as root, so I have 
capable(CAP_SYS_RAWIO), so I slip through the dev_validate_header()
check.

--Sowmini

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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Relax hw domain mapping attributes to p2m_mmio_direct_c

[Stefano Stabellini]

On Thu, 19 Jan 2017, Julien Grall wrote:
> Hi Edgar,
> 
> On 10/01/2017 11:37, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias" 
> > 
> > Relax the hardware domains mapping attributes to p2m_mmio_direct_c.
> > This will allow the hardware domain to fully control the
> > attribtues via its S1 mappings.
> 
> s/attribtues/attributes/
> 
> I would like some rationale in the commit message to explain why it is fine to
> do this relaxation (e.g the hardware domain is a trusted domain).
> 
> A such relaxation would probably be necessary for the ACPI case too (see
> map_dev_mmio_region).
> 
> Also, this is a revert of patch 1e75ed8 and 9eed361 + relaxation, I would
> either mention it in the commit message. Or send separate patch to revert both
> of them. Either way will be fine by me.
> 
> > 
> > Signed-off-by: Edgar E. Iglesias 
> > ---
> >  xen/arch/arm/domain_build.c | 63
> > ++---
> >  1 file changed, 13 insertions(+), 50 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 07b868d..a3521c7 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -48,20 +48,6 @@ struct map_range_data
> >  p2m_type_t p2mt;
> >  };
> > 
> > -static const struct dt_device_match dev_map_attrs[] __initconst =
> > -{
> > -{
> > -__DT_MATCH_COMPATIBLE("mmio-sram"),
> > -__DT_MATCH_PROP("no-memory-wc"),
> > -.data = (void *) (uintptr_t) p2m_mmio_direct_dev,
> > -},
> > -{
> > -__DT_MATCH_COMPATIBLE("mmio-sram"),
> > -.data = (void *) (uintptr_t) p2m_mmio_direct_nc,
> > -},
> > -{ /* sentinel */ },
> > -};
> > -
> >  //#define DEBUG_11_ALLOCATION
> >  #ifdef DEBUG_11_ALLOCATION
> >  # define D11PRINT(fmt, args...) printk(XENLOG_DEBUG fmt, ##args)
> > @@ -1005,8 +991,7 @@ static int map_range_to_domain(const struct
> > dt_device_node *dev,
> > u64 addr, u64 len,
> > void *data)
> >  {
> > -struct map_range_data *mr_data = data;
> 
> I would actually prefer to keep the plumbing and only remove dev_map_attrs.
> Stefano do you have any opinions?

I would keep the plumbings too (9eed361a), but I am fine either way.

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

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]

[Boris Ostrovsky]

On 01/19/2017 01:05 PM, Ian Jackson wrote:
> Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237: 
> regressions - FAIL"):
>> On 01/18/2017 10:05 AM, osstest service owner wrote:
>>> flight 104237 linux-linus real [real]
>>> http://logs.test-lab.xenproject.org/osstest/logs/104237/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>>  test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 
>>> 59254
>>>  test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 
>>> 59254
>> Assuming that the last session in serial-nocera1.log is the one that
>> failed, I wonder whether these is something with the mpt2sas --- it's
>> the last thing that's reported before debug-keys are activated:
>>
>> Jan 18 08:47:25.033615 [   40.938069] sd 4:0:0:0: attempting task abort! 
>> scmd(db67b800)
>> Jan 18 08:47:47.705686 [   40.938090] sd 4:0:0:0: [sda] tag#0 CDB: ATA 
>> command pass through(12)/Blank a1 08 2e 00 01 00 00 00 00 ec 00 00
>> Jan 18 08:47:47.713625 [   40.938097] scsi target4:0:0: handle(0x0009), 
>> sas_address(0x443322110700), phy(7)
>> Jan 18 08:47:47.721635 [   40.938102] scsi target4:0:0: 
>> enclosure_logical_id(0x5b083fe0e50a5700), slot(0)
>> Jan 18 08:47:47.729630 [   40.938129] sd 4:0:0:0: task abort: SUCCESS 
>> scmd(db67b800)
> I have had other reports of problems with mptsas.  For example,
> see this bug:  http://bugs.debian.org/850425

That particular bug appears to have swiotlb "overflow" in its signature,
which osstest log doesn't have.

>
> The osstest bisector worked on this:
>
> osstest service owner writes ("[linux-linus bisection] complete 
> test-amd64-amd64-xl-qemut-win7-amd64"):
>> branch xen-unstable
>> xenbranch xen-unstable
>> job test-amd64-amd64-xl-qemut-win7-amd64
>> testid xen-boot
>>
>> Tree: linux 
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
>> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
>> Tree: xen git://xenbits.xen.org/xen.git
>>
>> *** Found and reproduced problem changeset ***
>>
>>   Bug is in tree:  linux 
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>>   Bug introduced:  0aa0313f9d576affd7747cc3f179feb097d28990
>>   Bug not present: bcc981e9ed84c678533299d7eff17d2c81e4d5de
>>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/104305/
> Unfortunately it has fingered a merge commit.
>
> This means that the bug is in commits which diverged before the last
> pass of this test.
>
> (Did your filters get you a copy of the bisection email?)

No, I haven't set a filter for the bisector but I did see this message
and didn't find bisection results particularly useful. bcc981e9ed84 is
from about a year ago, which, I think, is when you stopped running this
test. And so the question might be whether "Bug not present" is really true?

-boris



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

[Xen-devel] [PATCH] swiotlb-xen: update dev_addr after swapping pages

[Stefano Stabellini]

In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
page is not suitable, we swap it for another page from the swiotlb 
pool.

In these cases, we don't update the previously calculated dma address
for the page before calling xen_dma_map_page. Thus, we end up calling
xen_dma_map_page passing the wrong dev_addr, resulting in
xen_dma_map_page mistakenly assuming that the page is foreign when it is
local.

Fix the bug by updating dev_addr appropriately.

This change has no effect on x86, because xen_dma_map_page is a stub
there.

Signed-off-by: Stefano Stabellini 
Signed-off-by: Pooya Keshavarzi 
Tested-by: Pooya Keshavarzi 

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f905d6e..f8afc6d 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -414,9 +414,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, struct 
page *page,
if (map == SWIOTLB_MAP_ERROR)
return DMA_ERROR_CODE;
 
+   dev_addr = xen_phys_to_bus(map);
xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
dev_addr, map & ~PAGE_MASK, size, dir, 
attrs);
-   dev_addr = xen_phys_to_bus(map);
 
/*
 * Ensure that the address returned is DMA'ble
@@ -575,13 +575,14 @@ void xen_swiotlb_unmap_page(struct device *hwdev, 
dma_addr_t dev_addr,
sg_dma_len(sgl) = 0;
return 0;
}
+   dev_addr = xen_phys_to_bus(map);
xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
dev_addr,
map & ~PAGE_MASK,
sg->length,
dir,
attrs);
-   sg->dma_address = xen_phys_to_bus(map);
+   sg->dma_address = dev_addr;
} else {
/* we are not interested in the dma_addr returned by
 * xen_dma_map_page, only in the potential cache 
flushes executed

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Stefano Stabellini]

On Thu, 19 Jan 2017, Pooya Keshavarzi wrote:
> Hi Stefano,
> 
> On 01/13/2017 07:39 PM, Stefano Stabellini wrote:
> > On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
> >> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
> >>> On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:
> 
>  Firstly sorry for the late reply on this.
> 
>  Regarding the problem with swiotlb-xen here are some more details:
> 
>  If we limit Dom0's memory such that only low-memory (up to 32-bit 
>  addressable memory) is available to Dom0, then swiotlb-xen does not have 
>  to use bounce buffers and the devices (e.g. USB, ethernet) would work.
> 
>  But when there is some high memory also available to Dom0, the 
>  followings happen:
>   - If the the device address happens to be in the device's DMA window 
>  (see xen_swiotlb_map_page()), then the device would work.
>   - Otherwise if it has to allocate and map a bounce buffer, then the 
>  device would not work.
> >>>
> >>> From what you wrote it looks like the xen_swiotlb_map_page path: 
> >>>
> >>>   if (dma_capable(dev, dev_addr, size) &&
> >>>   !range_straddles_page_boundary(phys, size) &&
> >>>   !xen_arch_need_swiotlb(dev, phys, dev_addr) &&
> >>>   !swiotlb_force) {
> >>>   /* we are not interested in the dma_addr returned by
> >>>* xen_dma_map_page, only in the potential cache flushes 
> >>> executed
> >>>* by the function. */
> >>>   xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
> >>>   return dev_addr;
> >>>   }
> >>>
> >>> works, but the other does not. Does it match your understanding? Have
> >>> you done any digging to find the reason why the bounce buffer code path
> >>> is broken on your platform?
> >>
> >> Yes, The above path works but the other one doesn't.
> >> I did some digging but failed to find out what's the problem. The returned 
> >> address from swiotlb_tbl_map_single() is within the memory range allocated 
> >> earlier for Xen software IO TLB and is dma capable, so it seem to be OK.
> >>
> >> What's your suggestion for further digging?
> > 
> > Is the device DMA coherent?
> No.
> 
> > I take that it fails even without running any guests, correct?
> Yes, fails only with Dom0.
> 
> > A few things come to mind:
> > 
> > - In xen_dma_map_page, does it take the local path or the foreign path
> >   (if(local)...) when it fails?
> When it fails, it takes the foreign path.
> 
> > - Check that xen_swiotlb_init initializes the swiotlb memory region
> >   appriopriately and that it falls in a memory range supported by the
> >   device.
> The only thing is this warning:
> xen:swiotlb_xen: Warning: only able to allocate 4 MB for software IO TLB
> 
> The allocation in the first memory bank can be solved by this, and then 
> swiotlb-xen allocates in the proper memory range.
> https://patchwork.kernel.org/patch/9347329/
> We had a similar issue.
> 
> 
> > - Check that xen_phys_to_bus(map) returns the right dev_addr. As a
> >   reference, I know that on some arm32 platforms it wouldn't return the
> >   right value.
> It returns the same address as map.
> 
>  
> > - Does the following patch fixes the issue for you?
> Yes :) it seems that it solves the issue for Ethernet.
> And now it takes the local path in xen_dma_map_page.
> 
> But why?

This is a genuine bug in swiotlb-xen. xen_swiotlb_map_page swaps the
original page for one from the swiotlb pool. The call to
swiotlb_tbl_map_single returns the new page. However, we are calling
xen_dma_map_page passing the dev_addr of the original page, rather than
the new one. xen_dma_map_page wrongly assumes that the page is foreign
because phys_addr and dma_addr don't match.

Thank you for reporting the issue and for testing. I'll submit a patch
shortly. I'll add your signed-off-by to it, if that's OK.


  
> > diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> > index 87e6035..17c65fa 100644
> > --- a/drivers/xen/swiotlb-xen.c
> > +++ b/drivers/xen/swiotlb-xen.c
> > @@ -409,9 +409,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, 
> > struct page *page,
> > if (map == SWIOTLB_MAP_ERROR)
> > return DMA_ERROR_CODE;
> >  
> > +   dev_addr = xen_phys_to_bus(map);
> > xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
> > dev_addr, map & ~PAGE_MASK, size, dir, 
> > attrs);
> > -   dev_addr = xen_phys_to_bus(map);
> >  
> > /*
> >  * Ensure that the address returned is DMA'ble 
> 
> 
> And following patch solves the issue for USB, MMC, SDC.
> 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 7399782..69b5c62 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -567,6 +567,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct 
> scatterlist *sgl,
>   sg_dma_len(sgl) = 0;
>   return 0;
>   

Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

[Stefano Stabellini]

On Thu, 19 Jan 2017, Roger Pau Monné wrote:
> On Wed, Jan 18, 2017 at 07:13:23PM +, Julien Grall wrote:
> > Hi,
> > 
> > On 18/01/17 19:05, Stefano Stabellini wrote:
> > > On Wed, 18 Jan 2017, Roger Pau Monné wrote:
> > > > On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
> > > > > a) One option is to provide a Xen specific implementation of
> > > > > acpi_os_ioremap in Linux. I think this is the cleanest approach, but
> > > > > unfortunately, it doesn't cover cases where ioremap is used directly. 
> > > > > (2)
> > > > > is one of such cases, see
> > > > > arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
> > > > > drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
> > > > > see drivers/acpi/apei/bert.c:bert_init.
> > > > 
> > > > This is basically the same as b) from Xen's PoV, the only difference is 
> > > > where
> > > > you would call the hypercall from Dom0 to establish stage-2 mappings.
> > > 
> > > Right, but it is important from the Linux point of view, this is why I
> > > am asking the Linux maintainers.
> > > 
> > > 
> > > > > b) Otherwise, we could write an alternative implementation of ioremap
> > > > > on arm64. The Xen specific ioremap would request a stage-2 mapping
> > > > > first, then create the stage-1 mapping as usual. However, this means
> > > > > issuing an hypercall for every ioremap call.
> > > > 
> > > > This seems fine to me, and at present is the only way to get something 
> > > > working.
> > > > As you said not being able to discover OperationRegions from Xen means 
> > > > that
> > > > there's a chance some MMIO might not be added to the stage-2 mappings.
> > > > 
> > > > Then what's the initial memory map state when Dom0 is booted? There are 
> > > > no MMIO
> > > > mappings at all, and Dom0 must request mappings for everything?
> > > 
> > > Yes
> > 
> > To give more context here, the UEFI memory map does not report all the MMIO
> > regions. So there is no possibility to map MMIO at boot.
> 
> I've been able to get a Dom0 booting on x86 by mapping all the regions marked
> as ACPI in the memory map, plus the BARs of PCI devices and the MCFG areas. 
> But
> this is not really optimal, since as Stefano says:
> 
>  1. If there are new tables that contain memory regions that should be mapped 
> to
>Dom0, Xen will need to be updated in order to work on those systems.
>  2. ATM it's not possible for Xen to know all the OperationRegions described 
> in
>the ACPI DSDT/SSDT tables.
> 
> I'm not that worried about 1, since the user will also need a newish Dom0
> kernel in order to access those devices, and it doesn't seem like new ACPI
> tables appear out of the blue everyday. It however puts more pressure on Xen 
> in
> order to aggressively track ACPI changes.
> 
> In order to fix 2 an AML parser would need to be added to Xen.

This brings me to another possible solution: we could map everything
beforehand in Xen as you wrote, then use a), an alternative
implementation of acpi_os_ioremap, to fix problem 2.
In this scheme, 1. remains unfixed.

I think this is suboptimal, but it is a possibility.


> > > > What happens to ACPI tables crafted for Dom0 that reside in RAM? That 
> > > > would
> > > > apply to the STAO and to the other tables that are crafted for Dom0 at 
> > > > build
> > > > time. Should Dom0 also request stage-2 mappings for them, and Xen 
> > > > simply ignore
> > > > those calls?
> > > 
> > > The ACPI (and UEFI) tables are mapped by Xen
> > 
> > I think Royger's point is DOM0 cannot tell whether a region has been mapped
> > by Xen or not.
> > 
> > The function ioremap will be used to map anything (it is the leaf of all
> > mapping functions), and will call Xen no matter the address passed. It could
> > be a RAM region, HW device region, emulated device region.
> 
> Exactly, from a guest OS PoV it would request those mappings for all device
> memory regions. But from Xen's perspective, those request might be made 
> against
> at least 3 different types of p2m regions:
> 
>  - Regions trapped by emulated devices inside of Xen: no direct MMIO mapping
>should be established in this case.
>  - RAM regions that belong to Xen-crafted ACPI tables (STAO, MADT...).
>  - Real MMIO regions that should be passed through.
> 
> Right now AFAIK Xen doesn't track any of this information, so we would need
> additional non-trivial logic in order to account for all this inside the
> hypervisor.

I think this is something we'll have to do to guarantee that we have a
good implementation of XENMEM_add_to_physmap_range in Xen, regardless of
the rest of the discussion.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions 
- FAIL"):
> On 01/18/2017 10:05 AM, osstest service owner wrote:
> >  build-armhf-pvops 5 kernel-build  fail REGR. vs. 
> > 59254
> 
> ARM build seems to be caused by some sort of a timeout. The script
> allows about 2.5 hours for the build to complete and it looks like it is
> close to finishing it. Hard to say why it takes that long but I see no
> build errors --- IIUIC the build is aborted due to the timeout.

2.5 hours!  How long should it take do you think ?

I mean, I can increase the timeout, but this already seems quite
unreasonable.

Ian.

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

Re: [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64 [and 1 more messages]

[Ian Jackson]

Boris Ostrovsky writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions 
- FAIL"):
> On 01/18/2017 10:05 AM, osstest service owner wrote:
> > flight 104237 linux-linus real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/104237/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 
> > 59254
> >  test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 
> > 59254
> 
> Assuming that the last session in serial-nocera1.log is the one that
> failed, I wonder whether these is something with the mpt2sas --- it's
> the last thing that's reported before debug-keys are activated:
> 
> Jan 18 08:47:25.033615 [   40.938069] sd 4:0:0:0: attempting task abort! 
> scmd(db67b800)
> Jan 18 08:47:47.705686 [   40.938090] sd 4:0:0:0: [sda] tag#0 CDB: ATA 
> command pass through(12)/Blank a1 08 2e 00 01 00 00 00 00 ec 00 00
> Jan 18 08:47:47.713625 [   40.938097] scsi target4:0:0: handle(0x0009), 
> sas_address(0x443322110700), phy(7)
> Jan 18 08:47:47.721635 [   40.938102] scsi target4:0:0: 
> enclosure_logical_id(0x5b083fe0e50a5700), slot(0)
> Jan 18 08:47:47.729630 [   40.938129] sd 4:0:0:0: task abort: SUCCESS 
> scmd(db67b800)

I have had other reports of problems with mptsas.  For example,
see this bug:  http://bugs.debian.org/850425

The osstest bisector worked on this:

osstest service owner writes ("[linux-linus bisection] complete 
test-amd64-amd64-xl-qemut-win7-amd64"):
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-qemut-win7-amd64
> testid xen-boot
> 
> Tree: linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>   Bug introduced:  0aa0313f9d576affd7747cc3f179feb097d28990
>   Bug not present: bcc981e9ed84c678533299d7eff17d2c81e4d5de
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/104305/

Unfortunately it has fingered a merge commit.

This means that the bug is in commits which diverged before the last
pass of this test.

(Did your filters get you a copy of the bisection email?)

Ian.

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

Re: [Xen-devel] [PATCH 1/1] kexec: ensure kexec_status() return bit value of 0 or 1

[Daniel Kiper]

On Thu, Jan 19, 2017 at 11:10:53AM -0600, Eric DeVolder wrote:
> When checking kexec_flags bit corresponding to the
> requested image, ensure that 0 or 1 is returned.
>
> Signed-off-by: Eric DeVolder 

In general Reviewed-by: Daniel Kiper  but...

> ---
>  xen/common/kexec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/common/kexec.c b/xen/common/kexec.c
> index aa808cb..3da27bf 100644
> --- a/xen/common/kexec.c
> +++ b/xen/common/kexec.c
> @@ -1182,7 +1182,8 @@ static int kexec_status(XEN_GUEST_HANDLE_PARAM(void) 
> uarg)
>  if ( kexec_load_get_bits(status.type, , ) )
>  return -EINVAL;
>
> -return test_bit(bit, _flags);
> +/* Ensure return bit value of 0 or 1 */

This is not needed here. "!!" is used very often and it is not an unusual stuff.
So, it does not need any comment. However, I can agree that at first sight
it looks strange.

> +return !!test_bit(bit, _flags);

Daniel

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

Re: [Xen-devel] [PATCH RFC 3/8] golang/xenlight: Add host-related functionality

[George Dunlap]

On 18/01/17 19:56, Ronald Rojas wrote:
> Add calls for the following host-related functionality:
> - libxl_get_max_cpus
> - libxl_get_online_cpus
> - libxl_get_max_nodes
> - libxl_get_free_memory
> - libxl_get_physinfo
> - libxl_get_version_info
> 
> Include Golang versions of the following structs:
> - libxl_physinfo as Physinfo
> - libxl_version_info as VersionInfo
> - libxl_hwcap as Hwcap
> 
> Signed-off-by: Ronald Rojas 

This looks good, and I think could be checked in once rebased on
previous changes.  One comment for future direction...

> ---
>  tools/golang/xenlight/xenlight.go | 185 
> ++
>  1 file changed, 185 insertions(+)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index d58f8b8..6b04850 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -109,6 +109,62 @@ type Context struct {
>   ctx *C.libxl_ctx
>  }
>  
> +type Hwcap []C.uint32_t
> +
> +func hwcapCToGo(chwcap C.libxl_hwcap) (ghwcap Hwcap) {
> + // Alloc a Go slice for the bytes
> + size := 8
> + ghwcap = make([]C.uint32_t, size)
> +
> + // Make a slice pointing to the C array
> + mapslice := (*[1 << 
> 30]C.uint32_t)(unsafe.Pointer([0]))[:size:size]
> +
> + // And copy the C array into the Go array
> + copy(ghwcap, mapslice)
> +
> + return
> +}

In my own copy of the library, I was experimenting with using methods to
do this, rather than making standalone functions that embed the name in
the type.  Something like this:

func (c C.libxl_dominfo) toGo() (g Dominfo) {
g.Uuid = Uuid(c.uuid)
 [etc]
}

That way you can do cdi.toGo() rather than dominfoCToGo(cdi).  The
syntax looks a lot cleaner and more consistent.

What do you think?

 -George


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

[Xen-devel] [PATCH] libxl: fix dom0 autoballooning with Xen 4.8

[Jim Fehlig]

xen.git commit 57f8b13c changed several of the libxl memory
get/set functions to take 64 bit parameters. The libvirt
libxl driver still uses uint32_t variables for these various
parameters, which is particularly problematic for the
libxl_set_memory_target() function.

When dom0 autoballooning is enabled, libvirt (like xl) determines
the memory needed to start a domain and the memory available. If
memory available is less than memory needed, dom0 is ballooned
down by passing a negative value to libxl_set_memory_target()
'target_memkb' parameter. Prior to xen.git commit 57f8b13c,
'target_memkb' was an int32_t. Subtracting a larger uint32 from
a smaller uint32 and assigning it to int32 resulted in a negative
number. After commit 57f8b13c, the same subtraction is widened
to a int64, resulting in a large positive number. The simple
fix taken by this patch is to assign the difference of the
uint32 values to a temporary int32 variable, which is then
passed to 'target_memkb' parameter of libxl_set_memory_target().

Note that it is undesirable to change libvirt to use 64 bit
variables since it requires setting LIBXL_API_VERSION to 0x040800.
Currently libvirt supports LIBXL_API_VERSION >= 0x040400,
essentially Xen >= 4.4.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_domain.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index a5314b0..ed73cd2 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -909,6 +909,7 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config 
*d_config)
 {
 uint32_t needed_mem;
 uint32_t free_mem;
+int32_t target_mem;
 int tries = 3;
 int wait_secs = 10;
 
@@ -922,7 +923,8 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config 
*d_config)
 if (free_mem >= needed_mem)
 return 0;
 
-if (libxl_set_memory_target(ctx, 0, free_mem - needed_mem,
+target_mem = free_mem - needed_mem;
+if (libxl_set_memory_target(ctx, 0, target_mem,
 /* relative */ 1, 0) < 0)
 goto error;
 
-- 
2.9.2


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

Re: [Xen-devel] [PATCH v13 3/3] iommu: add rmrr Xen command line option for extra rmrrs

[Elena Ufimtseva]

On Thu, Jan 19, 2017 at 01:29:15AM -0700, Jan Beulich wrote:
> >>> On 18.01.17 at 20:56,  wrote:
> > I am looking at rmrr_identity_mapping where the RMRR paddr get converted
> > to pfn and then mapped with iommu.
> > If ( rmrr->end_address & ~PAGE_SHIFT_MASK_4K ) == 0, the while loop
> > while ( base_pfn < end_pfn )
> >  will not map that inclusive end_address of rmrr.
> > Does it seem wrong?
> 
> I don't think so, no. end_pfn is being calculated using
> PAGE_ALIGN_4K(), i.e. rounding up.

I mean to say, if the end address is already aligned, then the page wont
be mapped.
For example, if end paddr is 0x000ed000, end_pfn will be
0x000ed and wont be mapped in the loop
while ( base_pfn < end_pfn ).
And we will have mapped RMRR end address saved in arch.mapped_rmrrs
as 0x000ed000.
Looks like parsed ACPI RMRR end addresses are extended to end of the
page though. Not sure if there is somewhere same boundary alignment in
code similar to what you proposed below.

> 
> >> > +rmrr->segment = seg;
> >> > +rmrr->base_address = pfn_to_paddr(user_rmrrs[i].base_pfn);
> >> > +rmrr->end_address = pfn_to_paddr(user_rmrrs[i].end_pfn + 1);
> >> 
> >> "And this seems wrong too, unless I'm mistaken with the inclusive-ness."
> >> 
> > This one is the avoidance of the while loop mapping in
> > rmrr_identity_mapping.
> 
> Well, that's the purpose you describe, but the comment was about
> the calculation itself, which I think is lacking a "- 1", but even better
> would be - for avoiding boundary issues -
> 
> rmrr->end_address = pfn_to_paddr(user_rmrrs[i].end_pfn) | ~PAGE_MASK;

Yes, this will eliminate this problem. This will need to be accounted
for in overlapping condition as well.

> 
> or some such.
> 
> Jan
> 

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

[Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

[Roger Pau Monne]

Split the Dom0 builder into two different functions, one for PV (and classic
PVH), and another one for PVHv2. Introduce a new command line parameter
called 'dom0' that can be used to request the creation of a PVHv2 Dom0 by
setting the 'hvm' sub-option. A panic has also been added if a user tries
to use dom0=hvm until all the code is in place, then the panic will be
removed. While there remove the dom0_shadow option that was used by PV Dom0, it
was lacking documentation and was not functional.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Move common sanity BUG_ONs and process_pending_softirqs to construct_dom0.
 - Remove the non-existant documentation about dom0_shadow option.
 - Fix the define of dom0_shadow to be 'false' instead of 0.
 - Move the parsing of the dom0 command line option to domain_build.c.
 - s/hvm/pvh.

Changes since v3:
 - Correctly declare the parameter list.
 - Add a panic if dom0=hvm is used. This will be removed once all the code is in
   place.

Changes since v2:
 - Fix coding style.
 - Introduce a new dom0 option that allows passing several parameters.
   Currently supported ones are hvm and shadow.

Changes since RFC:
 - Add documentation for the new command line option.
 - Simplify the logic in construct_dom0.
---
 docs/misc/xen-command-line.markdown | 20 +--
 xen/arch/x86/domain_build.c | 66 +
 xen/arch/x86/setup.c|  9 +
 xen/include/asm-x86/setup.h |  7 
 4 files changed, 92 insertions(+), 10 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0138978..9f33c23 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -646,9 +646,6 @@ restrictions set up here. Note that the values to be 
specified here are
 ACPI PXM ones, not Xen internal node numbers. `relaxed` sets up vCPU
 affinities to prefer but be not limited to the specified node(s).
 
-### dom0\_shadow
-> `= `
-
 ### dom0\_vcpus\_pin
 > `= `
 
@@ -656,6 +653,23 @@ affinities to prefer but be not limited to the specified 
node(s).
 
 Pin dom0 vcpus to their respective pcpus
 
+### dom0
+> `= List of [ pvh | shadow ]`
+
+> Sub-options:
+
+> `pvh`
+
+> Default: `false`
+
+Flag that makes a dom0 boot in PVHv2 mode.
+
+> `shadow`
+
+> Default: `false`
+
+Flag that makes a dom0 use shadow paging.
+
 ### dom0pvh
 > `= `
 
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 243df96..4d555b1 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -191,11 +191,40 @@ struct vcpu *__init alloc_dom0_vcpu0(struct domain *dom0)
 }
 
 #ifdef CONFIG_SHADOW_PAGING
-static bool_t __initdata opt_dom0_shadow;
+bool __initdata opt_dom0_shadow;
 boolean_param("dom0_shadow", opt_dom0_shadow);
 #else
-#define opt_dom0_shadow 0
+#define opt_dom0_shadow false
 #endif
+bool __initdata dom0_pvh;
+
+/*
+ * List of parameters that affect Dom0 creation:
+ *
+ *  - pvh   Create a PVHv2 Dom0.
+ *  - shadowUse shadow paging for Dom0.
+ */
+static void __init parse_dom0_param(char *s)
+{
+char *ss;
+
+do {
+
+ss = strchr(s, ',');
+if ( ss )
+*ss = '\0';
+
+if ( !strcmp(s, "pvh") )
+dom0_pvh = true;
+#ifdef CONFIG_SHADOW_PAGING
+else if ( !strcmp(s, "shadow") )
+opt_dom0_shadow = true;
+#endif
+
+s = ss + 1;
+} while ( ss );
+}
+custom_param("dom0", parse_dom0_param);
 
 static char __initdata opt_dom0_ioports_disable[200] = "";
 string_param("dom0_ioports_disable", opt_dom0_ioports_disable);
@@ -951,7 +980,7 @@ static int __init setup_permissions(struct domain *d)
 return rc;
 }
 
-int __init construct_dom0(
+static int __init construct_dom0_pv(
 struct domain *d,
 const module_t *image, unsigned long image_headroom,
 module_t *initrd,
@@ -1008,12 +1037,8 @@ int __init construct_dom0(
 paddr_t mpt_alloc;
 
 /* Sanity! */
-BUG_ON(d->domain_id != 0);
-BUG_ON(d->vcpu[0] == NULL);
 BUG_ON(v->is_initialised);
 
-process_pending_softirqs();
-
 printk("*** LOADING DOMAIN 0 ***\n");
 
 d->max_pages = ~0U;
@@ -1655,6 +1680,33 @@ out:
 return rc;
 }
 
+static int __init construct_dom0_pvh(struct domain *d, const module_t *image,
+ unsigned long image_headroom,
+ module_t *initrd,
+ void *(*bootstrap_map)(const module_t *),
+ char *cmdline)
+{
+
+printk("** Building a PVH Dom0 **\n");
+
+return 0;
+}
+
+int __init construct_dom0(struct domain *d, const module_t *image,
+  unsigned long image_headroom, module_t *initrd,
+  void *(*bootstrap_map)(const module_t *),
+ 

[Xen-devel] [PATCH v5 8/9] xen/x86: Setup PVHv2 Dom0 CPUs

[Roger Pau Monne]

Initialize Dom0 BSP/APs and setup the memory and IO permissions. This also sets
the initial BSP state in order to match the protocol specified in
hvm/start_info.h.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
---
 xen/arch/x86/domain_build.c | 60 +
 1 file changed, 60 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 55caa30..ca5d393 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
@@ -2096,6 +2097,56 @@ static int __init pvh_load_kernel(struct domain *d, 
const module_t *image,
 return 0;
 }
 
+static int __init pvh_setup_cpus(struct domain *d, paddr_t entry,
+ paddr_t start_info)
+{
+vcpu_hvm_context_t cpu_ctx;
+struct vcpu *v = d->vcpu[0];
+int cpu, i, rc;
+
+cpu = v->processor;
+for ( i = 1; i < d->max_vcpus; i++ )
+{
+cpu = cpumask_cycle(cpu, _cpus);
+setup_dom0_vcpu(d, i, cpu);
+}
+
+memset(_ctx, 0, sizeof(cpu_ctx));
+
+cpu_ctx.mode = VCPU_HVM_MODE_32B;
+
+cpu_ctx.cpu_regs.x86_32.ebx = start_info;
+cpu_ctx.cpu_regs.x86_32.eip = entry;
+cpu_ctx.cpu_regs.x86_32.cr0 = X86_CR0_PE | X86_CR0_ET;
+
+cpu_ctx.cpu_regs.x86_32.cs_limit = ~0u;
+cpu_ctx.cpu_regs.x86_32.ds_limit = ~0u;
+cpu_ctx.cpu_regs.x86_32.ss_limit = ~0u;
+cpu_ctx.cpu_regs.x86_32.tr_limit = 0x67;
+cpu_ctx.cpu_regs.x86_32.cs_ar = 0xc9b;
+cpu_ctx.cpu_regs.x86_32.ds_ar = 0xc93;
+cpu_ctx.cpu_regs.x86_32.ss_ar = 0xc93;
+cpu_ctx.cpu_regs.x86_32.tr_ar = 0x8b;
+
+rc = arch_set_info_hvm_guest(v, _ctx);
+if ( rc )
+{
+printk("Unable to setup Dom0 BSP context: %d\n", rc);
+return rc;
+}
+
+rc = setup_permissions(d);
+if ( rc )
+{
+panic("Unable to setup Dom0 permissions: %d\n", rc);
+return rc;
+}
+
+update_domain_wallclock_time(d);
+
+return 0;
+}
+
 static int __init construct_dom0_pvh(struct domain *d, const module_t *image,
  unsigned long image_headroom,
  module_t *initrd,
@@ -2124,6 +2175,15 @@ static int __init construct_dom0_pvh(struct domain *d, 
const module_t *image,
 return rc;
 }
 
+rc = pvh_setup_cpus(d, entry, start_info);
+if ( rc )
+{
+printk("Failed to setup Dom0 CPUs: %d\n", rc);
+return rc;
+}
+
+clear_bit(_VPF_down, >vcpu[0]->pause_flags);
+
 return 0;
 }
 
-- 
2.10.1 (Apple Git-78)


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

Re: [Xen-devel] [PATCH v2 2/6] qdict: Add convenience helpers for wrapped puts

[Stefan Hajnoczi]

On Wed, Jan 18, 2017 at 10:16:49AM -0600, Eric Blake wrote:
> Quite a few users of qdict_put() were manually wrapping a
> non-QObject. We can make such call-sites shorter, by providing
> common macros to do the tedious work.  Also shorten nearby
> qdict_put_obj(,,QOBJECT()) sequences.
> 
> Signed-off-by: Eric Blake 
> Reviewed-by: Alberto Garcia 
> 
> ---
> 
> v2: rebase to current master
> 
> I'm okay if you want me to break this patch into smaller pieces.
> ---
>  include/qapi/qmp/qdict.h|   8 +++
>  block.c |  59 +++-
>  block/archipelago.c |   4 +-
>  block/blkdebug.c|   6 +-
>  block/blkverify.c   |  11 ++-
>  block/curl.c|   2 +-
>  block/file-posix.c  |   8 +--
>  block/file-win32.c  |   4 +-
>  block/iscsi.c   |   2 +-
>  block/nbd.c |  41 ++-
>  block/nfs.c |  43 +---
>  block/null.c|   2 +-
>  block/qcow2.c   |   4 +-
>  block/quorum.c  |  13 ++--
>  block/ssh.c |  16 ++---
>  block/vvfat.c   |  10 +--
>  blockdev.c  |  28 
>  hw/block/xen_disk.c |   2 +-
>  hw/usb/xen-usb.c|  12 ++--
>  monitor.c   |  18 ++---
>  qapi/qmp-event.c|   2 +-
>  qemu-img.c  |   6 +-
>  qemu-io.c   |   2 +-
>  qemu-nbd.c  |   2 +-
>  qobject/qdict.c |   2 +-
>  target/s390x/cpu_models.c   |   4 +-
>  tests/check-qdict.c | 132 
> ++--
>  tests/test-qmp-commands.c   |  30 
>  tests/test-qmp-event.c  |  30 
>  tests/test-qobject-output-visitor.c |   6 +-
>  util/qemu-option.c  |   6 +-
>  31 files changed, 245 insertions(+), 270 deletions(-)

Reviewed-by: Stefan Hajnoczi 


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

[Xen-devel] [PATCH v5 6/9] xen/x86: parse Dom0 kernel for PVHv2

[Roger Pau Monne]

Introduce a helper to parse the Dom0 kernel.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - s/hvm/pvh.
 - Use hvm_copy_to_guest_phys_vcpu.

Changes since v3:
 - Change one error message.
 - Indent "out" label by one space.
 - Introduce hvm_copy_to_phys and slightly simplify the code in hvm_load_kernel.

Changes since v2:
 - Remove debug messages.
 - Don't hardcode the number of modules to 1.
---
 xen/arch/x86/domain_build.c | 143 
 1 file changed, 143 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index fbce1c2..4f5f712 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -39,6 +39,7 @@
 #include 
 
 #include 
+#include 
 
 static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
@@ -1959,12 +1960,146 @@ static int __init pvh_setup_p2m(struct domain *d)
 #undef MB1_PAGES
 }
 
+static int __init pvh_load_kernel(struct domain *d, const module_t *image,
+  unsigned long image_headroom,
+  module_t *initrd, char *image_base,
+  char *cmdline, paddr_t *entry,
+  paddr_t *start_info_addr)
+{
+char *image_start = image_base + image_headroom;
+unsigned long image_len = image->mod_end;
+struct elf_binary elf;
+struct elf_dom_parms parms;
+paddr_t last_addr;
+struct hvm_start_info start_info;
+struct hvm_modlist_entry mod = { 0 };
+struct vcpu *saved_current, *v = d->vcpu[0];
+int rc;
+
+if ( (rc = bzimage_parse(image_base, _start, _len)) != 0 )
+{
+printk("Error trying to detect bz compressed kernel\n");
+return rc;
+}
+
+if ( (rc = elf_init(, image_start, image_len)) != 0 )
+{
+printk("Unable to init ELF\n");
+return rc;
+}
+#ifdef VERBOSE
+elf_set_verbose();
+#endif
+elf_parse_binary();
+if ( (rc = elf_xen_parse(, )) != 0 )
+{
+printk("Unable to parse kernel for ELFNOTES\n");
+return rc;
+}
+
+if ( parms.phys_entry == UNSET_ADDR32 ) {
+printk("Unable to find XEN_ELFNOTE_PHYS32_ENTRY address\n");
+return -EINVAL;
+}
+
+printk("OS: %s version: %s loader: %s bitness: %s\n", parms.guest_os,
+   parms.guest_ver, parms.loader,
+   elf_64bit() ? "64-bit" : "32-bit");
+
+/* Copy the OS image and free temporary buffer. */
+elf.dest_base = (void *)(parms.virt_kstart - parms.virt_base);
+elf.dest_size = parms.virt_kend - parms.virt_kstart;
+
+/*
+ * NB: we need to set vCPU 0 of Dom0 as the current vCPU (instead of the
+ * idle one) because elf_load_binary calls raw_{copy_to/clear}_guest, and
+ * the target domain is not passed anywhere. This is very similar to what
+ * is done during classic PV Dom0 creation, where Xen switches to the Dom0
+ * page tables. We also cannot pass a struct domain or vcpu to
+ * elf_load_binary, since the interface is shared with the toolstack, and
+ * it doesn't have any notion of a domain or vcpu struct.
+ */
+saved_current = current;
+set_current(v);
+rc = elf_load_binary();
+set_current(saved_current);
+if ( rc < 0 )
+{
+printk("Failed to load kernel: %d\n", rc);
+printk("Xen dom0 kernel broken ELF: %s\n", elf_check_broken());
+return rc;
+}
+
+last_addr = ROUNDUP(parms.virt_kend - parms.virt_base, PAGE_SIZE);
+
+if ( initrd != NULL )
+{
+rc = hvm_copy_to_guest_phys_vcpu(last_addr,
+ mfn_to_virt(initrd->mod_start),
+ initrd->mod_end, v);
+if ( rc )
+{
+printk("Unable to copy initrd to guest\n");
+return rc;
+}
+
+mod.paddr = last_addr;
+mod.size = initrd->mod_end;
+last_addr += ROUNDUP(initrd->mod_end, PAGE_SIZE);
+}
+
+/* Free temporary buffers. */
+discard_initial_images();
+
+memset(_info, 0, sizeof(start_info));
+if ( cmdline != NULL )
+{
+rc = hvm_copy_to_guest_phys_vcpu(last_addr, cmdline,
+ strlen(cmdline) + 1, v);
+if ( rc )
+{
+printk("Unable to copy guest command line\n");
+return rc;
+}
+start_info.cmdline_paddr = last_addr;
+last_addr += ROUNDUP(strlen(cmdline) + 1, 8);
+}
+if ( initrd != NULL )
+{
+rc = hvm_copy_to_guest_phys_vcpu(last_addr, , sizeof(mod), v);
+if ( rc )
+{
+printk("Unable to copy guest modules\n");
+return rc;
+}
+start_info.modlist_paddr = last_addr;
+start_info.nr_modules = 1;
+last_addr += sizeof(mod);
+}
+
+

Re: [Xen-devel] [PATCH v5 7/9] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0

[Andrew Cooper]

On 19/01/17 17:29, Roger Pau Monne wrote:
> PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix
> dom0_max_vcpus so it takes this limitation into account by poking at the
> dom0_hvm variable.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

Craft the Dom0 e820 memory map and populate it. Introduce a helper to remove
memory pages that are shared between Xen and a domain, and use it in order to
remove low 1MB RAM regions from dom_io in order to assign them to a PVHv2 Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Move process_pending_softirqs to previous patch.
 - Fix off-by-one errors in some checks.
 - Make unshare_xen_page_with_guest __init.
 - Improve unshare_xen_page_with_guest by making use of already existing
   is_xen_heap_page and put_page.
 - s/hvm/pvh/.
 - Use PAGE_ORDER_4K in pvh_setup_e820 in order to keep consistency with the
   p2m code.

Changes since v3:
 - Drop get_order_from_bytes_floor, it was only used by
   hvm_populate_memory_range.
 - Switch hvm_populate_memory_range to use frame numbers instead of full memory
   addresses.
 - Add a helper to steal the low 1MB RAM areas from dom_io and add them to Dom0
   as normal RAM.
 - Introduce unshare_xen_page_with_guest in order to remove pages from dom_io,
   so they can be assigned to other domains. This is needed in order to remove
   the low 1MB RAM regions from dom_io and assign them to the hardware_domain.
 - Simplify the loop in hvm_steal_ram.
 - Move definition of map_identity_mmio into this patch.

Changes since v2:
 - Introduce get_order_from_bytes_floor as a local function to
   domain_build.c.
 - Remove extra asserts.
 - Make hvm_populate_memory_range return an error code instead of panicking.
 - Fix comments and printks.
 - Use ULL sufix instead of casting to uint64_t.
 - Rename hvm_setup_vmx_unrestricted_guest to
   hvm_setup_vmx_realmode_helpers.
 - Only substract two pages from the memory calculation, that will be used
   by the MADT replacement.
 - Remove some comments.
 - Remove printing allocation information.
 - Don't stash any pages for the MADT, TSS or ident PT, those will be
   subtracted directly from RAM regions of the memory map.
 - Count the number of iterations before calling process_pending_softirqs
   when populating the memory map.
 - Move the initial call to process_pending_softirqs into construct_dom0,
   and remove the ones from construct_dom0_hvm and construct_dom0_pv.
 - Make memflags global so it can be shared between alloc_chunk and
   hvm_populate_memory_range.

Changes since RFC:
 - Use IS_ALIGNED instead of checking with PAGE_MASK.
 - Use the new %pB specifier in order to print sizes in human readable form.
 - Create a VM86 TSS for hardware that doesn't support unrestricted mode.
 - Subtract guest RAM for the identity page table and the VM86 TSS.
 - Split the creation of the unrestricted mode helper structures to a
   separate function.
 - Use preemption with paging_set_allocation.
 - Use get_order_from_bytes_floor.
---
 xen/arch/x86/domain_build.c | 299 +++-
 xen/arch/x86/mm.c   |  16 +++
 xen/include/asm-x86/mm.h|   2 +
 3 files changed, 312 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 4d555b1..fbce1c2 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +44,9 @@ static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
 static long __initdata dom0_max_nrpages = LONG_MAX;
 
+/* Size of the VM86 TSS for virtual 8086 mode to use. */
+#define HVM_VM86_TSS_SIZE   128
+
 /*
  * dom0_mem=[min:,][max:,][]
  * 
@@ -244,11 +248,12 @@ boolean_param("ro-hpet", ro_hpet);
 #define round_pgup(_p)(((_p)+(PAGE_SIZE-1))_MASK)
 #define round_pgdown(_p)  ((_p)_MASK)
 
+static unsigned int __initdata memflags = MEMF_no_dma|MEMF_exact_node;
+
 static struct page_info * __init alloc_chunk(
 struct domain *d, unsigned long max_pages)
 {
 static unsigned int __initdata last_order = MAX_ORDER;
-static unsigned int __initdata memflags = MEMF_no_dma|MEMF_exact_node;
 struct page_info *page;
 unsigned int order = get_order_from_pages(max_pages), free_order;
 
@@ -333,7 +338,9 @@ static unsigned long __init compute_dom0_nr_pages(
 avail -= max_pdx >> s;
 }
 
-need_paging = opt_dom0_shadow || (is_pvh_domain(d) && !iommu_hap_pt_share);
+need_paging = opt_dom0_shadow ||
+  (has_hvm_container_domain(d) && (!iommu_hap_pt_share ||
+   !paging_mode_hap(d)));
 for ( ; ; need_paging = 0 )
 {
 nr_pages = dom0_nrpages;
@@ -365,7 +372,8 @@ static unsigned long __init compute_dom0_nr_pages(
 avail -= dom0_paging_pages(d, nr_pages);
 }
 
-if ( (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
+if ( is_pv_domain(d) &&
+ (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
  ((dom0_min_nrpages <= 0) || (nr_pages > min_pages)) )
 

[Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function

[Roger Pau Monne]

Current __hvm_copy assumes that the destination memory belongs to the current
vcpu, but this is not always the case since for PVHv2 Dom0 build hvm copy
functions are used with current being the idle vcpu. Add a new vcpu parameter
to hvm copy in order to solve that. Note that only hvm_copy_to_guest_phys_vcpu
is introduced, because that's the only one at the moment that's required in
order to build a PVHv2 Dom0.

While there, also assert that the passed vcpu belongs to a HVM guest.

Signed-off-by: Roger Pau Monné 
---
Changes since v4:
 - New in the series.
---
 xen/arch/x86/hvm/hvm.c| 40 ---
 xen/include/asm-x86/hvm/support.h |  2 ++
 2 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 41a44c9..600a04d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3077,15 +3077,16 @@ void hvm_task_switch(
 #define HVMCOPY_linear (1u<<2)
 static enum hvm_copy_result __hvm_copy(
 void *buf, paddr_t addr, int size, unsigned int flags, uint32_t pfec,
-pagefault_info_t *pfinfo)
+pagefault_info_t *pfinfo, struct vcpu *vcpu)
 {
-struct vcpu *curr = current;
 unsigned long gfn;
 struct page_info *page;
 p2m_type_t p2mt;
 char *p;
 int count, todo = size;
 
+ASSERT(has_hvm_container_vcpu(vcpu));
+
 /*
  * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
  * such as query_size. Grant-table code currently does copy_to/from_guest
@@ -3110,7 +3111,7 @@ static enum hvm_copy_result __hvm_copy(
 
 if ( flags & HVMCOPY_linear )
 {
-gfn = paging_gva_to_gfn(curr, addr, );
+gfn = paging_gva_to_gfn(vcpu, addr, );
 if ( gfn == gfn_x(INVALID_GFN) )
 {
 if ( pfec & PFEC_page_paged )
@@ -3137,12 +3138,12 @@ static enum hvm_copy_result __hvm_copy(
  * - 32-bit WinXP (& older Windows) on AMD CPUs for LAPIC accesses,
  * - newer Windows (like Server 2012) for HPET accesses.
  */
-if ( !nestedhvm_vcpu_in_guestmode(curr)
- && is_hvm_vcpu(curr)
+if ( !nestedhvm_vcpu_in_guestmode(vcpu)
+ && is_hvm_vcpu(vcpu)
  && hvm_mmio_internal(gpa) )
 return HVMCOPY_bad_gfn_to_mfn;
 
-page = get_page_from_gfn(curr->domain, gfn, , P2M_UNSHARE);
+page = get_page_from_gfn(vcpu->domain, gfn, , P2M_UNSHARE);
 
 if ( !page )
 return HVMCOPY_bad_gfn_to_mfn;
@@ -3150,7 +3151,7 @@ static enum hvm_copy_result __hvm_copy(
 if ( p2m_is_paging(p2mt) )
 {
 put_page(page);
-p2m_mem_paging_populate(curr->domain, gfn);
+p2m_mem_paging_populate(vcpu->domain, gfn);
 return HVMCOPY_gfn_paged_out;
 }
 if ( p2m_is_shared(p2mt) )
@@ -3172,9 +3173,9 @@ static enum hvm_copy_result __hvm_copy(
 {
 static unsigned long lastpage;
 if ( xchg(, gfn) != gfn )
-gdprintk(XENLOG_DEBUG, "guest attempted write to read-only"
+printk(XENLOG_DEBUG, "%pv guest attempted write to 
read-only"
  " memory page. gfn=%#lx, mfn=%#lx\n",
- gfn, page_to_mfn(page));
+ vcpu->domain, gfn, page_to_mfn(page));
 }
 else
 {
@@ -3182,7 +3183,7 @@ static enum hvm_copy_result __hvm_copy(
 memcpy(p, buf, count);
 else
 memset(p, 0, count);
-paging_mark_dirty(curr->domain, _mfn(page_to_mfn(page)));
+paging_mark_dirty(vcpu->domain, _mfn(page_to_mfn(page)));
 }
 }
 else
@@ -3202,18 +3203,25 @@ static enum hvm_copy_result __hvm_copy(
 return HVMCOPY_okay;
 }
 
+enum hvm_copy_result hvm_copy_to_guest_phys_vcpu(
+paddr_t paddr, void *buf, size_t size, struct vcpu *vcpu)
+{
+return __hvm_copy(buf, paddr, size,
+  HVMCOPY_to_guest | HVMCOPY_phys, 0, NULL, vcpu);
+}
+
 enum hvm_copy_result hvm_copy_to_guest_phys(
 paddr_t paddr, void *buf, int size)
 {
 return __hvm_copy(buf, paddr, size,
-  HVMCOPY_to_guest | HVMCOPY_phys, 0, NULL);
+  HVMCOPY_to_guest | HVMCOPY_phys, 0, NULL, current);
 }
 
 enum hvm_copy_result hvm_copy_from_guest_phys(
 void *buf, paddr_t paddr, int size)
 {
 return __hvm_copy(buf, paddr, size,
-  HVMCOPY_from_guest | HVMCOPY_phys, 0, NULL);
+  HVMCOPY_from_guest | HVMCOPY_phys, 0, NULL, current);
 }
 
 enum hvm_copy_result hvm_copy_to_guest_linear(
@@ -3222,7 +3230,8 @@ enum hvm_copy_result hvm_copy_to_guest_linear(
 {
 return __hvm_copy(buf, addr, size,
   HVMCOPY_to_guest | HVMCOPY_linear,
-  PFEC_page_present | 

[Xen-devel] [PATCH v5 0/9] Initial PVHv2 Dom0 support

[Roger Pau Monne]

Hello,

This is the first batch of the PVHv2 Dom0 support series, that includes
everything up to the point where ACPI tables for Dom0 are crafted. I've
decided to left the last part of the series (the one that contains the PCI
config space handlers, and other emulation/trapping related code) separated,
in order to focus and ease the review. This is of course not functional, one
might be able to partially boot a Dom0 kernel if it doesn't try to access
any physical devices, and the panic in setup.c is removed.

The full series can also be found on a git branch in my personal git repo:

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

Each patch contains the changelog between versions.

This series is based on top of Andrew Cooper's "x86/cpuid: Handling of simple
leaves in guest_cpuid()", although the dependency is only functional, there
should be no merge conflicts as a result of one going in before or after the
other.

Thanks, Roger.


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

[Xen-devel] [PATCH v5 2/9] x86/iommu: add IOMMU entries for p2m_mmio_direct pages

[Roger Pau Monne]

There's nothing wrong with allowing the domain to perform DMA transfers to
MMIO areas that it already can access from the CPU, and this allows us to
remove the hack in set_identity_p2m_entry for PVH Dom0.

Signed-off-by: Roger Pau Monné 
---
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - Check for mmio_ro_ranges, this requires passing the mfn to the function, and
   fixing the callers.
---
 xen/arch/x86/mm/p2m-ept.c |  5 +++--
 xen/arch/x86/mm/p2m-pt.c  | 17 ++---
 xen/arch/x86/mm/p2m.c |  9 -
 xen/include/asm-x86/p2m.h |  6 +-
 4 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 13cab24..0e316ba 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -672,7 +672,7 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 uint8_t ipat = 0;
 bool_t need_modify_vtd_table = 1;
 bool_t vtd_pte_present = 0;
-unsigned int iommu_flags = p2m_get_iommu_flags(p2mt);
+unsigned int iommu_flags = p2m_get_iommu_flags(p2mt, mfn);
 bool_t needs_sync = 1;
 ept_entry_t old_entry = { .epte = 0 };
 ept_entry_t new_entry = { .epte = 0 };
@@ -798,7 +798,8 @@ ept_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 
 /* Safe to read-then-write because we hold the p2m lock */
 if ( ept_entry->mfn == new_entry.mfn &&
- p2m_get_iommu_flags(ept_entry->sa_p2mt) == iommu_flags )
+ p2m_get_iommu_flags(ept_entry->sa_p2mt, _mfn(ept_entry->mfn)) ==
+ iommu_flags )
 need_modify_vtd_table = 0;
 
 ept_p2m_type_to_flags(p2m, _entry, p2mt, p2ma);
diff --git a/xen/arch/x86/mm/p2m-pt.c b/xen/arch/x86/mm/p2m-pt.c
index 3b025d5..a23d0bd 100644
--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -499,7 +499,7 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long gfn, 
mfn_t mfn,
 l2_pgentry_t l2e_content;
 l3_pgentry_t l3e_content;
 int rc;
-unsigned int iommu_pte_flags = p2m_get_iommu_flags(p2mt);
+unsigned int iommu_pte_flags = p2m_get_iommu_flags(p2mt, mfn);
 /*
  * old_mfn and iommu_old_flags control possible flush/update needs on the
  * IOMMU: We need to flush when MFN or flags (i.e. permissions) change.
@@ -565,9 +565,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( flags & _PAGE_PSE )
 {
-iommu_old_flags =
-p2m_get_iommu_flags(p2m_flags_to_type(flags));
 old_mfn = l1e_get_pfn(*p2m_entry);
+iommu_old_flags =
+p2m_get_iommu_flags(p2m_flags_to_type(flags),
+_mfn(old_mfn));
 }
 else
 {
@@ -609,9 +610,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 p2m_entry = p2m_find_entry(table, _remainder, gfn,
0, L1_PAGETABLE_ENTRIES);
 ASSERT(p2m_entry);
-iommu_old_flags =
-p2m_get_iommu_flags(p2m_flags_to_type(l1e_get_flags(*p2m_entry)));
 old_mfn = l1e_get_pfn(*p2m_entry);
+iommu_old_flags =
+p2m_get_iommu_flags(p2m_flags_to_type(l1e_get_flags(*p2m_entry)),
+_mfn(old_mfn));
 
 if ( mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt) )
 entry_content = p2m_l1e_from_pfn(mfn_x(mfn),
@@ -637,9 +639,10 @@ p2m_pt_set_entry(struct p2m_domain *p2m, unsigned long 
gfn, mfn_t mfn,
 {
 if ( flags & _PAGE_PSE )
 {
-iommu_old_flags =
-p2m_get_iommu_flags(p2m_flags_to_type(flags));
 old_mfn = l1e_get_pfn(*p2m_entry);
+iommu_old_flags =
+p2m_get_iommu_flags(p2m_flags_to_type(flags),
+_mfn(old_mfn));
 }
 else
 {
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 6a45185..7e33ab6 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1053,16 +1053,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
long gfn,
 ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
 p2m_mmio_direct, p2ma);
 else if ( mfn_x(mfn) == gfn && p2mt == p2m_mmio_direct && a == p2ma )
-{
 ret = 0;
-/*
- * PVH fixme: during Dom0 PVH construction, p2m entries are being set
- * but iomem regions are not mapped with IOMMU. This makes sure that
- * RMRRs are correctly mapped with IOMMU.
- */
-if ( is_hardware_domain(d) && !iommu_use_hap_pt(d) )
-ret = 

[Xen-devel] [PATCH v5 1/9] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne]

PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
from physical or emulated devices over event channels using PIRQs. This
applies to both DomU and Dom0 PVHv2 guests.

Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
route physical interrupts (even from emulated devices) over event channels,
and is thus allowed to use some of the PHYSDEV ops.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v3:
 - Update docs.

Changes since v2:
 - Change local variable name to currd instead of d.
 - Use currd where it makes sense.
---
 docs/misc/hvmlite.markdown| 20 
 xen/arch/x86/hvm/hvm.c| 25 -
 xen/arch/x86/physdev.c|  5 +++--
 xen/common/kernel.c   |  3 ++-
 xen/include/public/arch-x86/xen.h |  4 +++-
 5 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 898b8ee..b2557f7 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,23 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## Interrupts ##
+
+### Interrupts from physical devices ###
+
+Interrupts from physical devices are delivered using native methods, this is
+done in order to take advantage of new hardware assisted virtualization
+functions, like posted interrupts. This implies that PVHv2 guests with physical
+devices will also have the necessary interrupt controllers in order to manage
+the delivery of interrupts from those devices, using the same interfaces that
+are available on native hardware.
+
+### Interrupts from paravirtualized devices ###
+
+Interrupts from paravirtualized devices are delivered using event channels, see
+[Event Channel Internals][event_channels] for more detailed information about
+event channels. Delivery of those interrupts can be configured in the same way
+as HVM guests, check xen/include/public/hvm/params.h and
+xen/include/public/hvm/hvm_op.h for more information about available delivery
+methods.
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 63748dc..41a44c9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3757,10 +3757,12 @@ static long hvm_memory_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 
 static long hvm_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *currd = current->domain;
+
 switch ( cmd )
 {
 default:
-if ( !is_pvh_vcpu(current) || !is_hardware_domain(current->domain) )
+if ( !is_pvh_domain(currd) || !is_hardware_domain(currd) )
 return -ENOSYS;
 /* fall through */
 case PHYSDEVOP_map_pirq:
@@ -3768,7 +3770,9 @@ static long hvm_physdev_op(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 case PHYSDEVOP_eoi:
 case PHYSDEVOP_irq_status_query:
 case PHYSDEVOP_get_free_pirq:
-return do_physdev_op(cmd, arg);
+return ((currd->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) ||
+   is_pvh_domain(currd)) ?
+do_physdev_op(cmd, arg) : -ENOSYS;
 }
 }
 
@@ -3801,17 +3805,20 @@ static long hvm_memory_op_compat32(int cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 static long hvm_physdev_op_compat32(
 int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
+struct domain *d = current->domain;
+
 switch ( cmd )
 {
-case PHYSDEVOP_map_pirq:
-case PHYSDEVOP_unmap_pirq:
-case PHYSDEVOP_eoi:
-case PHYSDEVOP_irq_status_query:
-case PHYSDEVOP_get_free_pirq:
-return compat_physdev_op(cmd, arg);
+case PHYSDEVOP_map_pirq:
+case PHYSDEVOP_unmap_pirq:
+case PHYSDEVOP_eoi:
+case PHYSDEVOP_irq_status_query:
+case PHYSDEVOP_get_free_pirq:
+return (d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) ?
+compat_physdev_op(cmd, arg) : -ENOSYS;
 break;
 default:
-return -ENOSYS;
+return -ENOSYS;
 break;
 }
 }
diff --git a/xen/arch/x86/physdev.c b/xen/arch/x86/physdev.c
index 5a49796..0bea6e1 100644
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -94,7 +94,8 @@ int physdev_map_pirq(domid_t domid, int type, int *index, int 
*pirq_p,
 int pirq, irq, ret = 0;
 void *map_data = NULL;
 
-if ( domid == DOMID_SELF && is_hvm_domain(d) )
+if ( domid == DOMID_SELF && is_hvm_domain(d) &&
+ (d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) )
 {
 /*
  * Only makes sense for vector-based callback, else HVM-IRQ logic
@@ -265,7 +266,7 @@ int physdev_unmap_pirq(domid_t domid, int pirq)
 if ( ret )
 goto free_domain;
 
-if ( is_hvm_domain(d) )
+if ( is_hvm_domain(d) && (d->arch.emulation_flags & XEN_X86_EMU_USE_PIRQ) 

[Xen-devel] [PATCH v5 7/9] x86/PVHv2: fix dom0_max_vcpus so it's capped to 128 for PVHv2 Dom0

[Roger Pau Monne]

PVHv2 Dom0 is limited to 128 vCPUs, as are all HVM guests at the moment. Fix
dom0_max_vcpus so it takes this limitation into account by poking at the
dom0_hvm variable.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Change since v4:
 - Fix codding style to match rest of the function.

Changes since v3:
 - New in the series.
---
 xen/arch/x86/domain_build.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index 4f5f712..55caa30 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -40,6 +40,7 @@
 
 #include 
 #include 
+#include 
 
 static long __initdata dom0_nrpages;
 static long __initdata dom0_min_nrpages;
@@ -176,6 +177,8 @@ unsigned int __init dom0_max_vcpus(void)
 max_vcpus = opt_dom0_max_vcpus_max;
 if ( max_vcpus > MAX_VIRT_CPUS )
 max_vcpus = MAX_VIRT_CPUS;
+if ( dom0_pvh && max_vcpus > HVM_MAX_VCPUS )
+max_vcpus = HVM_MAX_VCPUS;
 
 return max_vcpus;
 }
-- 
2.10.1 (Apple Git-78)


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

[Xen-devel] [PATCH v5 9/9] xen/x86: setup PVHv2 Dom0 ACPI tables

[Roger Pau Monne]

Create a new MADT table that contains the topology exposed to the guest. A
new XSDT table is also created, in order to filter the tables that we want
to expose to the guest, plus the Xen crafted MADT. This in turn requires Xen
to also create a new RSDP in order to make it point to the custom XSDT.

Also, regions marked as E820_ACPI or E820_NVS are identity mapped into Dom0
p2m, plus any top-level ACPI tables that should be accessible to Dom0 and
reside in reserved regions. This is needed because some memory maps don't
properly account for all the memory used by ACPI, so it's common to find ACPI
tables in reserved regions.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v4:
 - s/hvm/pvh.
 - Use hvm_copy_to_guest_phys_vcpu.
 - Don't allocate up to E820MAX entries for the Dom0 memory map and instead
   allow pvh_add_mem_range to dynamically grow the memory map.
 - Add a comment about the lack of x2APIC MADT entries.
 - Change acpi_intr_overrides to unsigned int and the max iterator bound to
   UINT_MAX.
 - Set the MADT version as the minimum version between the hardware value and
   our supported version (4).
 - Set the MADT IO APIC ID to the current value of the domain vioapic->id.
 - Use void * when subtracting two pointers.
 - Fix indentation of nr_pages and use PFN_UP instead of DIV_ROUND_UP.
 - Change wording of the pvh_acpi_table_allowed error message.
 - Make j unsigned in pvh_setup_acpi_xsdt.
 - Move initialization of local variables with declarations in
   pvh_setup_acpi_xsdt.
 - Reword the comment about the allocated size of the xsdt custom table.
 - Fix line splitting.
 - Add a comment regarding the layering violation caused by the usage of
   acpi_tb_checksum.
 - Pass IO APIC NMI sources found in the MADT to Dom0.
 - Create x2APIC entries if the native MADT also contains them.
 - s/acpi_intr_overrrides/acpi_intr_overrides/.
 - Make sure the MADT is properly mapped into Dom0, or else Dom0 might not be
   able to access the output of the _MAT method depending on the
   implementation.
 - Get the first ACPI processor ID and use that as the base processor ID of the
   crafted MADT. This is done so that local/x2 APIC NMI entries match with the
   local/x2 APIC objects.

Changes since v3:
 - Use hvm_copy_to_phys in order to copy the tables to Dom0 memory.
 - Return EEXIST for overlaping ranges in hvm_add_mem_range.
 - s/ov/ovr/ for interrupt override parsing functions.
 - Constify intr local variable in acpi_set_intr_ovr.
 - Use structure asignement for type safety.
 - Perform sizeof using local variables in hvm_setup_acpi_madt.
 - Manually set revision of crafted/modified tables.
 - Only map tables to guest that reside in reserved or ACPI memory regions.
 - Copy the RSDP OEM signature to the crafted RSDP.
 - Pair calls to acpi_os_map_memory/acpi_os_unmap_memory.
 - Add memory regions for allowed ACPI tables to the memory map and then
   perform the identity mappings. This avoids having to call 
modify_identity_mmio
   multiple times.
 - Add a FIXME comment regarding the lack of multiple vIO-APICs.

Changes since v2:
 - Completely reworked.
---
 xen/arch/x86/domain_build.c | 517 
 1 file changed, 517 insertions(+)

diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index ca5d393..3331f3b 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -38,6 +39,8 @@
 #include 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -50,6 +53,14 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
 /* Size of the VM86 TSS for virtual 8086 mode to use. */
 #define HVM_VM86_TSS_SIZE   128
 
+static unsigned int __initdata acpi_intr_overrides;
+static struct acpi_madt_interrupt_override __initdata *intsrcovr;
+
+static unsigned int __initdata acpi_nmi_sources;
+static struct acpi_madt_nmi_source __initdata *nmisrc;
+
+static bool __initdata acpi_x2apic;
+
 /*
  * dom0_mem=[min:,][max:,][]
  * 
@@ -1812,6 +1823,58 @@ static int __init pvh_steal_ram(struct domain *d, 
unsigned long size,
 return -ENOMEM;
 }
 
+/* NB: memory map must be sorted at all times for this to work correctly. */
+static int __init pvh_add_mem_range(struct domain *d, uint64_t s, uint64_t e,
+unsigned int type)
+{
+struct e820entry *map;
+unsigned int i;
+
+for ( i = 0; i < d->arch.nr_e820; i++ )
+{
+uint64_t rs = d->arch.e820[i].addr;
+uint64_t re = rs + d->arch.e820[i].size;
+
+if ( rs == e && d->arch.e820[i].type == type )
+{
+d->arch.e820[i].addr = s;
+return 0;
+}
+
+if ( re == s && d->arch.e820[i].type == type &&
+ (i + 1 == d->arch.nr_e820 || d->arch.e820[i + 1].addr >= e) )
+{
+

Re: [Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

[George Dunlap]

On 18/01/17 19:56, Ronald Rojas wrote:
> Create error type Errorxl for throwing proper xenlight
> errors.
> 
> Update Ctx functions to throw Errorxl errors.
> 
> Signed-off-by: Ronald Rojas 

Overall, looks good!  Thanks for this.  Just a few minor comments.

> ---
>  tools/golang/xenlight/xenlight.go | 77 
> +--
>  1 file changed, 73 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> index 1f10e51..d58f8b8 100644
> --- a/tools/golang/xenlight/xenlight.go
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -32,6 +32,77 @@ import (
>  )
>  
>  /*
> + * Errors
> + */
> +type Errorxl int

Is there a reason not to make this just "Error"?  The callers will have
to use the namespace anyway (xenlight.Error).

> +
> +const (
> + ErrorNonspecific  = Errorxl(-C.ERROR_NONSPECIFIC)
> + ErrorVersion  = Errorxl(-C.ERROR_VERSION)
> + ErrorFail = Errorxl(-C.ERROR_FAIL)
> + ErrorNi   = Errorxl(-C.ERROR_NI)
> + ErrorNomem= Errorxl(-C.ERROR_NOMEM)
> + ErrorInval= Errorxl(-C.ERROR_INVAL)
> + ErrorBadfail  = Errorxl(-C.ERROR_BADFAIL)
> + ErrorGuestTimedout= Errorxl(-C.ERROR_GUEST_TIMEDOUT)
> + ErrorTimedout = Errorxl(-C.ERROR_TIMEDOUT)
> + ErrorNoparavirt   = Errorxl(-C.ERROR_NOPARAVIRT)
> + ErrorNotReady = Errorxl(-C.ERROR_NOT_READY)
> + ErrorOseventRegFail   = Errorxl(-C.ERROR_OSEVENT_REG_FAIL)
> + ErrorBufferfull   = Errorxl(-C.ERROR_BUFFERFULL)
> + ErrorUnknownChild = Errorxl(-C.ERROR_UNKNOWN_CHILD)
> + ErrorLockFail = Errorxl(-C.ERROR_LOCK_FAIL)
> + ErrorJsonConfigEmpty  = Errorxl(-C.ERROR_JSON_CONFIG_EMPTY)
> + ErrorDeviceExists = Errorxl(-C.ERROR_DEVICE_EXISTS)
> + ErrorCheckpointDevopsDoesNotMatch = 
> Errorxl(-C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
> + ErrorCheckpointDeviceNotSupported = 
> Errorxl(-C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
> + ErrorVnumaConfigInvalid   = 
> Errorxl(-C.ERROR_VNUMA_CONFIG_INVALID)
> + ErrorDomainNotfound   = Errorxl(-C.ERROR_DOMAIN_NOTFOUND)
> + ErrorAborted  = Errorxl(-C.ERROR_ABORTED)
> + ErrorNotfound = Errorxl(-C.ERROR_NOTFOUND)
> + ErrorDomainDestroyed  = Errorxl(-C.ERROR_DOMAIN_DESTROYED)
> + ErrorFeatureRemoved   = Errorxl(-C.ERROR_FEATURE_REMOVED)
> +)

So here you define the constants as positive integers corresponding to
libxl's negative integers, so that you can use them for array indexes in
the string table below.

But when you return an error from libxl itself, you simply cast it to
Errorxl(), leaving it negative; this means that you can't actually
compare err with the constants here -- you have to negate it, which is a
bit strange.

I think probably negating the C libxl values for the golang constants,
as you have done here, makes sense.  But then you should negate the
values you get back from libxl as well, so that they match.

> +
> +var errors = [...]string{
> + ErrorNonspecific:  "Non-specific error",
> + ErrorVersion:  "Wrong version",
> + ErrorFail: "Failed",
> + ErrorNi:   "Null",

"Not implemented"

> + ErrorNomem:"No memory",
> + ErrorInval:"Invalid",

probably "Invalid argument"

> + ErrorBadfail:  "Bad Fail",
> + ErrorGuestTimedout:"Guest timed out",
> + ErrorTimedout: "Timed out",
> + ErrorNoparavirt:   "No Paravirtualization",
> + ErrorNotReady: "Not ready",
> + ErrorOseventRegFail:   "OS event failed",

"OS event registration failed"

> + ErrorBufferfull:   "Buffer full",
> + ErrorUnknownChild: "Unknown child",
> + ErrorLockFail: "Lock failed",
> + ErrorJsonConfigEmpty:  "JSON config empyt",

empty

> + ErrorDeviceExists: "Device exists",
> + ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does not match",
> + ErrorCheckpointDeviceNotSupported: "Checkpoint device not supported",
> + ErrorVnumaConfigInvalid:   "VNUMA config invalid",
> + ErrorDomainNotfound:   "Domain not found",
> + ErrorAborted:  "Aborted",
> + ErrorNotfound: "Not found",
> + ErrorDomainDestroyed:  "Domain destroyed",
> + ErrorFeatureRemoved:   "Feature removed",
> +}
> +
> +func 

[Xen-devel] [PATCH 1/1] kexec: ensure kexec_status() return bit value of 0 or 1

[Eric DeVolder]

When checking kexec_flags bit corresponding to the
requested image, ensure that 0 or 1 is returned.

Signed-off-by: Eric DeVolder 
---
 xen/common/kexec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index aa808cb..3da27bf 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -1182,7 +1182,8 @@ static int kexec_status(XEN_GUEST_HANDLE_PARAM(void) uarg)
 if ( kexec_load_get_bits(status.type, , ) )
 return -EINVAL;
 
-return test_bit(bit, _flags);
+/* Ensure return bit value of 0 or 1 */
+return !!test_bit(bit, _flags);
 }
 
 static int do_kexec_op_internal(unsigned long op,
-- 
2.7.4


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

[Xen-devel] [PATCH 0/1] Followup corrections for kexec_status()

[Eric DeVolder]

Jan,
This corrects the use of test_bit() in kexec_status().

Wei,
This patch is against the kexec_status() recently applied to staging.

Regards,
Eric


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

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

[Boris Ostrovsky]

On 01/18/2017 10:05 AM, osstest service owner wrote:
> flight 104237 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/104237/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 
> 59254
>  test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 
> 59254

Assuming that the last session in serial-nocera1.log is the one that
failed, I wonder whether these is something with the mpt2sas --- it's
the last thing that's reported before debug-keys are activated:

Jan 18 08:47:25.033615 [   40.938069] sd 4:0:0:0: attempting task abort! 
scmd(db67b800)
Jan 18 08:47:47.705686 [   40.938090] sd 4:0:0:0: [sda] tag#0 CDB: ATA command 
pass through(12)/Blank a1 08 2e 00 01 00 00 00 00 ec 00 00
Jan 18 08:47:47.713625 [   40.938097] scsi target4:0:0: handle(0x0009), 
sas_address(0x443322110700), phy(7)
Jan 18 08:47:47.721635 [   40.938102] scsi target4:0:0: 
enclosure_logical_id(0x5b083fe0e50a5700), slot(0)
Jan 18 08:47:47.729630 [   40.938129] sd 4:0:0:0: task abort: SUCCESS 
scmd(db67b800)



>  test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 
> 59254
>  test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 
> 59254
>  build-armhf-pvops 5 kernel-build  fail REGR. vs. 
> 59254


ARM build seems to be caused by some sort of a timeout. The script
allows about 2.5 hours for the build to complete and it looks like it is
close to finishing it. Hard to say why it takes that long but I see no
build errors --- IIUIC the build is aborted due to the timeout.


-boris


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

Re: [Xen-devel] tap device name for emulated NIC too long

[Wei Liu]

Sorry, this fell through the crack.

On Wed, Nov 30, 2016 at 06:38:45PM -0700, Jim Fehlig wrote:
> Hi All,
> 
> During the last Wg-openstack meetup we briefly discussed a long-standing bug
> when using Xen+libvirt+OpenStack with Neutron networking
> 
> https://bugs.launchpad.net/nova/+bug/1450465
> 
> The bug was also discussed on this list with no resolution
> 
> https://lists.xenproject.org/archives/html/xen-devel/2015-06/msg04116.html
> 
> To summarize: the tap device name for an emulated NIC is too long after
> libxl appends '-emu' to the name provided by Neutron. Some proposed fixes
> include
> 
> 1. Shorten '-emu' to just '-e', avoiding IFNAMSIZ limit. But users are free
> to provide a name that already occupies the full IFNAMSIZ. Also, the
> user-provided name may be used in rules, filters, etc. elsewhere in the
> network, so modifying it at all seems questionable.
> 

This is just a workaround, not a solution. As you said, there is no way
to prevent users from setting a long name.

> 2. Change OpenStack to not exceed IFNAMSIZ-4 when specifying Xen vif name.
> This could be proposed to the Neutron devs, but IMO adding such Xen-specific
> hacks in OpenStack is undesirable.
> 

Is there a knob to tune the name length in Neutron? Then we can set such
knob in Xen driver (not sure if it is the right term in Neutron)?

I think such knob would not be Xen specific. I would go further to say
tying Neutron to Linux specific thing is a bug. What if Linux changes
IFNAMSIZ some day?  What if other OSes need to be supported?

Long term I think having such knob in Neutron and let specific driver
tune it would be the best option for Neutron. And the angle is no more
Xen specific, so it might be easier to sell to Neutron devs?

> 3. Change the Xen default vif type from 'ioemu' to 'vif' (see
> docs/misc/xl-network-configuration.markdown), which avoids creating an
> emulated device. (Note: such a change could be made in Xen or libvirt.) But
> I think this is a no-go. I'd suspect it would result in a lot of broken
> configurations. E.g. a guest may not have PV drivers and is relying on the
> emulated device. Or the guest may be configured to network boot, in which
> case the emulated device would be needed for PXE [0].
> 

Correct, this is a no-go option.

Wei.

> We (the Wg-openstack folks) would like to hear your opinions on these
> proposals, or alternatives for fixing this bug.
> 
> Regards,
> Jim
> 
> [0] iPXE claims support for Xen netfront devices, but I've not yet got it to
> work: http://lists.ipxe.org/pipermail/ipxe-devel/2014-July/003674.html
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 1/6] libxl: add "merge" function to generic device type support

[Juergen Gross]

On 19/01/17 17:19, Wei Liu wrote:
> On Thu, Jan 19, 2017 at 05:14:35PM +0100, Olaf Hering wrote:
>> On Tue, Jul 12, Juergen Gross wrote:
>>
>>> Instead of using a macro generating the code to merge xenstore and
>>> json configuration data, use the generic device type support for
>>> this purpose.
>>> This requires to add some accessor functions to the framework and
>>> a structure for disks (as disks are added separately they didn't need
>>> such a structure up to now).
>>
>>> +++ b/tools/libxl/libxl.c
>>> @@ -7371,93 +7371,68 @@ int libxl_retrieve_domain_configuration(libxl_ctx 
>>> *ctx, uint32_t domid,
>>
>>> +if (!dt->list || !dt->compare)
>>> +continue;
>>
>>
>> This makes libxl_device__compare optional ...
> 
> Actually this makes both list and compare optional.
> 
> I would say both should be mandatory -- why would you have a device type
> that can't be listed or compared?
> 
> Juergen?

I think above lines predate the introduction of
DEFINE_DEVICE_TYPE_STRUCT_X().

They can probably be removed.


Juergen


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

[Xen-devel] [ovmf baseline-only test] 68395: tolerable trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i3863 host-install(3)   broken baseline untested
 build-amd64   3 host-install(3)   broken baseline untested
 build-i386-pvops  3 host-install(3)   broken baseline untested
 build-i386-xsm3 host-install(3)   broken baseline untested
 build-amd64-pvops 3 host-install(3)   broken baseline untested
 build-amd64-xsm   3 host-install(3)   broken baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 88fd27e5b2cae68ff5a11cd5560ef5f98d001c42
baseline version:
 ovmf 7be6e6776253d3638f03375e346e978228af5edb

Last test of basis68391  2017-01-18 11:19:02 Z1 days
Testing same since68395  2017-01-19 05:18:18 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

broken-step build-i386 host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386-pvops host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)
broken-step build-amd64-xsm host-install(3)

Push not applicable.


commit 88fd27e5b2cae68ff5a11cd5560ef5f98d001c42
Author: Star Zeng 
Date:   Tue Jan 17 11:41:57 2017 +0800

MdePkg: Correct comments of macros FixedPcdGetX/PatchPcdXXX in PcdLib.h

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=311

The patch is also to refine comments of macros PcdToken and PcdTokenEx.

Cc: Liming Gao 
Cc: Michael Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Liming Gao 

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

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

[George Dunlap]

On 18/01/17 19:56, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
> 
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
> 
> For now, return simple errors. Proper error handling will be
> added in next patch.
> 
> Signed-off-by: Ronald Rojas 
> ---
>  tools/Makefile| 15 +++-
>  tools/golang/xenlight/Makefile| 29 ++
>  tools/golang/xenlight/xenlight.go | 80 
> +++
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 tools/golang/xenlight/Makefile
>  create mode 100644 tools/golang/xenlight/xenlight.go
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 77e0723..fd49e7f 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -6,12 +6,13 @@ SUBDIRS-y += include
>  SUBDIRS-y += libs
>  SUBDIRS-y += libxc
>  SUBDIRS-y += flask
> -SUBDIRS-y += fuzz
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples
>  SUBDIRS-y += hotplug
>  SUBDIRS-y += xentrace
> +#Uncomment line to build Golang libxl
> +#SUBDIRS-y += golang/xenlight
>  SUBDIRS-$(CONFIG_XCUTILS) += xcutils
>  SUBDIRS-$(CONFIG_X86) += firmware
>  SUBDIRS-y += console
> @@ -322,6 +323,18 @@ subdir-install-debugger/kdd: .phony
>  subdir-all-debugger/kdd: .phony
>   $(MAKE) -C debugger/kdd all
>  
> +subdir-clean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight clean
> +
> +subdir-distclean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight distclean
> +
> +subdir-install-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight install
> +
> +subdir-all-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight all
> +
>  subdir-distclean-firmware: .phony
>   $(MAKE) -C firmware distclean
>  
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> new file mode 100644
> index 000..a45336b
> --- /dev/null
> +++ b/tools/golang/xenlight/Makefile
> @@ -0,0 +1,29 @@
> +XEN_ROOT=$(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +BINARY = xenlightgo
> +GO = go
> +
> +.PHONY: all
> +all: build
> +
> +.PHONY: build
> +build: xenlight
> +
> +.PHONY: install
> +install: build
> + ! [ -f $(BINARY) ] || $(INSTALL_PROG) xenlight.go $(DESTDIR)$(bindir)
> +
> +.PHONY: clean
> +clean:
> + $(RM) $(BINARY)
> +
> +.PHONY: distclean
> +distclean: clean
> +
> +
> +xenlight: xenlight.go
> + $(GO) build -o $(BINARY) xenlight.go
> +
> +
> +-include $(DEPS)
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> new file mode 100644
> index 000..1f10e51
> --- /dev/null
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; version 2 of the
> + * License only.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> + * 02110-1301, USA.
> + */
> +package xenlight
> +
> +/*
> +#cgo LDFLAGS: -lxenlight -lyajl
> +#include 
> +#include 
> +*/
> +import "C"
> +
> +import (
> + "fmt"
> + "time"
> + "unsafe"
> +)

And finally -- this won't compile because we're not using the "time"
package yet.  This should be removed and added back in in the patch that
requires it.

 -George


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

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

[George Dunlap]

On 18/01/17 19:56, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
> 
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
> 
> For now, return simple errors. Proper error handling will be
> added in next patch.
> 
> Signed-off-by: Ronald Rojas 
> ---
>  tools/Makefile| 15 +++-
>  tools/golang/xenlight/Makefile| 29 ++
>  tools/golang/xenlight/xenlight.go | 80 
> +++
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 tools/golang/xenlight/Makefile
>  create mode 100644 tools/golang/xenlight/xenlight.go
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 77e0723..fd49e7f 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -6,12 +6,13 @@ SUBDIRS-y += include
>  SUBDIRS-y += libs
>  SUBDIRS-y += libxc
>  SUBDIRS-y += flask
> -SUBDIRS-y += fuzz
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples
>  SUBDIRS-y += hotplug
>  SUBDIRS-y += xentrace
> +#Uncomment line to build Golang libxl
> +#SUBDIRS-y += golang/xenlight
>  SUBDIRS-$(CONFIG_XCUTILS) += xcutils
>  SUBDIRS-$(CONFIG_X86) += firmware
>  SUBDIRS-y += console
> @@ -322,6 +323,18 @@ subdir-install-debugger/kdd: .phony
>  subdir-all-debugger/kdd: .phony
>   $(MAKE) -C debugger/kdd all
>  
> +subdir-clean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight clean
> +
> +subdir-distclean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight distclean
> +
> +subdir-install-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight install
> +
> +subdir-all-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight all
> +
>  subdir-distclean-firmware: .phony
>   $(MAKE) -C firmware distclean
>  
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> new file mode 100644
> index 000..a45336b
> --- /dev/null
> +++ b/tools/golang/xenlight/Makefile
> @@ -0,0 +1,29 @@
> +XEN_ROOT=$(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +BINARY = xenlightgo
> +GO = go
> +
> +.PHONY: all
> +all: build
> +
> +.PHONY: build
> +build: xenlight
> +
> +.PHONY: install
> +install: build
> + ! [ -f $(BINARY) ] || $(INSTALL_PROG) xenlight.go $(DESTDIR)$(bindir)
> +
> +.PHONY: clean
> +clean:
> + $(RM) $(BINARY)
> +
> +.PHONY: distclean
> +distclean: clean
> +
> +
> +xenlight: xenlight.go
> + $(GO) build -o $(BINARY) xenlight.go

Actually, one more thing here -- this will build using whatever version
of libxl you have installed *on the host system*, not the one you just
build as part of the build process.

You need to point the go compiler to use the version of libxl you've
just built in-tree, like this:

CGO_CFLAGS = -I$(DESTDIR)$(includedir)
CGO_LDFLAGS = -L$(DESTDIR)$(libdir) -Wl,-rpath-link=$(DESTDIR)$(libdir)
xenlight: xenlight.go
CGO_CFLAGS="$(CGO_CFLAGS)" CGO_LDFLAGS="$(CGO_LDFLAGS)" $(GO) build -o
$(BINARY) xenlight.go


 -George

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

Re: [Xen-devel] xennet_start_xmit assumptions

[David Miller]

From: Sowmini Varadhan 
Date: Thu, 19 Jan 2017 06:14:26 -0500

> I'll probably work on fixing packet_snd to return -EINVAL 
> or similar when the len is zero this week.

I thought we had code which made sure that at least a minimal
link layer header was present in the SKB?

Specifically I'm talking about the dev_validate_header() check.
That is supposed to protect us from these kinds of situations.

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

Re: [Xen-devel] IOMMU fault with IGD passthrough setup on XEN 4.8.0

[Jan Beulich]

>>> On 17.01.17 at 16:08,  wrote:
> But fortunately commenting out that line could still reproduce the IOMMU
> fault.
> I was lucky to capture the full log before it fills up my 100MB ring buffer
> (in less than 2 seconds).

So here's a first take at a debugging patch. I've tried to limit existing
output, so that you'd have better chance of again capturing all
interesting messages.

Jan

--- unstable.orig/xen/drivers/passthrough/vtd/iommu.c   2017-01-03 
10:55:55.0 +0100
+++ unstable/xen/drivers/passthrough/vtd/iommu.c2017-01-19 
17:26:48.0 +0100
@@ -897,8 +897,23 @@ static int iommu_page_fault_do_one(struc
kind, fault_reason, reason);
 
 if ( iommu_verbose && fault_type == DMA_REMAP )
+{//temp
+ static domid_t last;
+ static unsigned long cnt, thr;
+ const struct pci_dev*pdev;
+ pcidevs_lock();
+ pdev = pci_get_real_pdev(seg, PCI_BUS(source_id), PCI_DEVFN2(source_id));
+ if(pdev && pdev->domain && pdev->domain->domain_id > last) {
+  thr = cnt = 0;
+  last = pdev->domain->domain_id;
+ }
+ pcidevs_unlock();
+ if(++cnt > thr) {
+  thr |= cnt;
 print_vtd_entries(iommu, PCI_BUS(source_id), PCI_DEVFN2(source_id),
   addr >> PAGE_SHIFT);
+ }
+}
 
 return 0;
 }
@@ -1890,6 +1905,7 @@ static void iommu_set_pgd(struct domain
 
 static int rmrr_identity_mapping(struct domain *d, bool_t map,
  const struct acpi_rmrr_unit *rmrr,
+u16 bdf,//temp
  u32 flag)
 {
 unsigned long base_pfn = rmrr->base_address >> PAGE_SHIFT_4K;
@@ -1914,6 +1930,7 @@ static int rmrr_identity_mapping(struct
 if ( map )
 {
 ++mrmrr->count;
+printk(XENLOG_GUEST "d%d: RMRR [%lx,%lx] count %u\n", d->domain_id, base_pfn, 
end_pfn, mrmrr->count);//temp
 return 0;
 }
 
@@ -1928,6 +1945,7 @@ static int rmrr_identity_mapping(struct
 }
 
 list_del(>list);
+printk(XENLOG_GUEST "d%d: RMRR [%lx,%lx] zapped (%d)\n", d->domain_id, 
mrmrr->base >> PAGE_SHIFT_4K, end_pfn, ret);//temp
 xfree(mrmrr);
 return ret;
 }
@@ -1941,11 +1959,30 @@ static int rmrr_identity_mapping(struct
 int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
 
 if ( err )
+{//temp
+ printk(XENLOG_GUEST "d%d: RMRR [%lx,%lx] map error %d @ %lx\n", d->domain_id, 
rmrr->base_address >> PAGE_SHIFT_4K, end_pfn, err, base_pfn);
 return err;
+} else {
+ static domid_t last;
+ static unsigned long cnt, thr;
+ if(d->domain_id > last) {
+  thr = cnt = 0;
+  last = d->domain_id;
+ }
+ if(!(base_pfn & 0xff) && ++cnt > thr) {
+  const struct pci_dev*pdev = pci_get_pdev(rmrr->segment, PCI_BUS(bdf), 
PCI_DEVFN2(bdf));
+  const struct acpi_drhd_unit*drhd = pdev ? acpi_find_matched_drhd_unit(pdev) 
: NULL;
+  thr |= cnt;
+  printk(XENLOG_GUEST "d%d: RMRR [%lx,%lx] mapped %lx\n", d->domain_id, 
rmrr->base_address >> PAGE_SHIFT_4K, end_pfn, base_pfn);
+  if(drhd)
+   print_vtd_entries(drhd->iommu, PCI_BUS(bdf), PCI_DEVFN2(bdf), base_pfn);
+ }
+}
 base_pfn++;
 }
 
 mrmrr = xmalloc(struct mapped_rmrr);
+printk(XENLOG_GUEST "d%d: RMRR [%lx,%lx] alloc -> %p\n", d->domain_id, 
rmrr->base_address >> PAGE_SHIFT_4K, end_pfn, mrmrr);//temp
 if ( !mrmrr )
 return -ENOMEM;
 mrmrr->base = rmrr->base_address;
@@ -1987,7 +2024,7 @@ static int intel_iommu_add_device(u8 dev
  * Since RMRRs are always reserved in the e820 map for the hardware
  * domain, there shouldn't be a conflict.
  */
-ret = rmrr_identity_mapping(pdev->domain, 1, rmrr, 0);
+ret = rmrr_identity_mapping(pdev->domain, 1, rmrr, bdf, 0);
 if ( ret )
 dprintk(XENLOG_ERR VTDPREFIX, "d%d: RMRR mapping failed\n",
 pdev->domain->domain_id);
@@ -2032,7 +2069,7 @@ static int intel_iommu_remove_device(u8
  * Any flag is nothing to clear these mappings but here
  * its always safe and strict to set 0.
  */
-rmrr_identity_mapping(pdev->domain, 0, rmrr, 0);
+rmrr_identity_mapping(pdev->domain, 0, rmrr, bdf, 0);
 }
 
 return domain_context_unmap(pdev->domain, devfn, pdev);
@@ -2199,7 +2236,7 @@ static void __hwdom_init setup_hwdom_rmr
  * domain, there shouldn't be a conflict. So its always safe and
  * strict to set 0.
  */
-ret = rmrr_identity_mapping(d, 1, rmrr, 0);
+ret = rmrr_identity_mapping(d, 1, rmrr, bdf, 0);
 if ( ret )
 dprintk(XENLOG_ERR VTDPREFIX,
  "IOMMU: mapping reserved region failed\n");
@@ -2356,7 +2393,7 @@ static int reassign_device_ownership(
  * Any RMRR flag is always ignored when remove a device,
  * but its always safe and strict to set 0.
  */
-ret = 

[Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-qemut-win7-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-win7-amd64
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  0aa0313f9d576affd7747cc3f179feb097d28990
  Bug not present: bcc981e9ed84c678533299d7eff17d2c81e4d5de
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/104305/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-qemut-win7-amd64.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-qemut-win7-amd64.xen-boot
 --summary-out=tmp/104305.bisection-summary --basis-template=59254 
--blessings=real,real-bisect linux-linus test-amd64-amd64-xl-qemut-win7-amd64 
xen-boot
Searching for failure / basis pass:
 104237 fail [host=nocera0] / 92798 ok.
Failure / basis pass flights: 104237 / 92798
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 0aa0313f9d576affd7747cc3f179feb097d28990 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
b669e922b37b8957248798a5eb7aa96a666cd3fe 
5cd2e1739763915e6b4c247eef71f948dc808bd5 
5ad98e3c7fa92f46d77a788e1109b7d282bd1256
Basis pass bcc981e9ed84c678533299d7eff17d2c81e4d5de 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
ae69b059498e8a563c6d64c4aa4cb95e53d76680 
e0ec0a717d882ff0c0935b4893792d6aa95df3ef
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#bcc981e9ed84c678533299d7eff17d2c81e4d5de-0aa0313f9d576affd7747cc3f179feb097d28990
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-b669e922b37b8957248798a5eb7aa96a666cd3fe
 
git://xenbits.xen.org/qemu-xen.git#ae69b059498e8a563c6d64c4aa4cb95e53d76680-5cd2e1739763915e6b4c247eef71f948dc808bd5
 
git://xenbits.xen.org/xen.git#e0ec0a717d882ff0c0935b4893792d6aa95df3ef-5ad98e3c7fa92f46d77a788e1109b7d282bd1256
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
adhoc-revtuple-generator: tree discontiguous: xen
Loaded 1007 nodes in revision graph
Searching for test results:
 78977 [host=fiano0]
 79068 [host=fiano0]
 79155 [host=fiano0]
 79208 []
 79389 [host=fiano0]
 79450 [host=italia1]
 79587 [host=godello0]
 79778 [host=rimava1]
 79918 [host=rimava1]
 80122 [host=rimava1]
 80381 [host=rimava1]
 80627 [host=rimava1]
 81161 [host=chardonnay1]
 81424 [host=chardonnay1]
 81734 [host=huxelrebe1]
 82065 [host=chardonnay0]
 82419 pass irrelevant
 82614 pass irrelevant
 82764 pass irrelevant
 82911 pass irrelevant
 83118 pass irrelevant
 83452 pass irrelevant
 83655 pass irrelevant
 83810 pass irrelevant
 84169 pass irrelevant
 84300 pass irrelevant
 84379 pass irrelevant
 84472 pass irrelevant
 84616 pass irrelevant
 85168 pass irrelevant
 85353 pass irrelevant
 85509 pass irrelevant
 85614 pass irrelevant
 85667 pass irrelevant
 85725 pass irrelevant
 85776 pass irrelevant
 85870 pass irrelevant
 85988 pass irrelevant
 86111 pass irrelevant
 86047 pass irrelevant
 86187 pass irrelevant
 86279 pass irrelevant
 86368 pass irrelevant
 86449 pass irrelevant
 86542 pass irrelevant
 86626 pass irrelevant
 86811 pass irrelevant
 86715 pass irrelevant
 86882 pass irrelevant
 87133 pass irrelevant
 87236 pass irrelevant
 87315 pass irrelevant
 87418 pass irrelevant
 87558 pass irrelevant
 87701 pass irrelevant
 87832 pass irrelevant
 87977 pass irrelevant
 88131 pass irrelevant
 88284 pass irrelevant
 88416 pass irrelevant
 88539 pass irrelevant
 88655 pass irrelevant
 89304 pass irrelevant
 90908 pass irrelevant
 91263 pass irrelevant
 91416 pass irrelevant
 91591 pass irrelevant
 91700 pass irrelevant
 91779 pass irrelevant
 91862 pass irrelevant
 92005 pass irrelevant
 92125 pass irrelevant
 92228 pass irrelevant
 92342 pass irrelevant
 92440 pass irrelevant
 92532 pass irrelevant
 92668 pass irrelevant
 92798 pass 

Re: [Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

[Dario Faggioli]

On Thu, 2017-01-19 at 16:02 +, George Dunlap wrote:
> On 19/01/17 15:13, Ronald Rojas wrote:
> > It's possible to add the errors as part of the first patch and then
> > add the context functions as the second patch as Go will at least 
> > let you compile the errors on it's own. I can swap the order of the
> > patchs in the next revision.
> 
> Which points out the problem with Dario's suggestion. :-)
> 
> It is indeed normal that you don't fix things from previous patches.
> But the "fix" here is from the very first patch: you can't introduce
> the
> error code before you introduce the directories and the makefile to
> build it.  
>
Sure! But, OOC, is it imperative that the makefile is introduced in the
first patch?

I think that if it were me doing something like this, I'd defer
introducing it, if not at the very end, not before than when there is
something meaningful to make.

A matter of taste, at least up to a certain extent, I know.

> But that of course means that you're not separating out the important
> things from the first patch (the Makefile setup) with the important
> things from the second patch (the Error handling design).
> 
> I'd prefer it be left as it is; 
>
Sure. I'd at least remove the '//FIXME' from patch 1, especially
considering that the changelog already says that error handling will be
reworked.

> but it's Ian and Wei that have the final
> word on that.
> 
Indeed. :-)

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

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

Re: [Xen-devel] [PATCH 1/6] libxl: add "merge" function to generic device type support

[Wei Liu]

On Thu, Jan 19, 2017 at 05:14:35PM +0100, Olaf Hering wrote:
> On Tue, Jul 12, Juergen Gross wrote:
> 
> > Instead of using a macro generating the code to merge xenstore and
> > json configuration data, use the generic device type support for
> > this purpose.
> > This requires to add some accessor functions to the framework and
> > a structure for disks (as disks are added separately they didn't need
> > such a structure up to now).
> 
> > +++ b/tools/libxl/libxl.c
> > @@ -7371,93 +7371,68 @@ int libxl_retrieve_domain_configuration(libxl_ctx 
> > *ctx, uint32_t domid,
> 
> > +if (!dt->list || !dt->compare)
> > +continue;
> 
> 
> This makes libxl_device__compare optional ...

Actually this makes both list and compare optional.

I would say both should be mandatory -- why would you have a device type
that can't be listed or compared?

Juergen?

Wei.

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

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

[George Dunlap]

On 18/01/17 19:56, Ronald Rojas wrote:
> Create a basic Makefile to build and install libxenlight Golang
> bindings. Also add a stub package which only opens libxl context.
> 
> Include a global xenlight.Ctx variable which can be used as the
> default context by the entire program if desired.
> 
> For now, return simple errors. Proper error handling will be
> added in next patch.
> 
> Signed-off-by: Ronald Rojas 
> ---
>  tools/Makefile| 15 +++-
>  tools/golang/xenlight/Makefile| 29 ++
>  tools/golang/xenlight/xenlight.go | 80 
> +++
>  3 files changed, 123 insertions(+), 1 deletion(-)
>  create mode 100644 tools/golang/xenlight/Makefile
>  create mode 100644 tools/golang/xenlight/xenlight.go
> 
> diff --git a/tools/Makefile b/tools/Makefile
> index 77e0723..fd49e7f 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -6,12 +6,13 @@ SUBDIRS-y += include
>  SUBDIRS-y += libs
>  SUBDIRS-y += libxc
>  SUBDIRS-y += flask
> -SUBDIRS-y += fuzz
>  SUBDIRS-y += xenstore
>  SUBDIRS-y += misc
>  SUBDIRS-y += examples
>  SUBDIRS-y += hotplug
>  SUBDIRS-y += xentrace
> +#Uncomment line to build Golang libxl
> +#SUBDIRS-y += golang/xenlight
>  SUBDIRS-$(CONFIG_XCUTILS) += xcutils
>  SUBDIRS-$(CONFIG_X86) += firmware
>  SUBDIRS-y += console
> @@ -322,6 +323,18 @@ subdir-install-debugger/kdd: .phony
>  subdir-all-debugger/kdd: .phony
>   $(MAKE) -C debugger/kdd all
>  
> +subdir-clean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight clean
> +
> +subdir-distclean-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight distclean
> +
> +subdir-install-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight install
> +
> +subdir-all-golang/xenlight: .phony
> + $(MAKE) -C golang/xenlight all
> +
>  subdir-distclean-firmware: .phony
>   $(MAKE) -C firmware distclean
>  
> diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> new file mode 100644
> index 000..a45336b
> --- /dev/null
> +++ b/tools/golang/xenlight/Makefile
> @@ -0,0 +1,29 @@
> +XEN_ROOT=$(CURDIR)/../../..
> +include $(XEN_ROOT)/tools/Rules.mk
> +
> +BINARY = xenlightgo
> +GO = go
> +
> +.PHONY: all
> +all: build
> +
> +.PHONY: build
> +build: xenlight
> +
> +.PHONY: install
> +install: build
> + ! [ -f $(BINARY) ] || $(INSTALL_PROG) xenlight.go $(DESTDIR)$(bindir)

This will install xenlight.go in /usr/bin.  What happened to the
GOLANG_SRC variable I had in the sample series I sent you?

> +
> +.PHONY: clean
> +clean:
> + $(RM) $(BINARY)
> +
> +.PHONY: distclean
> +distclean: clean
> +
> +
> +xenlight: xenlight.go
> + $(GO) build -o $(BINARY) xenlight.go
> +
> +
> +-include $(DEPS)
> diff --git a/tools/golang/xenlight/xenlight.go 
> b/tools/golang/xenlight/xenlight.go
> new file mode 100644
> index 000..1f10e51
> --- /dev/null
> +++ b/tools/golang/xenlight/xenlight.go
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; version 2 of the
> + * License only.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> + * 02110-1301, USA.
> + */
> +package xenlight
> +
> +/*
> +#cgo LDFLAGS: -lxenlight -lyajl
> +#include 
> +#include 
> +*/
> +import "C"
> +
> +import (
> + "fmt"
> + "time"
> + "unsafe"
> +)
> +
> +/*
> + * Types: Builtins
> + */
> +type Context struct {
> + ctx *C.libxl_ctx
> +}
> +
> +/*
> + * Context
> + */
> +var Ctx Context
> +
> +func (Ctx *Context) IsOpen() bool {
> + return Ctx.ctx != nil
> +}
> +
> +func (Ctx *Context) Open() (err error) {
> + if Ctx.ctx != nil {
> + return
> + }
> +
> + ret := C.libxl_ctx_alloc(unsafe.Pointer(), C.LIBXL_VERSION, 0, 
> nil)
> +
> + if ret != 0 {
> + //FIXME: proper error
> + err = createError("Allocating libxl context: ", ret)

Ah, right -- I think I see what Dario was getting at.

At the moment this won't compile, because you haven't declared
createError() anywhere.  You should try to make an effort to make each
commit in the series actually compile and have no regressions.

Since you're already including fmt, I think here I'd say:

err = fmt.Errorf("Allocating libxl context: %d", ret)

This will compile and behave sensibly before it's replaced with the
error message.

Everything else looks good for now.  (The makefile will 

Re: [Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

[Wei Liu]

On Thu, Jan 19, 2017 at 04:02:46PM +, George Dunlap wrote:
> On 19/01/17 15:13, Ronald Rojas wrote:
> > On Wed, Jan 18, 2017 at 11:16:31PM +0100, Dario Faggioli wrote:
> >> On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote:
> >>> Create error type Errorxl for throwing proper xenlight
> >>> errors.
> >>>
> >>> Update Ctx functions to throw Errorxl errors.
> >>>
> >>> Signed-off-by: Ronald Rojas 
> >>> ---
> >>>  tools/golang/xenlight/xenlight.go | 77
> >>> +--
> >>>  1 file changed, 73 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/tools/golang/xenlight/xenlight.go
> >>> b/tools/golang/xenlight/xenlight.go
> >>> index 1f10e51..d58f8b8 100644
> >>> --- a/tools/golang/xenlight/xenlight.go
> >>> +++ b/tools/golang/xenlight/xenlight.go
> >>> @@ -32,6 +32,77 @@ import (
> >>>  )
> >>>  
> >>>  /*
> >>> + * Errors
> >>> + */
> >>> +type Errorxl int
> >>> +
> >>> +const (
> >>> + ErrorNonspecific  = Errorxl(-
> >>> C.ERROR_NONSPECIFIC)
> >>> + ErrorVersion  = Errorxl(-
> >>> C.ERROR_VERSION)
> >>> + ErrorFail = Errorxl(-C.ERROR_FAIL)
> >>> + ErrorNi   = Errorxl(-C.ERROR_NI)
> >>> + ErrorNomem= Errorxl(-C.ERROR_NOMEM)
> >>> + ErrorInval= Errorxl(-C.ERROR_INVAL)
> >>> + ErrorBadfail  = Errorxl(-
> >>> C.ERROR_BADFAIL)
> >>> + ErrorGuestTimedout= Errorxl(-
> >>> C.ERROR_GUEST_TIMEDOUT)
> >>> + ErrorTimedout = Errorxl(-
> >>> C.ERROR_TIMEDOUT)
> >>> + ErrorNoparavirt   = Errorxl(-
> >>> C.ERROR_NOPARAVIRT)
> >>> + ErrorNotReady = Errorxl(-
> >>> C.ERROR_NOT_READY)
> >>> + ErrorOseventRegFail   = Errorxl(-
> >>> C.ERROR_OSEVENT_REG_FAIL)
> >>> + ErrorBufferfull   = Errorxl(-
> >>> C.ERROR_BUFFERFULL)
> >>> + ErrorUnknownChild = Errorxl(-
> >>> C.ERROR_UNKNOWN_CHILD)
> >>> + ErrorLockFail = Errorxl(-
> >>> C.ERROR_LOCK_FAIL)
> >>> + ErrorJsonConfigEmpty  = Errorxl(-
> >>> C.ERROR_JSON_CONFIG_EMPTY)
> >>> + ErrorDeviceExists = Errorxl(-
> >>> C.ERROR_DEVICE_EXISTS)
> >>> + ErrorCheckpointDevopsDoesNotMatch = Errorxl(-
> >>> C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
> >>> + ErrorCheckpointDeviceNotSupported = Errorxl(-
> >>> C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
> >>> + ErrorVnumaConfigInvalid   = Errorxl(-
> >>> C.ERROR_VNUMA_CONFIG_INVALID)
> >>> + ErrorDomainNotfound   = Errorxl(-
> >>> C.ERROR_DOMAIN_NOTFOUND)
> >>> + ErrorAborted  = Errorxl(-
> >>> C.ERROR_ABORTED)
> >>> + ErrorNotfound = Errorxl(-
> >>> C.ERROR_NOTFOUND)
> >>> + ErrorDomainDestroyed  = Errorxl(-
> >>> C.ERROR_DOMAIN_DESTROYED)
> >>> + ErrorFeatureRemoved   = Errorxl(-
> >>> C.ERROR_FEATURE_REMOVED)
> >>> +)
> >>> +
> >>> +var errors = [...]string{
> >>> + ErrorNonspecific:  "Non-specific error",
> >>> + ErrorVersion:  "Wrong version",
> >>> + ErrorFail: "Failed",
> >>> + ErrorNi:   "Null",
> >>> + ErrorNomem:"No memory",
> >>> + ErrorInval:"Invalid",
> >>> + ErrorBadfail:  "Bad Fail",
> >>> + ErrorGuestTimedout:"Guest timed out",
> >>> + ErrorTimedout: "Timed out",
> >>> + ErrorNoparavirt:   "No Paravirtualization",
> >>> + ErrorNotReady: "Not ready",
> >>> + ErrorOseventRegFail:   "OS event failed",
> >>> + ErrorBufferfull:   "Buffer full",
> >>> + ErrorUnknownChild: "Unknown child",
> >>> + ErrorLockFail: "Lock failed",
> >>> + ErrorJsonConfigEmpty:  "JSON config empyt",
> >>> + ErrorDeviceExists: "Device exists",
> >>> + ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does
> >>> not match",
> >>> + ErrorCheckpointDeviceNotSupported: "Checkpoint device not
> >>> supported",
> >>> + ErrorVnumaConfigInvalid:   "VNUMA config invalid",
> >>> + ErrorDomainNotfound:   "Domain not found",
> >>> + ErrorAborted:  "Aborted",
> >>> + ErrorNotfound: "Not found",
> >>> + ErrorDomainDestroyed:  "Domain destroyed",
> >>> + ErrorFeatureRemoved:   "Feature removed",
> >>> +}
> >>> +
> >>> +func (e Errorxl) Error() string {
> >>> + if 0 <= -int(e) && -int(e) < len(errors) {
> >>> + s := errors[-e]
> >>> + if s != "" {
> >>> + return s
> >>> + }
> >>> + }
> >>> + return "errorxl " + strconv.Itoa(int(e))
> >>> +}
> >>> +
> >>> +/*
> >>>   * Types: Builtins
> >>>   */
> >>>  type Context struct {
> >>> @@ -55,8 +126,7 @@ func (Ctx *Context) Open() (err error) {
> 

Re: [Xen-devel] [PATCH 1/6] libxl: add "merge" function to generic device type support

[Olaf Hering]

On Tue, Jul 12, Juergen Gross wrote:

> Instead of using a macro generating the code to merge xenstore and
> json configuration data, use the generic device type support for
> this purpose.
> This requires to add some accessor functions to the framework and
> a structure for disks (as disks are added separately they didn't need
> such a structure up to now).

> +++ b/tools/libxl/libxl.c
> @@ -7371,93 +7371,68 @@ int libxl_retrieve_domain_configuration(libxl_ctx 
> *ctx, uint32_t domid,

> +if (!dt->list || !dt->compare)
> +continue;


This makes libxl_device__compare optional ...

> +#define DEFINE_DEVICE_TYPE_STRUCT_X(name, sname, ...)
>   \
> +const struct libxl_device_type libxl__ ## name ## _devtype = {   
>   \
> +.type  = #sname, 
>   \
> +.ptr_offset= offsetof(libxl_domain_config, name ## s),   
>   \
> +.num_offset= offsetof(libxl_domain_config, num_ ## name ## s),   
>   \
> +.dev_elem_size = sizeof(libxl_device_ ## sname), 
>   \
> +.add   = libxl__add_ ## name ## s,   
>   \
> +.list  = (void *(*)(libxl_ctx *, uint32_t, int *))   
>   \
> + libxl_device_ ## sname ## _list,
>   \
> +.dispose   = (void (*)(void *))libxl_device_ ## sname ## 
> _dispose, \
> +.compare   = (int (*)(void *, void *))   
>   \
> + libxl_device_ ## sname ## _compare, 
>   \

... and this makes libxl_device__compare mandatory.

Which one is correct?

Olaf


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 libvirt  b018ada3304c08e02b0750f8735b0702f0fd5f8c
baseline version:
 libvirt  aee1e1feac1e0c6ec410379e71e466ee16d8396e

Last test of basis   104238  2017-01-18 04:25:58 Z1 days
Testing same since   104283  2017-01-19 04:21:40 Z0 days1 attempts


People who touched revisions under test:
  Boris Fiuczynski 
  Chen Hanxiao 
  Jim Fehlig 
  John Ferlan 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-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-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-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 harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=b018ada3304c08e02b0750f8735b0702f0fd5f8c
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ 

Re: [Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

[George Dunlap]

On 19/01/17 15:13, Ronald Rojas wrote:
> On Wed, Jan 18, 2017 at 11:16:31PM +0100, Dario Faggioli wrote:
>> On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote:
>>> Create error type Errorxl for throwing proper xenlight
>>> errors.
>>>
>>> Update Ctx functions to throw Errorxl errors.
>>>
>>> Signed-off-by: Ronald Rojas 
>>> ---
>>>  tools/golang/xenlight/xenlight.go | 77
>>> +--
>>>  1 file changed, 73 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/tools/golang/xenlight/xenlight.go
>>> b/tools/golang/xenlight/xenlight.go
>>> index 1f10e51..d58f8b8 100644
>>> --- a/tools/golang/xenlight/xenlight.go
>>> +++ b/tools/golang/xenlight/xenlight.go
>>> @@ -32,6 +32,77 @@ import (
>>>  )
>>>  
>>>  /*
>>> + * Errors
>>> + */
>>> +type Errorxl int
>>> +
>>> +const (
>>> +   ErrorNonspecific  = Errorxl(-
>>> C.ERROR_NONSPECIFIC)
>>> +   ErrorVersion  = Errorxl(-
>>> C.ERROR_VERSION)
>>> +   ErrorFail = Errorxl(-C.ERROR_FAIL)
>>> +   ErrorNi   = Errorxl(-C.ERROR_NI)
>>> +   ErrorNomem= Errorxl(-C.ERROR_NOMEM)
>>> +   ErrorInval= Errorxl(-C.ERROR_INVAL)
>>> +   ErrorBadfail  = Errorxl(-
>>> C.ERROR_BADFAIL)
>>> +   ErrorGuestTimedout= Errorxl(-
>>> C.ERROR_GUEST_TIMEDOUT)
>>> +   ErrorTimedout = Errorxl(-
>>> C.ERROR_TIMEDOUT)
>>> +   ErrorNoparavirt   = Errorxl(-
>>> C.ERROR_NOPARAVIRT)
>>> +   ErrorNotReady = Errorxl(-
>>> C.ERROR_NOT_READY)
>>> +   ErrorOseventRegFail   = Errorxl(-
>>> C.ERROR_OSEVENT_REG_FAIL)
>>> +   ErrorBufferfull   = Errorxl(-
>>> C.ERROR_BUFFERFULL)
>>> +   ErrorUnknownChild = Errorxl(-
>>> C.ERROR_UNKNOWN_CHILD)
>>> +   ErrorLockFail = Errorxl(-
>>> C.ERROR_LOCK_FAIL)
>>> +   ErrorJsonConfigEmpty  = Errorxl(-
>>> C.ERROR_JSON_CONFIG_EMPTY)
>>> +   ErrorDeviceExists = Errorxl(-
>>> C.ERROR_DEVICE_EXISTS)
>>> +   ErrorCheckpointDevopsDoesNotMatch = Errorxl(-
>>> C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
>>> +   ErrorCheckpointDeviceNotSupported = Errorxl(-
>>> C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
>>> +   ErrorVnumaConfigInvalid   = Errorxl(-
>>> C.ERROR_VNUMA_CONFIG_INVALID)
>>> +   ErrorDomainNotfound   = Errorxl(-
>>> C.ERROR_DOMAIN_NOTFOUND)
>>> +   ErrorAborted  = Errorxl(-
>>> C.ERROR_ABORTED)
>>> +   ErrorNotfound = Errorxl(-
>>> C.ERROR_NOTFOUND)
>>> +   ErrorDomainDestroyed  = Errorxl(-
>>> C.ERROR_DOMAIN_DESTROYED)
>>> +   ErrorFeatureRemoved   = Errorxl(-
>>> C.ERROR_FEATURE_REMOVED)
>>> +)
>>> +
>>> +var errors = [...]string{
>>> +   ErrorNonspecific:  "Non-specific error",
>>> +   ErrorVersion:  "Wrong version",
>>> +   ErrorFail: "Failed",
>>> +   ErrorNi:   "Null",
>>> +   ErrorNomem:"No memory",
>>> +   ErrorInval:"Invalid",
>>> +   ErrorBadfail:  "Bad Fail",
>>> +   ErrorGuestTimedout:"Guest timed out",
>>> +   ErrorTimedout: "Timed out",
>>> +   ErrorNoparavirt:   "No Paravirtualization",
>>> +   ErrorNotReady: "Not ready",
>>> +   ErrorOseventRegFail:   "OS event failed",
>>> +   ErrorBufferfull:   "Buffer full",
>>> +   ErrorUnknownChild: "Unknown child",
>>> +   ErrorLockFail: "Lock failed",
>>> +   ErrorJsonConfigEmpty:  "JSON config empyt",
>>> +   ErrorDeviceExists: "Device exists",
>>> +   ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does
>>> not match",
>>> +   ErrorCheckpointDeviceNotSupported: "Checkpoint device not
>>> supported",
>>> +   ErrorVnumaConfigInvalid:   "VNUMA config invalid",
>>> +   ErrorDomainNotfound:   "Domain not found",
>>> +   ErrorAborted:  "Aborted",
>>> +   ErrorNotfound: "Not found",
>>> +   ErrorDomainDestroyed:  "Domain destroyed",
>>> +   ErrorFeatureRemoved:   "Feature removed",
>>> +}
>>> +
>>> +func (e Errorxl) Error() string {
>>> +   if 0 <= -int(e) && -int(e) < len(errors) {
>>> +   s := errors[-e]
>>> +   if s != "" {
>>> +   return s
>>> +   }
>>> +   }
>>> +   return "errorxl " + strconv.Itoa(int(e))
>>> +}
>>> +
>>> +/*
>>>   * Types: Builtins
>>>   */
>>>  type Context struct {
>>> @@ -55,8 +126,7 @@ func (Ctx *Context) Open() (err error) {
>>> ret := C.libxl_ctx_alloc(unsafe.Pointer(),
>>> C.LIBXL_VERSION, 0, nil)
>>>  
>>> if ret != 0 {
>>> -   //FIXME: proper error
>>> -   err = createError("Allocating 

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 xen  40837a38ef39b1706cec2d09d5d248494ccd2909
baseline version:
 xen  468a313def4e6b31dfb2514353d5457789714a5b

Last test of basis   104251  2017-01-18 09:54:28 Z1 days
Testing same since   104278  2017-01-19 00:43:02 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 

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 

Re: [Xen-devel] [RFC] Device memory mappings for Dom0 on ARM64 ACPI systems

[Roger Pau Monné]

On Wed, Jan 18, 2017 at 07:13:23PM +, Julien Grall wrote:
> Hi,
> 
> On 18/01/17 19:05, Stefano Stabellini wrote:
> > On Wed, 18 Jan 2017, Roger Pau Monné wrote:
> > > On Tue, Jan 17, 2017 at 02:20:54PM -0800, Stefano Stabellini wrote:
> > > > a) One option is to provide a Xen specific implementation of
> > > > acpi_os_ioremap in Linux. I think this is the cleanest approach, but
> > > > unfortunately, it doesn't cover cases where ioremap is used directly. 
> > > > (2)
> > > > is one of such cases, see
> > > > arch/arm64/kernel/pci.c:pci_acpi_setup_ecam_mapping and
> > > > drivers/pci/ecam.c:pci_ecam_create. (3) is another one of these cases,
> > > > see drivers/acpi/apei/bert.c:bert_init.
> > > 
> > > This is basically the same as b) from Xen's PoV, the only difference is 
> > > where
> > > you would call the hypercall from Dom0 to establish stage-2 mappings.
> > 
> > Right, but it is important from the Linux point of view, this is why I
> > am asking the Linux maintainers.
> > 
> > 
> > > > b) Otherwise, we could write an alternative implementation of ioremap
> > > > on arm64. The Xen specific ioremap would request a stage-2 mapping
> > > > first, then create the stage-1 mapping as usual. However, this means
> > > > issuing an hypercall for every ioremap call.
> > > 
> > > This seems fine to me, and at present is the only way to get something 
> > > working.
> > > As you said not being able to discover OperationRegions from Xen means 
> > > that
> > > there's a chance some MMIO might not be added to the stage-2 mappings.
> > > 
> > > Then what's the initial memory map state when Dom0 is booted? There are 
> > > no MMIO
> > > mappings at all, and Dom0 must request mappings for everything?
> > 
> > Yes
> 
> To give more context here, the UEFI memory map does not report all the MMIO
> regions. So there is no possibility to map MMIO at boot.

I've been able to get a Dom0 booting on x86 by mapping all the regions marked
as ACPI in the memory map, plus the BARs of PCI devices and the MCFG areas. But
this is not really optimal, since as Stefano says:

 1. If there are new tables that contain memory regions that should be mapped to
   Dom0, Xen will need to be updated in order to work on those systems.
 2. ATM it's not possible for Xen to know all the OperationRegions described in
   the ACPI DSDT/SSDT tables.

I'm not that worried about 1, since the user will also need a newish Dom0
kernel in order to access those devices, and it doesn't seem like new ACPI
tables appear out of the blue everyday. It however puts more pressure on Xen in
order to aggressively track ACPI changes.

In order to fix 2 an AML parser would need to be added to Xen.

> > 
> > 
> > > What happens to ACPI tables crafted for Dom0 that reside in RAM? That 
> > > would
> > > apply to the STAO and to the other tables that are crafted for Dom0 at 
> > > build
> > > time. Should Dom0 also request stage-2 mappings for them, and Xen simply 
> > > ignore
> > > those calls?
> > 
> > The ACPI (and UEFI) tables are mapped by Xen
> 
> I think Royger's point is DOM0 cannot tell whether a region has been mapped
> by Xen or not.
> 
> The function ioremap will be used to map anything (it is the leaf of all
> mapping functions), and will call Xen no matter the address passed. It could
> be a RAM region, HW device region, emulated device region.

Exactly, from a guest OS PoV it would request those mappings for all device
memory regions. But from Xen's perspective, those request might be made against
at least 3 different types of p2m regions:

 - Regions trapped by emulated devices inside of Xen: no direct MMIO mapping
   should be established in this case.
 - RAM regions that belong to Xen-crafted ACPI tables (STAO, MADT...).
 - Real MMIO regions that should be passed through.

Right now AFAIK Xen doesn't track any of this information, so we would need
additional non-trivial logic in order to account for all this inside the
hypervisor.

Roger.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 5ab0ffc9f64f5a539a9bdb50446b7fbf92b845d6
baseline version:
 ovmf 88fd27e5b2cae68ff5a11cd5560ef5f98d001c42

Last test of basis   104261  2017-01-18 14:44:31 Z1 days
Testing same since   104279  2017-01-19 02:01:37 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH] tools/libxl: modify static-max in xenstore when setting maxmem

[Juergen Gross]

On 19/01/17 13:51, Juergen Gross wrote:
> On 19/01/17 12:51, Wei Liu wrote:
>> On Wed, Jan 18, 2017 at 07:25:57PM +0100, Juergen Gross wrote:
>>> xl mem-max is setting the hypervisor memory limit of a domain, but not
>>> the memory/static-max value in Xenstore. This prohibits setting the
>>> memory size above the old maximum size.
>>>
>>> Set the new maximum value in Xenstore.
>>>
>>> Signed-off-by: Juergen Gross 
>>
>> This looks sensible. But memory accounting is a thorny area.
>>
>> Could you try to do local migration test for both PV and HVM guests with
>> this patch applied (with or w/out changing maxmem)?
> 
> PV: works (both with or without maxmem changed)
> HVM: works only with unchanged maxmem
> 
> HVM with changed maxmem will trigger an assertion in qemu for the
> incoming domain:
> 
> xen_ram_alloc: do not alloc 37c0 bytes of ram at 0 when runstate is
> INMIGRATE
> xen_ram_alloc: do not alloc 80 bytes of ram at 37c0 when
> runstate is INMIGRATE
> qemu-system-i386:
> /home/gross/xen/tools/qemu-xen-dir/include/exec/ram_addr.h:49:
> ramblock_ptr: Assertion `offset_in_ramblock(block, offset)' failed.
> 
> Without my patch this is working, but the migrated domain has the old
> maxmem in hypervisor data as can be seen via "xl debug-keys q".

This is all very strange:

Starting a HVM domain with maxmem=1124 and memory=1024 will place the
correct size in Xenstore, but max_pages in the hypervisor is showing
1025 MB only.

Can anybody tell me how the sizes should be set?


Juergen

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

Re: [Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

[Ronald Rojas]

On Thu, Jan 19, 2017 at 12:03:22PM +, Wei Liu wrote:
> On Wed, Jan 18, 2017 at 02:56:39PM -0500, Ronald Rojas wrote:
>   
> > diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
> > new file mode 100644
> > index 000..a45336b
> > --- /dev/null
> > +++ b/tools/golang/xenlight/Makefile
> > @@ -0,0 +1,29 @@
> > +XEN_ROOT=$(CURDIR)/../../..
> > +include $(XEN_ROOT)/tools/Rules.mk
> > +
> > +BINARY = xenlightgo
> > +GO = go
> 
> GO ?= go
> 
> to allow overriding this command.

Fixed. Thanks!
> 
> Other than this, I don't have further comments on the actual go code and
> will let George review your series.
> 
> Wei.

Thanks,
Ronald

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

Re: [Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

[Ronald Rojas]

On Wed, Jan 18, 2017 at 11:16:31PM +0100, Dario Faggioli wrote:
> On Wed, 2017-01-18 at 14:56 -0500, Ronald Rojas wrote:
> > Create error type Errorxl for throwing proper xenlight
> > errors.
> > 
> > Update Ctx functions to throw Errorxl errors.
> > 
> > Signed-off-by: Ronald Rojas 
> > ---
> >  tools/golang/xenlight/xenlight.go | 77
> > +--
> >  1 file changed, 73 insertions(+), 4 deletions(-)
> > 
> > diff --git a/tools/golang/xenlight/xenlight.go
> > b/tools/golang/xenlight/xenlight.go
> > index 1f10e51..d58f8b8 100644
> > --- a/tools/golang/xenlight/xenlight.go
> > +++ b/tools/golang/xenlight/xenlight.go
> > @@ -32,6 +32,77 @@ import (
> >  )
> >  
> >  /*
> > + * Errors
> > + */
> > +type Errorxl int
> > +
> > +const (
> > +   ErrorNonspecific  = Errorxl(-
> > C.ERROR_NONSPECIFIC)
> > +   ErrorVersion  = Errorxl(-
> > C.ERROR_VERSION)
> > +   ErrorFail = Errorxl(-C.ERROR_FAIL)
> > +   ErrorNi   = Errorxl(-C.ERROR_NI)
> > +   ErrorNomem= Errorxl(-C.ERROR_NOMEM)
> > +   ErrorInval= Errorxl(-C.ERROR_INVAL)
> > +   ErrorBadfail  = Errorxl(-
> > C.ERROR_BADFAIL)
> > +   ErrorGuestTimedout= Errorxl(-
> > C.ERROR_GUEST_TIMEDOUT)
> > +   ErrorTimedout = Errorxl(-
> > C.ERROR_TIMEDOUT)
> > +   ErrorNoparavirt   = Errorxl(-
> > C.ERROR_NOPARAVIRT)
> > +   ErrorNotReady = Errorxl(-
> > C.ERROR_NOT_READY)
> > +   ErrorOseventRegFail   = Errorxl(-
> > C.ERROR_OSEVENT_REG_FAIL)
> > +   ErrorBufferfull   = Errorxl(-
> > C.ERROR_BUFFERFULL)
> > +   ErrorUnknownChild = Errorxl(-
> > C.ERROR_UNKNOWN_CHILD)
> > +   ErrorLockFail = Errorxl(-
> > C.ERROR_LOCK_FAIL)
> > +   ErrorJsonConfigEmpty  = Errorxl(-
> > C.ERROR_JSON_CONFIG_EMPTY)
> > +   ErrorDeviceExists = Errorxl(-
> > C.ERROR_DEVICE_EXISTS)
> > +   ErrorCheckpointDevopsDoesNotMatch = Errorxl(-
> > C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
> > +   ErrorCheckpointDeviceNotSupported = Errorxl(-
> > C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
> > +   ErrorVnumaConfigInvalid   = Errorxl(-
> > C.ERROR_VNUMA_CONFIG_INVALID)
> > +   ErrorDomainNotfound   = Errorxl(-
> > C.ERROR_DOMAIN_NOTFOUND)
> > +   ErrorAborted  = Errorxl(-
> > C.ERROR_ABORTED)
> > +   ErrorNotfound = Errorxl(-
> > C.ERROR_NOTFOUND)
> > +   ErrorDomainDestroyed  = Errorxl(-
> > C.ERROR_DOMAIN_DESTROYED)
> > +   ErrorFeatureRemoved   = Errorxl(-
> > C.ERROR_FEATURE_REMOVED)
> > +)
> > +
> > +var errors = [...]string{
> > +   ErrorNonspecific:  "Non-specific error",
> > +   ErrorVersion:  "Wrong version",
> > +   ErrorFail: "Failed",
> > +   ErrorNi:   "Null",
> > +   ErrorNomem:"No memory",
> > +   ErrorInval:"Invalid",
> > +   ErrorBadfail:  "Bad Fail",
> > +   ErrorGuestTimedout:"Guest timed out",
> > +   ErrorTimedout: "Timed out",
> > +   ErrorNoparavirt:   "No Paravirtualization",
> > +   ErrorNotReady: "Not ready",
> > +   ErrorOseventRegFail:   "OS event failed",
> > +   ErrorBufferfull:   "Buffer full",
> > +   ErrorUnknownChild: "Unknown child",
> > +   ErrorLockFail: "Lock failed",
> > +   ErrorJsonConfigEmpty:  "JSON config empyt",
> > +   ErrorDeviceExists: "Device exists",
> > +   ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does
> > not match",
> > +   ErrorCheckpointDeviceNotSupported: "Checkpoint device not
> > supported",
> > +   ErrorVnumaConfigInvalid:   "VNUMA config invalid",
> > +   ErrorDomainNotfound:   "Domain not found",
> > +   ErrorAborted:  "Aborted",
> > +   ErrorNotfound: "Not found",
> > +   ErrorDomainDestroyed:  "Domain destroyed",
> > +   ErrorFeatureRemoved:   "Feature removed",
> > +}
> > +
> > +func (e Errorxl) Error() string {
> > +   if 0 <= -int(e) && -int(e) < len(errors) {
> > +   s := errors[-e]
> > +   if s != "" {
> > +   return s
> > +   }
> > +   }
> > +   return "errorxl " + strconv.Itoa(int(e))
> > +}
> > +
> > +/*
> >   * Types: Builtins
> >   */
> >  type Context struct {
> > @@ -55,8 +126,7 @@ func (Ctx *Context) Open() (err error) {
> >     ret := C.libxl_ctx_alloc(unsafe.Pointer(),
> > C.LIBXL_VERSION, 0, nil)
> >  
> >     if ret != 0 {
> > -   //FIXME: proper error
> > -   err = createError("Allocating libxl context: ", ret)
> > +   

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Pooya Keshavarzi]

Hi Stefano,

On 01/13/2017 07:39 PM, Stefano Stabellini wrote:
> On Fri, 13 Jan 2017, Pooya.Keshavarzi wrote:
>> On 01/12/2017 07:50 PM, Stefano Stabellini wrote:
>>> On Thu, 12 Jan 2017, Pooya.Keshavarzi wrote:

 Firstly sorry for the late reply on this.

 Regarding the problem with swiotlb-xen here are some more details:

 If we limit Dom0's memory such that only low-memory (up to 32-bit 
 addressable memory) is available to Dom0, then swiotlb-xen does not have 
 to use bounce buffers and the devices (e.g. USB, ethernet) would work.

 But when there is some high memory also available to Dom0, the followings 
 happen:
  - If the the device address happens to be in the device's DMA window (see 
 xen_swiotlb_map_page()), then the device would work.
  - Otherwise if it has to allocate and map a bounce buffer, then the 
 device would not work.
>>>
>>> From what you wrote it looks like the xen_swiotlb_map_page path: 
>>>
>>> if (dma_capable(dev, dev_addr, size) &&
>>> !range_straddles_page_boundary(phys, size) &&
>>> !xen_arch_need_swiotlb(dev, phys, dev_addr) &&
>>> !swiotlb_force) {
>>> /* we are not interested in the dma_addr returned by
>>>  * xen_dma_map_page, only in the potential cache flushes 
>>> executed
>>>  * by the function. */
>>> xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
>>> return dev_addr;
>>> }
>>>
>>> works, but the other does not. Does it match your understanding? Have
>>> you done any digging to find the reason why the bounce buffer code path
>>> is broken on your platform?
>>
>> Yes, The above path works but the other one doesn't.
>> I did some digging but failed to find out what's the problem. The returned 
>> address from swiotlb_tbl_map_single() is within the memory range allocated 
>> earlier for Xen software IO TLB and is dma capable, so it seem to be OK.
>>
>> What's your suggestion for further digging?
> 
> Is the device DMA coherent?
No.

> I take that it fails even without running any guests, correct?
Yes, fails only with Dom0.

> A few things come to mind:
> 
> - In xen_dma_map_page, does it take the local path or the foreign path
>   (if(local)...) when it fails?
When it fails, it takes the foreign path.

> - Check that xen_swiotlb_init initializes the swiotlb memory region
>   appriopriately and that it falls in a memory range supported by the
>   device.
The only thing is this warning:
xen:swiotlb_xen: Warning: only able to allocate 4 MB for software IO TLB

The allocation in the first memory bank can be solved by this, and then 
swiotlb-xen allocates in the proper memory range.
https://patchwork.kernel.org/patch/9347329/
We had a similar issue.


> - Check that xen_phys_to_bus(map) returns the right dev_addr. As a
>   reference, I know that on some arm32 platforms it wouldn't return the
>   right value.
It returns the same address as map.

 
> - Does the following patch fixes the issue for you?
Yes :) it seems that it solves the issue for Ethernet.
And now it takes the local path in xen_dma_map_page.

But why?

 
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 87e6035..17c65fa 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -409,9 +409,9 @@ dma_addr_t xen_swiotlb_map_page(struct device *dev, 
> struct page *page,
>   if (map == SWIOTLB_MAP_ERROR)
>   return DMA_ERROR_CODE;
>  
> + dev_addr = xen_phys_to_bus(map);
>   xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
>   dev_addr, map & ~PAGE_MASK, size, dir, 
> attrs);
> - dev_addr = xen_phys_to_bus(map);
>  
>   /*
>* Ensure that the address returned is DMA'ble 


And following patch solves the issue for USB, MMC, SDC.

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 7399782..69b5c62 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -567,6 +567,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct 
scatterlist *sgl,
sg_dma_len(sgl) = 0;
return 0;
}
+   dev_addr = xen_phys_to_bus(map);
xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
dev_addr,
map & ~PAGE_MASK,


BR,
Pooya

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

Re: [Xen-devel] [RFC PATCH v2 00/26] arm64: Dom0 ITS emulation

[Andre Przywara]

Hi,

On 19/01/17 14:32, Julien Grall wrote:
> Hi Andre,
> 
> On 19/01/2017 13:50, Andre Przywara wrote:
>> On 19/01/17 12:26, Vijay Kilari wrote:
>>>I see following issues when running on ThunderX platform with your
>>> patches.
>>> I have debugged and patched/workaround few issues. For issue (5) I
>>> need your  inputs.
>>
>> thanks for the testing and the input. It seems that my anticipation of
>> issues when booting on hardware were right ;-)
>> It seems that some of the issues got fixed already by me rewriting some
>> parts, triggered by comments from Stefano.
>>
>>> 1) Your code base fails to boot xen. Fails at dom0 memory allocation.
>>> To overcome this I have rebased your patches on top of 4.8 stable
>>> release and this issue is not seen.
>>
>> Can you try to rebase on latest xen master instead and see if that's
>> fixed there by any chance? Because that's where we eventually need to
>> base against anyway. 4.8 stable will not help.
>>
>>> 2)  ITS is not initialized if GICv2 info is not found in GICv3 dt
>>> node. But having GICv2 info is not
>>>mandatory. So in the below code if GICv2 info is not found ITS is
>>> not initialized.
>>
>> Ah, right, good point. The model is v2 compatible.
>> As this looks like an issue independent from the ITS emulation, can you
>> make a patch? Or does Xen indeed rely on having v2 compat support at the
>> moment? I think you should be able to boot Dom0 with an initrd on
>> ThunderX already, can't you?
> 
> This is a bug in your series and not the current tree. If you look at it
> the if (res) return; will avoid to read the next GICv2 region if the
> first one does not exist.

Ah, right, I misread the code snippet.

> So the problem is where you added the call to the ITS initialization.
> This should be fixed in your series and not separately.

So yes, I will fix it in my next drop.
I guess it should simply read:
if ( !res )
dt_device_get_address(node, 1 + gicv3.rdist_count + 2,
...

Thanks for pointing this out.

Cheers,
Andre.

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/6] qdict: Add convenience helpers for wrapped puts

[Eric Blake]

On 01/19/2017 03:25 AM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> Quite a few users of qdict_put() were manually wrapping a
>> non-QObject. We can make such call-sites shorter, by providing
>> common macros to do the tedious work.  Also shorten nearby
>> qdict_put_obj(,,QOBJECT()) sequences.
>>
>> Signed-off-by: Eric Blake 
>> Reviewed-by: Alberto Garcia 
>>
>> ---
>>
>> v2: rebase to current master
>>
>> I'm okay if you want me to break this patch into smaller pieces.
> 
> I guess I'm okay with a single piece, but I'd like to know how you did
> the conversion.  Coccinelle?  Manually?

Manual, via grepping for put_obj.*QOBJECT. I'll see if I can do the same
under Coccinelle (at which point, committing the script will make it
easier to rerun cleanups if later code reintroduces poor usage
patterns), so maybe I have a v3 coming up.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



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

Re: [Xen-devel] [RFC PATCH v2 00/26] arm64: Dom0 ITS emulation

[Julien Grall]

Hi Andre,

On 19/01/2017 13:50, Andre Przywara wrote:

On 19/01/17 12:26, Vijay Kilari wrote:

   I see following issues when running on ThunderX platform with your patches.
I have debugged and patched/workaround few issues. For issue (5) I
need your  inputs.


thanks for the testing and the input. It seems that my anticipation of
issues when booting on hardware were right ;-)
It seems that some of the issues got fixed already by me rewriting some
parts, triggered by comments from Stefano.


1) Your code base fails to boot xen. Fails at dom0 memory allocation.
To overcome this I have rebased your patches on top of 4.8 stable
release and this issue is not seen.


Can you try to rebase on latest xen master instead and see if that's
fixed there by any chance? Because that's where we eventually need to
base against anyway. 4.8 stable will not help.


2)  ITS is not initialized if GICv2 info is not found in GICv3 dt
node. But having GICv2 info is not
   mandatory. So in the below code if GICv2 info is not found ITS is
not initialized.


Ah, right, good point. The model is v2 compatible.
As this looks like an issue independent from the ITS emulation, can you
make a patch? Or does Xen indeed rely on having v2 compat support at the
moment? I think you should be able to boot Dom0 with an initrd on
ThunderX already, can't you?


This is a bug in your series and not the current tree. If you look at it 
the if (res) return; will avoid to read the next GICv2 region if the 
first one does not exist.


So the problem is where you added the call to the ITS initialization. 
This should be fixed in your series and not separately.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/4] multiboot2 protocol support

[Doug Goldstein]

On 1/19/17 3:31 AM, Jan Beulich wrote:
 On 18.01.17 at 18:38,  wrote:
>>
>> What's controversial about it?
> 
> The not insignificant amount of assembly code it adds, when our
> overall goal is to reduce the amount of assembly code. But
> Andrew has meanwhile indicated he's okay for this to go in as is.
> I will want to go over the whole patch once more though before
> committing it.

I completely agree with you on the assembly vs C. I want to follow this
up with some conversions to C but my original goal was to land some
basic multiboot2 support since we've had this series outstanding for
years. I was just trying to help this series move forward and believe we
can do improvements after the fact.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v4 5/5] fix: add multiboot2 protocol support for EFI platforms

[Doug Goldstein]

On 1/19/17 6:56 AM, Daniel Kiper wrote:
>> Can you tell me what were the fixes to the relocation code?
> 
> Unfortunately I have not received any details from you. Just vague
> statements that it does not work. So, I am not able to say anything
> about that. If you provide more details I am happy to help.

We discussed this on your original v11 thread. It fails on Intel NUCs,
Lenovo T430, Dell PowerEdge something (I'm on vacation so I can't see
the model number), HP Proliant ML10, QEMU (with OVMF) and some other
broads that I don't remember the model number off of my head. Its about
a dozen machines all together. They fail in two different ways:

- the other CPUs are reported as stuck and the machine boots but 'xl
info' reports 1 available CPU.
- when the non-CPUs are brought up it dies when setting paging back into
cr0.

Every single machine fails in one of these two ways.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH 1/6] x86/cpuid: Hide VT-x/SVM from HVM-based control domains

[Andrew Cooper]

On 19/01/17 03:56, Doug Goldstein wrote:
> On 1/18/17 2:40 PM, Andrew Cooper wrote:
>> The VT-x/SVM features are hidden from PV dom0 by the pv_featureset[] upper
>> mask, but nothing thusfar has prevented the features being visible in
> thus far? Could be the difference between British English and American
> English.

Just a lack of a space on my behalf.

>
>> HVM-based control domains (where there is no toolstack decision to hide the
>> features).
>>
>> As a side effect of calling nestedhvm_enabled() earlier during domain
>> creation, it needs to cope with the params[] array array not having been
> array array?

Both fixed.

~Andrew

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

[Xen-devel] [xen-4.7-testing test] 104275: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail in 104250 pass in 104275
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start.2fail pass in 104250

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

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

version targeted for testing:
 xen  24dc62731cd198d0396135392338abb3d285b18a
baseline version:
 xen  9f3c5553ebf5978992cf02664002570e15ed8ebd

Last test of basis   103850  2016-12-23 14:49:04 Z   26 days
Testing same since   104250  2017-01-18 09:54:01 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Kevin Tian 
  Luwei Kang 

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

Re: [Xen-devel] [PATCH] xenstore: remove XS_RESTRICT support

[Wei Liu]

On Thu, Jan 19, 2017 at 01:56:34PM +, Andrew Cooper wrote:
> On 19/01/17 11:01, Wei Liu wrote:
> > On Wed, Jan 18, 2017 at 07:15:44PM +0100, Juergen Gross wrote:
> > [...]
> >> diff --git a/xen/include/public/io/xs_wire.h 
> >> b/xen/include/public/io/xs_wire.h
> >> index 54c1d71..751bd17 100644
> >> --- a/xen/include/public/io/xs_wire.h
> >> +++ b/xen/include/public/io/xs_wire.h
> >> @@ -48,7 +48,7 @@ enum xsd_sockmsg_type
> >>  XS_IS_DOMAIN_INTRODUCED,
> >>  XS_RESUME,
> >>  XS_SET_TARGET,
> >> -XS_RESTRICT,
> >> +XS_PAD_1,   /* XS_RESTRICT has been removed */
> > XS_RESERVED_0/1 is better.
> >
> > Other than this, the modification looks good.
> 
> How about?
> 
> XS_SET_TARGET,
> /* XS_RESTRICT has been removed */
> XS_RESET_WATCHES = XS_SET_TARGET + 2,
> 
> This doesn't involve adding an pad/reserved identifier.
> 

Fine by me. I don't really feel strongly about this.

Wei.

> ~Andrew

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

Re: [Xen-devel] [PATCH] xenstore: remove XS_RESTRICT support

[Andrew Cooper]

On 19/01/17 11:01, Wei Liu wrote:
> On Wed, Jan 18, 2017 at 07:15:44PM +0100, Juergen Gross wrote:
> [...]
>> diff --git a/xen/include/public/io/xs_wire.h 
>> b/xen/include/public/io/xs_wire.h
>> index 54c1d71..751bd17 100644
>> --- a/xen/include/public/io/xs_wire.h
>> +++ b/xen/include/public/io/xs_wire.h
>> @@ -48,7 +48,7 @@ enum xsd_sockmsg_type
>>  XS_IS_DOMAIN_INTRODUCED,
>>  XS_RESUME,
>>  XS_SET_TARGET,
>> -XS_RESTRICT,
>> +XS_PAD_1,   /* XS_RESTRICT has been removed */
> XS_RESERVED_0/1 is better.
>
> Other than this, the modification looks good.

How about?

XS_SET_TARGET,
/* XS_RESTRICT has been removed */
XS_RESET_WATCHES = XS_SET_TARGET + 2,

This doesn't involve adding an pad/reserved identifier.

~Andrew

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