Re: [Xen-devel] [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Oleksandr Andrushchenko]

On 06/07/2018 06:47 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Jun 07, 2018 at 04:40:48PM +0300, Oleksandr Andrushchenko wrote:

On 06/07/2018 04:28 PM, Konrad Rzeszutek Wilk wrote:

On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

If frontend is configured to expose multiple input device instances
then backend may require a way to uniquely identify concrete input
device within the frontend. This is useful for use-cases where
virtual input device needs to be matched to physical input device.
Add XenBus "unique-id" node parameter, so this sort of use-cases can
be implemented.

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

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index a68da0f1a37f..45e4ff5b0a05 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -82,6 +82,15 @@
*  for pointer devices should set this to 1. Raw (unscaled) values have
*  a range of [0, 0x7fff].
*
+ *---  Device Instance Parameters 
+ *
+ * unique-id
+ *  Values: 

Wouldn't a string be easier? That way you can extend this in the future
to also have an UUID or so?

Much easier. We were thinking about that as well, but sndif already has it
as uint32_t. If you are ok to change uniquie-id for sndif to string then
that
would be much better: UUID as you mention + all protocols have unique-id
consistently defined as string.
sndif's unique-id is not used by the frontend driver and we are about
to start libx/xl support for sound, so I think this is the right time for
such a change.
If you are fine with that then I'll send yet another patch for sndif.

Please do and feel free to add

Reviewed-by: Konrad Rzeszutek Wilk 

on it.

Also pls CC Juergen so he can release-ack it.

Thank you

+ *
+ *  After device instance initialization it is assigned a unique ID
+ *  (within the front driver), so every instance of the frontend can be
+ *  identified by the backend by this ID.
+ *
*- Pointer Device Parameters 

*
* width
@@ -204,6 +213,7 @@
   #define XENKBD_FIELD_MT_WIDTH  "multi-touch-width"
   #define XENKBD_FIELD_MT_HEIGHT "multi-touch-height"
   #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
+#define XENKBD_FIELD_UNIQUE_ID "unique-id"
   /* OBSOLETE, not recommended for use */
   #define XENKBD_FIELD_RING_REF  "page-ref"
--
2.17.0




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

Re: [Xen-devel] [v3 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Manish Jaggi]

Hi Sameer,


On 06/08/2018 05:17 AM, Sameer Goel wrote:

Pull common defines for SMMU drives in a local header.

Can add more detail in commit message?


Signed-off-by: Sameer Goel 
---
  xen/drivers/passthrough/arm/smmu-v3.c |  96 +---
  xen/drivers/passthrough/arm/smmu.c| 104 +
  xen/drivers/passthrough/arm/smmu.h| 125 ++
  3 files changed, 128 insertions(+), 197 deletions(-)
  create mode 100644 xen/drivers/passthrough/arm/smmu.h

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index 75c3411ad9..fdf85c1508 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -49,28 +49,7 @@
  #include 
  #include 
  
-/* Alias to Xen device tree helpers */

-#define device_node dt_device_node
-#define of_phandle_args dt_phandle_args
-#define of_device_id dt_device_match
-#define of_match_node dt_match_node
-#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
-#define of_property_read_bool dt_property_read_bool
-#define of_parse_phandle_with_args dt_parse_phandle_with_args
-
-/* Xen: Helpers to get device MMIO and IRQs */

Added and removed in subsequent patches? code specific to xen.
you can remove from patch#4 itself.

-struct resource {
-   u64 addr;
-   u64 size;
-   unsigned int type;
-};
-
-#define resource_size(res) ((res)->size)
-
-#define platform_device device
-
-#define IORESOURCE_MEM 0
-#define IORESOURCE_IRQ 1
+#include "smmu.h"
  
  static struct resource *platform_get_resource(struct platform_device *pdev,

  unsigned int type,
@@ -200,79 +179,6 @@ static void dmam_free_coherent(struct device *dev, size_t 
size, void *vaddr,
xfree(vaddr);
  }
  
-/* Xen: Stub out DMA domain related functions */

-#define iommu_get_dma_cookie(dom) 0
-#define iommu_put_dma_cookie(dom)
-
-/* Xen: Stub out module param related function */
-#define module_param_named(a, b, c, d)
-#define MODULE_PARM_DESC(a, b)
-
-#define dma_set_mask_and_coherent(d, b) 0
-
-#define of_dma_is_coherent(n) 0
-
-#define MODULE_DEVICE_TABLE(type, name)
-
-static void __iomem *devm_ioremap_resource(struct device *dev,
-  struct resource *res)
-{
-   void __iomem *ptr;
-
-   if (!res || res->type != IORESOURCE_MEM) {
-   dev_err(dev, "Invalid resource\n");
-   return ERR_PTR(-EINVAL);
-   }
-
-   ptr = ioremap_nocache(res->addr, res->size);
-   if (!ptr) {
-   dev_err(dev,
-   "ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
-   res->addr, res->size);
-   return ERR_PTR(-ENOMEM);
-   }
-
-   return ptr;
-}
-
-/* Xen: Compatibility define for iommu_domain_geometry.*/
-struct iommu_domain_geometry {
-   dma_addr_t aperture_start; /* First address that can be mapped*/
-   dma_addr_t aperture_end;   /* Last address that can be mapped */
-   bool force_aperture;   /* DMA only allowed in mappable range? */
-};
-
-
-/* Xen: Type definitions for iommu_domain */
-#define IOMMU_DOMAIN_UNMANAGED 0
-#define IOMMU_DOMAIN_DMA 1
-#define IOMMU_DOMAIN_IDENTITY 2
-
-/* Xen: Dummy iommu_domain */
-struct iommu_domain {
-   /* Runtime SMMU configuration for this iommu_domain */
-   struct arm_smmu_domain  *priv;
-   unsigned int type;
-
-   /* Dummy compatibility defines */
-   unsigned long pgsize_bitmap;
-   struct iommu_domain_geometry geometry;
-
-   atomic_t ref;
-   /*
-* Used to link iommu_domain contexts for a same domain.
-* There is at least one per-SMMU to used by the domain.
-*/
-   struct list_headlist;
-};
-
This xen dummy structure was introduced in patch 4 and now removing in 
patch5,

Can you remove it from patch 4 itself?

-/* Xen: Describes information required for a Xen domain */
-struct arm_smmu_xen_domain {
-   spinlock_t  lock;
-   /* List of iommu domains associated to this domain */
-   struct list_headcontexts;
-};
-

Same as above

  /*
   * Xen: Information about each device stored in dev->archdata.iommu
   *
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index ad956d5b8d..f7a6b107de 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -41,6 +41,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -51,36 +52,13 @@
  #include 
  #include 
  
+#include "smmu.h" /* Not a self contained header. So last in the list */

  /* Xen: The below defines are redefined within the file. Undef it */
  #undef SCTLR_AFE
  #undef SCTLR_TRE
  #undef SCTLR_M
  #undef TTBCR_EAE
  
-/* Alias to Xen device tree helpers */

-#define device_node dt_device_node
-#define of_phandle_args 

[Xen-devel] [GIT PULL] xen: fixes and features for v4-18-rc1

[Juergen Gross]

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git 
for-linus-4.18-rc1-tag

xen: fixes and features for v4-18-rc1

It contains some minor code cleanups (fixing return types of functions),
some fixes for Linux running as Xen PVH guest, and adding of a new
guest resource mapping feature for Xen tools.


Thanks.

Juergen

 arch/arm/xen/enlighten.c  |  11 
 arch/x86/xen/mmu.c|  60 -
 arch/x86/xen/xen-pvh.S|  47 ++---
 drivers/net/xen-netfront.c|   2 +-
 drivers/xen/privcmd.c | 135 +-
 drivers/xen/xenbus/xenbus_probe.c |   5 +-
 include/uapi/xen/privcmd.h|  11 
 include/xen/interface/memory.h|  66 +++
 include/xen/interface/xen.h   |   7 +-
 include/xen/xen-ops.h |  24 ++-
 10 files changed, 332 insertions(+), 36 deletions(-)

Boris Ostrovsky (2):
  xen/PVH: Set up GS segment for stack canary
  xen/PVH: Make GDT selectors PVH-specific

Luc Van Oostenryck (1):
  xen-netfront: fix xennet_start_xmit()'s return type

Paul Durrant (1):
  xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

Roger Pau Monne (1):
  xen/store: do not store local values in xen_start_info

Souptick Joarder (1):
  xen: Change return type to vm_fault_t

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  5babc51912f91f196922b4149ce7e90ceafb5f9c
baseline version:
 libvirt  076a2b409667dd9f716a2a2085e1ffea9d58fe8b

Last test of basis   123814  2018-06-05 04:19:23 Z2 days
Failing since123840  2018-06-06 04:19:28 Z1 days2 attempts
Testing same since   123876  2018-06-07 04:19:29 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel P. Berrangé 
  Filip Alac 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Katerina Koukiou 
  Michal Privoznik 
  Peter Krempa 
  Radostin Stoyanov 
  Ramy Elkest 
  ramyelkest 
  Stefan Berger 

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



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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuuc1c2a435905ae76b159c573b0c0d6f095b45ebc6
baseline version:
 qemuu1d889f2a8baaa265939b339d2f52ec57f5b8a09c

Last test of basis   123828  2018-06-05 16:22:10 Z2 days
Testing same since   123870  2018-06-06 22:18:28 Z1 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Fam Zheng 
  Paolo Bonzini 
  Peter Maydell 
  Philippe Mathieu-Daudé 

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

[Xen-devel] [v3 0/6] SMMUv3 driver

[Sameer Goel]

This patch adds support for the SMMUv3 driver.

List of changes:
- Addition of a linux_compat header.
- Addition of a common header for arm smmu defines.
- Rebase of the SMMUv3 driver to the driver in linux kernel 4.14 rc7.
- New config defines for ARM SMMU drivers.

Changes in v3
- Changes to variables and file names.
- No functional changes.

Changes in v2 [3]
- Tasklets for evtq and priq.

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg01108.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg00713.html
[3] https://lists.xenproject.org/archives/html/xen-devel/2018-05/msg01693.html

The IORT support will come from [1]. The first revision of this patch
can be seen in [2].

Sameer Goel (6):
  Define WARN_ON_ONCE() macro to mirror Linux functionality
  passthrough/arm: Modify SMMU driver to use generic device definition
  Add verbatim copy of arm-smmu-v3.c from Linux
  xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver
  drivers/passthrough/arm: Refactor code for arm smmu drivers
  xen/smmu: Add a new config define for legacy SMMU

 xen/arch/arm/p2m.c|1 +
 xen/arch/arm/xen.lds.S|1 +
 xen/arch/x86/xen.lds.S|1 +
 xen/drivers/Kconfig   |2 +
 xen/drivers/passthrough/arm/Kconfig   |   14 +
 xen/drivers/passthrough/arm/Makefile  |3 +-
 xen/drivers/passthrough/arm/smmu-v3.c | 3667 +
 xen/drivers/passthrough/arm/smmu.c|  114 +-
 xen/drivers/passthrough/arm/smmu.h|  125 +
 xen/include/xen/lib.h |   13 +
 xen/include/xen/linux-compat.h|   84 +
 11 files changed, 3917 insertions(+), 108 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/Kconfig
 create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c
 create mode 100644 xen/drivers/passthrough/arm/smmu.h
 create mode 100644 xen/include/xen/linux-compat.h

-- 
2.17.1


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

[Xen-devel] [v3 5/6] drivers/passthrough/arm: Refactor code for arm smmu drivers

[Sameer Goel]

Pull common defines for SMMU drives in a local header.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/smmu-v3.c |  96 +---
 xen/drivers/passthrough/arm/smmu.c| 104 +
 xen/drivers/passthrough/arm/smmu.h| 125 ++
 3 files changed, 128 insertions(+), 197 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/smmu.h

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index 75c3411ad9..fdf85c1508 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -49,28 +49,7 @@
 #include 
 #include 
 
-/* Alias to Xen device tree helpers */
-#define device_node dt_device_node
-#define of_phandle_args dt_phandle_args
-#define of_device_id dt_device_match
-#define of_match_node dt_match_node
-#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
-#define of_property_read_bool dt_property_read_bool
-#define of_parse_phandle_with_args dt_parse_phandle_with_args
-
-/* Xen: Helpers to get device MMIO and IRQs */
-struct resource {
-   u64 addr;
-   u64 size;
-   unsigned int type;
-};
-
-#define resource_size(res) ((res)->size)
-
-#define platform_device device
-
-#define IORESOURCE_MEM 0
-#define IORESOURCE_IRQ 1
+#include "smmu.h"
 
 static struct resource *platform_get_resource(struct platform_device *pdev,
  unsigned int type,
@@ -200,79 +179,6 @@ static void dmam_free_coherent(struct device *dev, size_t 
size, void *vaddr,
xfree(vaddr);
 }
 
-/* Xen: Stub out DMA domain related functions */
-#define iommu_get_dma_cookie(dom) 0
-#define iommu_put_dma_cookie(dom)
-
-/* Xen: Stub out module param related function */
-#define module_param_named(a, b, c, d)
-#define MODULE_PARM_DESC(a, b)
-
-#define dma_set_mask_and_coherent(d, b) 0
-
-#define of_dma_is_coherent(n) 0
-
-#define MODULE_DEVICE_TABLE(type, name)
-
-static void __iomem *devm_ioremap_resource(struct device *dev,
-  struct resource *res)
-{
-   void __iomem *ptr;
-
-   if (!res || res->type != IORESOURCE_MEM) {
-   dev_err(dev, "Invalid resource\n");
-   return ERR_PTR(-EINVAL);
-   }
-
-   ptr = ioremap_nocache(res->addr, res->size);
-   if (!ptr) {
-   dev_err(dev,
-   "ioremap failed (addr 0x%"PRIx64" size 0x%"PRIx64")\n",
-   res->addr, res->size);
-   return ERR_PTR(-ENOMEM);
-   }
-
-   return ptr;
-}
-
-/* Xen: Compatibility define for iommu_domain_geometry.*/
-struct iommu_domain_geometry {
-   dma_addr_t aperture_start; /* First address that can be mapped*/
-   dma_addr_t aperture_end;   /* Last address that can be mapped */
-   bool force_aperture;   /* DMA only allowed in mappable range? */
-};
-
-
-/* Xen: Type definitions for iommu_domain */
-#define IOMMU_DOMAIN_UNMANAGED 0
-#define IOMMU_DOMAIN_DMA 1
-#define IOMMU_DOMAIN_IDENTITY 2
-
-/* Xen: Dummy iommu_domain */
-struct iommu_domain {
-   /* Runtime SMMU configuration for this iommu_domain */
-   struct arm_smmu_domain  *priv;
-   unsigned int type;
-
-   /* Dummy compatibility defines */
-   unsigned long pgsize_bitmap;
-   struct iommu_domain_geometry geometry;
-
-   atomic_t ref;
-   /*
-* Used to link iommu_domain contexts for a same domain.
-* There is at least one per-SMMU to used by the domain.
-*/
-   struct list_headlist;
-};
-
-/* Xen: Describes information required for a Xen domain */
-struct arm_smmu_xen_domain {
-   spinlock_t  lock;
-   /* List of iommu domains associated to this domain */
-   struct list_headcontexts;
-};
-
 /*
  * Xen: Information about each device stored in dev->archdata.iommu
  *
diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index ad956d5b8d..f7a6b107de 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,36 +52,13 @@
 #include 
 #include 
 
+#include "smmu.h" /* Not a self contained header. So last in the list */
 /* Xen: The below defines are redefined within the file. Undef it */
 #undef SCTLR_AFE
 #undef SCTLR_TRE
 #undef SCTLR_M
 #undef TTBCR_EAE
 
-/* Alias to Xen device tree helpers */
-#define device_node dt_device_node
-#define of_phandle_args dt_phandle_args
-#define of_device_id dt_device_match
-#define of_match_node dt_match_node
-#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
-#define of_property_read_bool dt_property_read_bool
-#define of_parse_phandle_with_args dt_parse_phandle_with_args
-
-/* Xen: Helpers to get device MMIO and IRQs */
-struct resource
-{
-   u64 

[Xen-devel] [v3 6/6] xen/smmu: Add a new config define for legacy SMMU

[Sameer Goel]

Add a new config item to control compilation for legacy arm SMMU.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/Kconfig  | 6 ++
 xen/drivers/passthrough/arm/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
index cda899f608..e888a78312 100644
--- a/xen/drivers/passthrough/arm/Kconfig
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -6,3 +6,9 @@ config ARM_SMMU_v3
 Support for implementations of the ARM System MMU architecture
 version 3.
 
+config ARM_SMMU
+   bool "ARM Legacy SMMU Support"
+   depends on ARM
+   help
+Support for implementations of the ARM System MMU architecture
+version 1 and 2.
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index e14732b55c..5b3eb1545e 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,3 +1,3 @@
 obj-y += iommu.o
-obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU) += smmu.o
 obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
-- 
2.17.1


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

[Xen-devel] [v3 4/6] xen/iommu: smmu-v3: Add Xen specific code to enable the ported driver

[Sameer Goel]

This driver follows an approach similar to smmu driver. The intent here
is to reuse as much Linux code as possible.
- Glue code has been introduced to bridge the API calls.
- Called Linux functions from the Xen IOMMU function calls.
- Xen modifications are preceded by /*Xen: comment */
- xen/linux_compat: Add a Linux compat header
  For porting files directly from Linux it is useful to have a function mapping
  definitions from Linux to Xen. This file adds common API functions and
  other defines that are needed for porting arm SMMU drivers.

Signed-off-by: Sameer Goel 
---
 xen/arch/arm/p2m.c|   1 +
 xen/drivers/Kconfig   |   2 +
 xen/drivers/passthrough/arm/Kconfig   |   8 +
 xen/drivers/passthrough/arm/Makefile  |   1 +
 xen/drivers/passthrough/arm/smmu-v3.c | 934 +-
 xen/include/xen/linux-compat.h|  84 +++
 6 files changed, 1001 insertions(+), 29 deletions(-)
 create mode 100644 xen/drivers/passthrough/arm/Kconfig
 create mode 100644 xen/include/xen/linux-compat.h

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index d43c3aa896..38aa9f00c1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1454,6 +1454,7 @@ err:
 static void __init setup_virt_paging_one(void *data)
 {
 unsigned long val = (unsigned long)data;
+/* SMMUv3 S2 cfg vtcr reuses the following value */
 WRITE_SYSREG32(val, VTCR_EL2);
 isb();
 }
diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
index db94393f47..59ca00f850 100644
--- a/xen/drivers/Kconfig
+++ b/xen/drivers/Kconfig
@@ -15,4 +15,6 @@ source "drivers/video/Kconfig"
 config HAS_VPCI
bool
 
+source "drivers/passthrough/arm/Kconfig"
+
 endmenu
diff --git a/xen/drivers/passthrough/arm/Kconfig 
b/xen/drivers/passthrough/arm/Kconfig
new file mode 100644
index 00..cda899f608
--- /dev/null
+++ b/xen/drivers/passthrough/arm/Kconfig
@@ -0,0 +1,8 @@
+
+config ARM_SMMU_v3
+   bool "ARM SMMUv3 Support"
+   depends on ARM_64
+   help
+Support for implementations of the ARM System MMU architecture
+version 3.
+
diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index f4cd26e15d..e14732b55c 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,3 @@
 obj-y += iommu.o
 obj-y += smmu.o
+obj-$(CONFIG_ARM_SMMU_v3) += smmu-v3.o
diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
index e67ba6c40f..75c3411ad9 100644
--- a/xen/drivers/passthrough/arm/smmu-v3.c
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -18,28 +18,414 @@
  * Author: Will Deacon 
  *
  * This driver is powered by bad coffee and bombay mix.
+ *
+ *
+ * Based on Linux drivers/iommu/arm-smmu-v3.c
+ * => commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
+ *
+ * Xen modifications:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-
-#include "io-pgtable.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Alias to Xen device tree helpers */
+#define device_node dt_device_node
+#define of_phandle_args dt_phandle_args
+#define of_device_id dt_device_match
+#define of_match_node dt_match_node
+#define of_property_read_u32(np, pname, out) (!dt_property_read_u32(np, pname, 
out))
+#define of_property_read_bool dt_property_read_bool
+#define of_parse_phandle_with_args dt_parse_phandle_with_args
+
+/* Xen: Helpers to get device MMIO and IRQs */
+struct resource {
+   u64 addr;
+   u64 size;
+   unsigned int type;
+};
+
+#define resource_size(res) ((res)->size)
+
+#define platform_device device
+
+#define IORESOURCE_MEM 0
+#define IORESOURCE_IRQ 1
+
+static struct resource *platform_get_resource(struct platform_device *pdev,
+ unsigned int type,
+ unsigned int num)
+{
+   /*
+* The resource is only used between 2 calls of platform_get_resource.
+* It's quite ugly but it's avoid to add too much code in the part
+* imported from Linux
+*/
+   static struct resource res;
+   struct acpi_iort_node *iort_node;
+   struct acpi_iort_smmu_v3 *node_smmu_data;
+   int ret = 0;
+
+   res.type = type;
+
+   switch (type) {
+   case IORESOURCE_MEM:
+   if (pdev->type == DEV_ACPI) {
+   ret = 1;
+   iort_node = pdev->acpi_node;
+   node_smmu_data =
+   (struct acpi_iort_smmu_v3 
*)iort_node->node_data;
+
+   if 

[Xen-devel] [v3 3/6] Add verbatim copy of arm-smmu-v3.c from Linux

[Sameer Goel]

Based on commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
This is a verbatim snapshot of arm-smmu-v3.c from Linux kernel source
code.
No Xen code has been added and the file is not built.

Signed-off-by: Sameer Goel 
---
 xen/drivers/passthrough/arm/smmu-v3.c | 2885 +
 1 file changed, 2885 insertions(+)
 create mode 100644 xen/drivers/passthrough/arm/smmu-v3.c

diff --git a/xen/drivers/passthrough/arm/smmu-v3.c 
b/xen/drivers/passthrough/arm/smmu-v3.c
new file mode 100644
index 00..e67ba6c40f
--- /dev/null
+++ b/xen/drivers/passthrough/arm/smmu-v3.c
@@ -0,0 +1,2885 @@
+/*
+ * IOMMU API for ARM architected SMMUv3 implementations.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *
+ * Copyright (C) 2015 ARM Limited
+ *
+ * Author: Will Deacon 
+ *
+ * This driver is powered by bad coffee and bombay mix.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "io-pgtable.h"
+
+/* MMIO registers */
+#define ARM_SMMU_IDR0  0x0
+#define IDR0_ST_LVL_SHIFT  27
+#define IDR0_ST_LVL_MASK   0x3
+#define IDR0_ST_LVL_2LVL   (1 << IDR0_ST_LVL_SHIFT)
+#define IDR0_STALL_MODEL_SHIFT 24
+#define IDR0_STALL_MODEL_MASK  0x3
+#define IDR0_STALL_MODEL_STALL (0 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_STALL_MODEL_FORCE (2 << IDR0_STALL_MODEL_SHIFT)
+#define IDR0_TTENDIAN_SHIFT21
+#define IDR0_TTENDIAN_MASK 0x3
+#define IDR0_TTENDIAN_LE   (2 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_TTENDIAN_BE   (3 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_TTENDIAN_MIXED(0 << IDR0_TTENDIAN_SHIFT)
+#define IDR0_CD2L  (1 << 19)
+#define IDR0_VMID16(1 << 18)
+#define IDR0_PRI   (1 << 16)
+#define IDR0_SEV   (1 << 14)
+#define IDR0_MSI   (1 << 13)
+#define IDR0_ASID16(1 << 12)
+#define IDR0_ATS   (1 << 10)
+#define IDR0_HYP   (1 << 9)
+#define IDR0_COHACC(1 << 4)
+#define IDR0_TTF_SHIFT 2
+#define IDR0_TTF_MASK  0x3
+#define IDR0_TTF_AARCH64   (2 << IDR0_TTF_SHIFT)
+#define IDR0_TTF_AARCH32_64(3 << IDR0_TTF_SHIFT)
+#define IDR0_S1P   (1 << 1)
+#define IDR0_S2P   (1 << 0)
+
+#define ARM_SMMU_IDR1  0x4
+#define IDR1_TABLES_PRESET (1 << 30)
+#define IDR1_QUEUES_PRESET (1 << 29)
+#define IDR1_REL   (1 << 28)
+#define IDR1_CMDQ_SHIFT21
+#define IDR1_CMDQ_MASK 0x1f
+#define IDR1_EVTQ_SHIFT16
+#define IDR1_EVTQ_MASK 0x1f
+#define IDR1_PRIQ_SHIFT11
+#define IDR1_PRIQ_MASK 0x1f
+#define IDR1_SSID_SHIFT6
+#define IDR1_SSID_MASK 0x1f
+#define IDR1_SID_SHIFT 0
+#define IDR1_SID_MASK  0x3f
+
+#define ARM_SMMU_IDR5  0x14
+#define IDR5_STALL_MAX_SHIFT   16
+#define IDR5_STALL_MAX_MASK0x
+#define IDR5_GRAN64K   (1 << 6)
+#define IDR5_GRAN16K   (1 << 5)
+#define IDR5_GRAN4K(1 << 4)
+#define IDR5_OAS_SHIFT 0
+#define IDR5_OAS_MASK  0x7
+#define IDR5_OAS_32_BIT(0 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_36_BIT(1 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_40_BIT(2 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_42_BIT(3 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_44_BIT(4 << IDR5_OAS_SHIFT)
+#define IDR5_OAS_48_BIT(5 << IDR5_OAS_SHIFT)
+
+#define ARM_SMMU_CR0   0x20
+#define CR0_CMDQEN (1 << 3)
+#define CR0_EVTQEN (1 << 2)
+#define CR0_PRIQEN (1 << 1)
+#define CR0_SMMUEN (1 << 0)
+
+#define ARM_SMMU_CR0ACK0x24
+
+#define ARM_SMMU_CR1   0x28
+#define CR1_SH_NSH 0
+#define CR1_SH_OSH 2

[Xen-devel] [v3 1/6] Define WARN_ON_ONCE() macro to mirror Linux functionality

[Sameer Goel]

Define WARN_ON_ONCE() macro to mirror Linux functionality.

Signed-off-by: Sameer Goel 
Acked-by: Julien Grall 
---
 xen/arch/arm/xen.lds.S |  1 +
 xen/arch/x86/xen.lds.S |  1 +
 xen/include/xen/lib.h  | 13 +
 3 files changed, 15 insertions(+)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 245a0e0e85..1ef714110a 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -94,6 +94,7 @@ SECTIONS
__end_schedulers_array = .;
*(.data.rel)
*(.data.rel.*)
+   *(.data.cold)
CONSTRUCTORS
   } :text
 
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 70afedd31d..51d9da2482 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -270,6 +270,7 @@ SECTIONS
*(.data)
*(.data.rel)
*(.data.rel.*)
+   *(.data.cold)
CONSTRUCTORS
   } :text
 
diff --git a/xen/include/xen/lib.h b/xen/include/xen/lib.h
index 1d9771340c..2bdaf6d60d 100644
--- a/xen/include/xen/lib.h
+++ b/xen/include/xen/lib.h
@@ -11,6 +11,19 @@
 #define BUG_ON(p)  do { if (unlikely(p)) BUG();  } while (0)
 #define WARN_ON(p) do { if (unlikely(p)) WARN(); } while (0)
 
+#define WARN_ON_ONCE(p)   \
+({\
+static bool __section(".data.cold") warned;   \
+bool ret_warn_once = !!(p);   \
+  \
+if ( unlikely(ret_warn_once && !warned) ) \
+{ \
+warned = true;\
+WARN();   \
+} \
+unlikely(ret_warn_once);  \
+})
+
 #if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
 /* Force a compilation error if condition is true */
 #define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
-- 
2.17.1


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

[Xen-devel] [v3 2/6] passthrough/arm: Modify SMMU driver to use generic device definition

[Sameer Goel]

Modify the SMMU code to use generic device instead of dt_device_node for
functions that can be used for ACPI based systems too.

Signed-off-by: Sameer Goel 
Acked-by: Julien Grall 
---
 xen/drivers/passthrough/arm/smmu.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 45acb89380..ad956d5b8d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -76,7 +76,7 @@ struct resource
 
 #define resource_size(res) (res)->size;
 
-#define platform_device dt_device_node
+#define platform_device device
 
 #define IORESOURCE_MEM 0
 #define IORESOURCE_IRQ 1
@@ -97,12 +97,12 @@ static struct resource *platform_get_resource(struct 
platform_device *pdev,
 
switch (type) {
case IORESOURCE_MEM:
-   ret = dt_device_get_address(pdev, num, , );
+   ret = dt_device_get_address(dev_to_dt(pdev), num, , 
);
 
return ((ret) ? NULL : );
 
case IORESOURCE_IRQ:
-   ret = platform_get_irq(pdev, num);
+   ret = platform_get_irq(dev_to_dt(pdev), num);
if (ret < 0)
return NULL;
 
@@ -2286,7 +2286,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
const struct of_device_id *of_id;
struct resource *res;
struct arm_smmu_device *smmu;
-   struct device *dev = >dev;
+   struct device *dev = pdev;
struct rb_node *node;
struct of_phandle_args masterspec;
int num_irqs, i, err;
@@ -2339,7 +2339,7 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev)
}
 
for (i = 0; i < num_irqs; ++i) {
-   int irq = platform_get_irq(pdev, i);
+   int irq = platform_get_irq(dev_to_dt(pdev), i);
 
if (irq < 0) {
dev_err(dev, "failed to get irq index %d\n", i);
@@ -2820,7 +2820,7 @@ static __init int arm_smmu_dt_init(struct dt_device_node 
*dev,
 */
dt_device_set_used_by(dev, DOMID_XEN);
 
-   rc = arm_smmu_device_dt_probe(dev);
+   rc = arm_smmu_device_dt_probe(dt_to_dev(dev));
if (rc)
return rc;
 
-- 
2.17.1


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

Re: [Xen-devel] [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

[Boris Ostrovsky]

On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
>>> On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
 On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>>
 +
 +static struct sg_table *
 +dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach,
 +   enum dma_data_direction dir)
 +{
 +    struct gntdev_dmabuf_attachment *gntdev_dmabuf_attach =
 attach->priv;
 +    struct gntdev_dmabuf *gntdev_dmabuf = attach->dmabuf->priv;
 +    struct sg_table *sgt;
 +
 +    pr_debug("Mapping %d pages for dev %p\n",
 gntdev_dmabuf->nr_pages,
 + attach->dev);
 +
 +    if (WARN_ON(dir == DMA_NONE || !gntdev_dmabuf_attach))

 WARN_ON_ONCE. Here and elsewhere.
>>> Why? The UAPI may be used by different applications, thus we might
>>> lose warnings for some of them. Having WARN_ON will show problems
>>> for multiple users, not for the first one.
>>> Does this make sense to still use WARN_ON?
>>
>> Just as with pr_err call somewhere else the concern here is that
>> userland (which I think is where this is eventually called from?) may
>> intentionally trigger the error, flooding the log.
>>
>> And even this is not directly called from userland there is still a
>> possibility of triggering this error multiple times.
> Ok, will use WARN_ON_ONCE


In fact, is there a reason to use WARN at all? Does this condition
indicate some sort of internal inconsistency/error?

-boris




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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxb0b357c20ca6171b8ac698351f5202402b7ad7d5
baseline version:
 linuxb87af3ab9dae0dc53b201701725ed6e2af4f2f74

Last test of basis74756  2018-05-28 20:55:21 Z   10 days
Testing same since74795  2018-06-07 07:21:38 Z0 days1 attempts


People who touched revisions under test:
  "Huang, Ying" 
  Aaro Koskinen 
  Aaron Brown 
  Al Viro 
  Alan Stern 
  Alex Estrin 
  Alex Williamson 
  Alexander Potapenko 
  Alexandre Belloni 
  Alexey Dobriyan 
  Anders Roxell 
  Andrea Parri 
  Andrew Morton 
  Andrzej Hajda 
  Anna-Maria Gleixner 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Arvind Yadav 
  Asutosh Das 
  Balbir Singh 
  Bart Van Assche 
  Bartlomiej Zolnierkiewicz 
  Benjamin Poirier 
  Bin Liu 
  Binarus 
  Bjorn Helgaas 
  Bjorn Helgaas 
  Boris Ostrovsky 
  Brad Love 
  Carlos Maiolino 
  Chad Dupuis 
  Chanwoo Choi 
  Chen Yu 
  Chris Dickens 
  Christoph Hellwig 
  Christophe JAILLET 
  Claudio Imbrenda 
  Colin Ian King 
  Coly Li 
  Cong Wang 
  Dan Carpenter 
  Daniel Díaz 
 

[Xen-devel] [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

[Boris Ostrovsky]

On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:32 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
>>> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index 9813fc440c70..7d58dfb3e5e8 100644
> --- a/drivers/xen/gntdev.c
> +++ b/drivers/xen/gntdev.c
 ...

>    +#ifdef CONFIG_XEN_GNTDEV_DMABUF
 This code belongs in gntdev-dmabuf.c.
>>> The reason I have this code here is that it is heavily
>>> tied to gntdev's internal functionality, e.g. map/unmap.
>>> I do not want to extend gntdev's API, so gntdev-dmabuf can
>>> access these. What is more dma-buf doesn't need to know about
>>> maps done by gntdev as there is no use of that information
>>> in gntdev-dmabuf. So, it seems more naturally to have
>>> dma-buf's related map/unmap code where it is: in gntdev.
>> Sorry, I don't follow. Why would this require extending the API? It's
>> just moving routines to a different file that is linked to the same
>> module.
> I do understand your intention here and tried to avoid dma-buf
> related code in gntdev.c as much as possible. So, let me explain
> my decision in more detail.
>
> There are 2 use-cases we have: dma-buf import and export.
>
> While importing a dma-buf all the dma-buf related functionality can
> easily be kept inside gntdev-dmabuf.c w/o any issue as all we need
> from gntdev.c is dev, dma_buf_fd, count and domid for that.
>
> But in case of dma-buf export we need to:
> 1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags);
> 2. gntdev_add_map(priv, map);
> 3. Set map->flags
> 4. ret = map_grant_pages(map);
> 5. And only now we are all set to export the new dma-buf from
> *map->pages*
>
> So, until 5) we use private gtndev.c's API not exported to outside world:
> a. struct grant_map
> b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv,
> int count,
>                       int dma_flags)
> c. static void gntdev_add_map(struct gntdev_priv *priv, struct
> grant_map *add)
> d. static int map_grant_pages(struct grant_map *map)
>
> Thus, all the above cannot be accessed from gntdev-dmabuf.c
> This is why I say that gntdev.c's API will need to be extended to
> provide the above
> a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c.



I still don't understand why you feel this would be extending the API.
These routines and the struct can be declared in local header file and
this header file will not be visible to anyone but gntdev.c and
gntdev-dmabuf.c. You can, for example, put this into gntdev-dmabuf.h
(and then rename it to something else, like gntdev-common.h).



> But that doesn't seem good to me and what is more a-d are really
> gntdev.c's
> functionality, not dma-buf's which only needs pages and doesn't really
> care from
> where those come.
> That was the reason I partitioned export into 2 chunks: gntdev +
> gntdev-dmabuf.
>
> You might also ask why importing side does Xen related things
> (granting references+)
> in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf
> exporter?
> This is because importer uses grant-table's API which seems to be not
> natural for gntdev.c,
> so it can leave in gntdev-dmabuf.c which has a use-case for that,
> while gntdev
> remains the same.


Yet another reason why this code should be moved: importing and
exporting functionalities logically belong together. The fat that they
are implemented using different methods is not relevant IMO.

If you have code which is under ifdef CONFIG_GNTDEV_DMABUF and you have
file called gntdev-dmabuf.c it sort of implies that this code should
live in that file (unless that code is intertwined with other code,
which is not the case here).


-boris



>> Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in
>> gntdev-dmabuf.c? In my view that's the file where all dma-related
>> "stuff" lives.
> Agree, but IMO grant_map stuff for dma-buf importer is right in its
> place in gntdev.c
> and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they
> should
>>
>> -boris
>>
>>
>> -boris
>>
> Thank you,
> Oleksandr


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

[Xen-devel] [linux-4.14 test] 123864: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl  broken

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl   4 host-install(4)  broken pass in 123820
 test-amd64-i386-qemut-rhel6hvm-amd 15 leak-check/check fail in 123820 pass in 
123864

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

version targeted for testing:
 linux2c6025ebc7fd8e0a8ca785d778dc6ae25225744b
baseline version:
 linux57a3ca7835962109d94533465a75e8c716b26845

Last test of basis   123447  2018-05-31 08:17:59 Z7 days
Testing same since   123820  2018-06-05 10:10:00 Z2 days2 attempts

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

[Boris Ostrovsky]

(Stefano, question for you at the end)

On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
>>> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
 On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
 @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map
 *map)
    if (map == NULL)
    return;
    +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> *Option 1: kfree(map->frames);*
 +    if (map->dma_vaddr) {
 +    struct gnttab_dma_alloc_args args;
 +
 +    args.dev = map->dma_dev;
 +    args.coherent = map->dma_flags & GNTDEV_DMA_FLAG_COHERENT;
 +    args.nr_pages = map->count;
 +    args.pages = map->pages;
 +    args.frames = map->frames;
 +    args.vaddr = map->dma_vaddr;
 +    args.dev_bus_addr = map->dma_bus_addr;
 +
 +    gnttab_dma_free_pages();
> *Option 2: kfree(map->frames);*
 +    } else
 +#endif
    if (map->pages)
    gnttab_free_pages(map->count, map->pages);
 +
 +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
 +    kfree(map->frames);
 +#endif

 Can this be done under if (map->dma_vaddr) ?
    In other words, is it
 possible for dma_vaddr to be NULL and still have unallocated frames
 pointer?
>>> It is possible to have vaddr == NULL and frames != NULL as we
>>> allocate frames outside of gnttab_dma_alloc_pages which
>>> may fail. Calling kfree on NULL pointer is safe,
>>
>> I am not questioning safety of the code, I would like avoid another
>> ifdef.
> Ah, I now understand, so you are asking if we can have
> that kfree(map->frames); in the place *Option 2* I marked above.
> Unfortunately no: map->frames is allocated before we try to
> allocate DMA memory, e.g. before dma_vaddr is set:
> [...]
>         add->frames = kcalloc(count, sizeof(add->frames[0]),
>                   GFP_KERNEL);
>         if (!add->frames)
>             goto err;
>
> [...]
>         if (gnttab_dma_alloc_pages())
>             goto err;
>
>         add->dma_vaddr = args.vaddr;
> [...]
> err:
>     gntdev_free_map(add);
>
> So, it is possible to enter gntdev_free_map with
> frames != NULL and dma_vaddr == NULL. Option 1 above cannot be used
> as map->frames is needed for gnttab_dma_free_pages();
> and Option 2 cannot be used as frames != NULL and dma_vaddr == NULL.
> Thus, I think that unfortunately we need that #ifdef.
> Option 3 below can also be considered, but that seems to be not good
> as we free resources in different places which looks inconsistent.


I was only thinking of option 2. But if it is possible to have frames !=
NULL and dma_vaddr == NULL then perhaps we indeed will have to live with
the extra ifdef.


>
> Sorry if I'm still missing your point.
>>
>>> so
>>> I see no reason to change this code.
>    kfree(map->pages);
>    kfree(map->grants);
>    kfree(map->map_ops);
> @@ -132,7 +176,8 @@ static void gntdev_free_map(struct grant_map
> *map)
>    kfree(map);
>    }
>    -static struct grant_map *gntdev_alloc_map(struct gntdev_priv
> *priv, int count)
> +static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv,
> int count,
> +  int dma_flags)
>    {
>    struct grant_map *add;
>    int i;
> @@ -155,6 +200,37 @@ static struct grant_map
> *gntdev_alloc_map(struct gntdev_priv *priv, int count)
>    NULL == add->pages)
>    goto err;
>    +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC
> +    add->dma_flags = dma_flags;
> +
> +    /*
> + * Check if this mapping is requested to be backed
> + * by a DMA buffer.
> + */
> +    if (dma_flags & (GNTDEV_DMA_FLAG_WC |
> GNTDEV_DMA_FLAG_COHERENT)) {
> +    struct gnttab_dma_alloc_args args;
> +
> +    add->frames = kcalloc(count, sizeof(add->frames[0]),
> +  GFP_KERNEL);
> +    if (!add->frames)
> +    goto err;
> +
> +    /* Remember the device, so we can free DMA memory. */
> +    add->dma_dev = priv->dma_dev;
> +
> +    args.dev = priv->dma_dev;
> +    args.coherent = dma_flags & GNTDEV_DMA_FLAG_COHERENT;
> +    args.nr_pages = count;
> +    args.pages = add->pages;
> +    args.frames = add->frames;
> +
> +    if (gnttab_dma_alloc_pages())
> *Option 3: kfree(map->frames);*
> +    goto err;
> +
> +    add->dma_vaddr = args.vaddr;
> +    add->dma_bus_addr = args.dev_bus_addr;
> +    } else
> +#endif
>    if (gnttab_alloc_pages(count, add->pages))
>    goto err;
>    @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map
> *map)
>    map->unmap_ops[i].handle = map->map_ops[i].handle;

Re: [Xen-devel] [PATCH] CODING_STYLE: discourage use of underscores where alternatives exist

[Julien Grall]

Hi Jan,

On 07/06/2018 14:56, Jan Beulich wrote:

Underscores commonly require two keypresses while hyphen / dash requires
just one, and the visual separation effect of both is basically the same.


I don't buy this argument. A good programmer is lazy by definition but 
not that much. C does not allow identifiers with hyphen, so you end up 
to use underscore most of time as you don't often create new filename 
and most of the editors have filename auto-completion.


To be honest, my mind has also been trained to recognize easily the 
underscore version and I feel the hyphen more difficult to parse.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Olaf Hering]

On Thu, Jun 07, Jan Beulich wrote:

> >>> On 07.06.18 at 16:49,  wrote:
> > Am Thu, 07 Jun 2018 08:44:41 -0600
> > schrieb "Jan Beulich" :
> >> The re-use of the field is acceptable only if all existing senders reliably
> >> fill zero in there.
> > How do we know all senders? I just know about write_tsc_info from xen-4.6+.
> I don't think we care about senders other than ones using libxc, so
> by knowing whether all libxc versions conform to the requirement,
> we could declare we're fine.

Yes, I think we are fine. And if migration from pre-4.6 is supported
anyway is another question. Most likely the answer is no.

Olaf


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

Re: [Xen-devel] PROBLEM: xen-netfront: ethtool settings changed in 4.4.134 causing packet loss

[Liam Shepherd]

Thank you.

As a side point David Vrabel is listed in the maintainers file for xen
hypervisor interface in 4.4.135 but his email is no longer active it seems.

On 7 Jun 2018 09:35, "Ross Lagerwall"  wrote:

On 06/05/2018 04:43 PM, Liam Shepherd wrote:
> When upgrading from 4.4.132 to 4.4.135 I started observing about 3%
> packet loss on PV on HVM domU interfaces. Specifically TX dropped
> packets (As reported by ifconfig).
>
> It seems that the default ethtool settings have changed.
>
> Previously (4.4.132):
> tx-checksumming: on
>  tx-checksum-ipv4: on [fixed]
>  tx-checksum-ip-generic: off [fixed]
>  tx-checksum-ipv6: on
>  tx-checksum-fcoe-crc: off [fixed]
>  tx-checksum-sctp: off [fixed]
> scatter-gather: on
>  tx-scatter-gather: on
>  tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: on
>  tx-tcp-segmentation: on
>  tx-tcp-ecn-segmentation: off [fixed]
>  tx-tcp6-segmentation: on
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: on
>
> Now (4.4.135):
> tx-checksumming: on
>  tx-checksum-ipv4: on [fixed]
>  tx-checksum-ip-generic: off [fixed]
>  tx-checksum-ipv6: off
>  tx-checksum-fcoe-crc: off [fixed]
>  tx-checksum-sctp: off [fixed]
> scatter-gather: off
>  tx-scatter-gather: off
>  tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: off
>  tx-tcp-segmentation: off
>  tx-tcp-ecn-segmentation: off [fixed]
>  tx-tcp6-segmentation: off
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: off [requested on]
>
> Manually running 'ethtool -K INT tso on sg on' on all interfaces stops
> the packet loss again. They're then set like this:
> tx-checksumming: on
>  tx-checksum-ipv4: on [fixed]
>  tx-checksum-ip-generic: off [fixed]
>  tx-checksum-ipv6: off
>  tx-checksum-fcoe-crc: off [fixed]
>  tx-checksum-sctp: off [fixed]
> scatter-gather: on
>  tx-scatter-gather: on
>  tx-scatter-gather-fraglist: off [fixed]
> tcp-segmentation-offload: on
>  tx-tcp-segmentation: on
>  tx-tcp-ecn-segmentation: off [fixed]
>  tx-tcp6-segmentation: off [requested on]
> udp-fragmentation-offload: off [fixed]
> generic-segmentation-offload: on
>
> I've traced it to a commit in 4.4.134:
> 6be4fe832954db3b359b72107a6c60e34d939b26
> xen-netfront: Fix race between device setup and open
> [ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
> https://patchwork.kernel.org/patch/10328969/
>
> Once that is reverted on 4.4.135, the ethtool settings are as 4.4.132
> and there is no packet loss.
>
Thanks for the bug report. Changing the ethtool settings was certainly
not intended with that change. I'll take a look to see what has gone wrong.


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-ws16-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-win7-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-pvhv2-intel  7 xen-boot  fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
122969
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 122969
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-win10-i386  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-win10-i386  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-win7-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemuu-ws16-amd64  7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 122969
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 122969
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 122969

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 122997
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 122997
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 122997
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 122997
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 122997
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 122997
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 122997
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 122997

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail in 123756 pass 
in 123858
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot   fail pass in 123408
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot   fail pass in 123408
 test-xtf-amd64-amd64-17 xen-boot   fail pass in 123408
 test-amd64-i386-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
123408
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail pass in 
123756
 test-amd64-amd64-pair10 xen-boot/src_host  fail pass in 123817
 test-amd64-amd64-pair11 xen-boot/dst_host  fail pass in 123817
 test-xtf-amd64-amd64-4   50 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 123817
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 123817

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 123408 like 
122923
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pae-memop-seg fail in 123408 never pass
 test-xtf-amd64-amd64-1   52 xtf/test-hvm64-memop-seg fail in 123408 never pass
 test-xtf-amd64-amd64-1   77 xtf/test-pv32pae-xsa-194 fail in 123408 never pass
 test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 123756 like 
122997
 test-xtf-amd64-amd64-3  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122923
 test-xtf-amd64-amd64-2  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 122997
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 122997
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 122997
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 122997
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 122997
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 122997
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 122997
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 122997
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 122997
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 122997
 test-xtf-amd64-amd64-4   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-4   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-4   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-3   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-3   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   37 xtf/test-hvm32pae-memop-seg  fail   never pass
 test-xtf-amd64-amd64-5   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-2   52 xtf/test-hvm64-memop-seg fail   never pass
 test-xtf-amd64-amd64-3   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   77 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-check

[Xen-devel] Xen or Bhyve?

[Jason Long]

Hello.
For BSD distros, Xen is better or Bhyve? Can Bhyve be a replacement for Xen? 
Have Bhyve all Xen features?


Thank you.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  35fcb982ea16c40619fee8bba4789a94d824521e
baseline version:
 xen  3960f3a52346348e6b0306f65d19375612bd35b9

Last test of basis   123798  2018-06-04 11:01:56 Z3 days
Testing same since   123894  2018-06-07 15:01:08 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Kevin Tian 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3960f3a523..35fcb982ea  35fcb982ea16c40619fee8bba4789a94d824521e -> smoke

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

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.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:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  60d9ad6f1e42618fce10baeb0f02c35e5ebd5b24
  Bug not present: 9b837963c54ac50d7faae63184d32a0fb599d1b0
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/123901/


  commit 60d9ad6f1e42618fce10baeb0f02c35e5ebd5b24
  Author: Michal Privoznik 
  Date:   Mon Jun 4 06:51:50 2018 +0200
  
  configure: Require GnuTLS
  
  We are building with GnuTLS everywhere because GnuTLS is widely
  available. Also, it is desirable to prefer cryptographically
  strong PRNG over "/dev/urandom" which is just a fallback.
  
  Signed-off-by: Michal Privoznik 
  Reviewed-by: Daniel P. Berrangé 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-amd64-libvirt.libvirt-build 
--summary-out=tmp/123901.bisection-summary --basis-template=123814 
--blessings=real,real-bisect libvirt build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 123840 fail [host=huxelrebe0] / 123814 [host=godello1] 123575 ok.
Failure / basis pass flights: 123840 / 123575
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.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 a9884d70627628f8f0f38fc2b9b99931675b1617 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
Basis pass e36b1f6583324133405c7f4552a9da51e6c61161 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#e36b1f6583324133405c7f4552a9da51e6c61161-a9884d70627628f8f0f38fc2b9b99931675b1617
 
https://git.savannah.gnu.org/git/gnulib.git/#d6397dde2e127e246e3eeb5254a21f42cac783c8-d6397dde2e127e246e3eeb5254a21f42cac783c8
 
https://gitlab.com/keycodemap/keycodemapdb.git#16e5b0787687d8904dad2c026107409eb9bfcb95-16e5b0787687d8904dad2c026107409eb9bfcb95
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#43139135a8938de44f66333831d3a8655d07663a-43139135a8938de44f66333831d3a8655d07663a
 
git://xenbits.xen.org/xen.git#06f542f8f2e446c01bd0edab51e9450af7f6e05b-06f542f8f2e446c01bd0edab51e9450af7f6e05b
Loaded 1001 nodes in revision graph
Searching for test results:
 123575 pass e36b1f6583324133405c7f4552a9da51e6c61161 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
 123840 fail a9884d70627628f8f0f38fc2b9b99931675b1617 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
 123814 [host=godello1]
 123889 fail 3700dd53c3e4890b18b9962955cdf3440dce9746 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
 123890 fail 60d9ad6f1e42618fce10baeb0f02c35e5ebd5b24 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
 123891 pass 9b837963c54ac50d7faae63184d32a0fb599d1b0 
d6397dde2e127e246e3eeb5254a21f42cac783c8 
16e5b0787687d8904dad2c026107409eb9bfcb95 
c8ea0457495342c417c3dc033bba25148b279f60 
43139135a8938de44f66333831d3a8655d07663a 
06f542f8f2e446c01bd0edab51e9450af7f6e05b
 123866 pass 

[Xen-devel] [PATCH v2] multiboot2: clarify usage of the address tag

[Roger Pau Monne]

Add a note to spell out that if the address tag is not present the
file should be loaded using the elf header.

Signed-off-by: Roger Pau Monné 
---
Cc: Daniel Kiper 
Cc: xen-devel@lists.xenproject.org
---
Changes since v1:
 - s/elf/@sc{elf}/
 - s/Multiboot/Multiboot2/
---
 doc/multiboot.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/multiboot.texi b/doc/multiboot.texi
index 2e2d7e74a..3c797787c 100644
--- a/doc/multiboot.texi
+++ b/doc/multiboot.texi
@@ -509,6 +509,12 @@ assumes that no bss segment is present.
 
 @end table
 
+Note: This information does not need to be provided if the kernel image
+is in @sc{elf} format, but it must be provided if the image is in a.out
+format or in some other format. Compliant boot loaders must be able to
+load images that are either in @sc{elf} format or contain the address
+tag embedded in the Multiboot2 header.
+
 @subsection The entry address tag of Multiboot2 header
 
 @example
-- 
2.17.1


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

[Xen-devel] [xen-4.7-testing test] 123852: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 123144
 test-amd64-i386-migrupgrade  10 xen-boot/src_hostfail REGR. vs. 123144
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 123144
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 123144
 test-amd64-i386-migrupgrade  11 xen-boot/dst_hostfail REGR. vs. 123144
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 123144
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 123144
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 123144
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 123144
 test-amd64-amd64-migrupgrade 10 xen-boot/src_hostfail REGR. vs. 123144
 test-amd64-amd64-migrupgrade 11 xen-boot/dst_hostfail REGR. vs. 123144

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-qemuu-nested-intel  7 xen-bootfail pass in 123812
 test-amd64-i386-libvirt-pair 23 guest-migrate/dst_host/src_host fail pass in 
123812
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-saverestore.2 
fail pass in 123812

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 123812 like 
123144
 test-xtf-amd64-amd64-4  50 xtf/test-hvm64-lbr-tsx-vmentry fail like 123144
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123144
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 123144
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 123144
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123144
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 123144
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123144
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123144
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 123144
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 123144
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 123144
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 123144
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 123144
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 123144
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail 

Re: [Xen-devel] [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Konrad Rzeszutek Wilk]

On Thu, Jun 07, 2018 at 04:40:48PM +0300, Oleksandr Andrushchenko wrote:
> On 06/07/2018 04:28 PM, Konrad Rzeszutek Wilk wrote:
> > On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:
> > > From: Oleksandr Andrushchenko 
> > > 
> > > If frontend is configured to expose multiple input device instances
> > > then backend may require a way to uniquely identify concrete input
> > > device within the frontend. This is useful for use-cases where
> > > virtual input device needs to be matched to physical input device.
> > > Add XenBus "unique-id" node parameter, so this sort of use-cases can
> > > be implemented.
> > > 
> > > Signed-off-by: Oleksandr Andrushchenko 
> > > ---
> > >   xen/include/public/io/kbdif.h | 10 ++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> > > index a68da0f1a37f..45e4ff5b0a05 100644
> > > --- a/xen/include/public/io/kbdif.h
> > > +++ b/xen/include/public/io/kbdif.h
> > > @@ -82,6 +82,15 @@
> > >*  for pointer devices should set this to 1. Raw (unscaled) values 
> > > have
> > >*  a range of [0, 0x7fff].
> > >*
> > > + *---  Device Instance Parameters 
> > > 
> > > + *
> > > + * unique-id
> > > + *  Values: 
> > Wouldn't a string be easier? That way you can extend this in the future
> > to also have an UUID or so?
> Much easier. We were thinking about that as well, but sndif already has it
> as uint32_t. If you are ok to change uniquie-id for sndif to string then
> that
> would be much better: UUID as you mention + all protocols have unique-id
> consistently defined as string.
> sndif's unique-id is not used by the frontend driver and we are about
> to start libx/xl support for sound, so I think this is the right time for
> such a change.
> If you are fine with that then I'll send yet another patch for sndif.

Please do and feel free to add 

Reviewed-by: Konrad Rzeszutek Wilk 

on it.

Also pls CC Juergen so he can release-ack it.
> > > + *
> > > + *  After device instance initialization it is assigned a unique ID
> > > + *  (within the front driver), so every instance of the frontend can 
> > > be
> > > + *  identified by the backend by this ID.
> > > + *
> > >*- Pointer Device Parameters 
> > > 
> > >*
> > >* width
> > > @@ -204,6 +213,7 @@
> > >   #define XENKBD_FIELD_MT_WIDTH  "multi-touch-width"
> > >   #define XENKBD_FIELD_MT_HEIGHT "multi-touch-height"
> > >   #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
> > > +#define XENKBD_FIELD_UNIQUE_ID "unique-id"
> > >   /* OBSOLETE, not recommended for use */
> > >   #define XENKBD_FIELD_RING_REF  "page-ref"
> > > -- 
> > > 2.17.0
> > > 
> 

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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Jan Beulich]

>>> On 07.06.18 at 17:21,  wrote:
>>  -Original Message-
>> From: Ian Jackson [mailto:ian.jack...@citrix.com]
>> Sent: 07 June 2018 15:21
>> To: Paul Durrant 
>> Cc: George Dunlap ; Jan Beulich
>> ; Andrew Cooper ; Wei
>> Liu ; Stefano Stabellini ; xen-
>> devel ; Konrad Rzeszutek Wilk
>> ; Daniel de Graaf ; Tim
>> (Xen.org) 
>> Subject: RE: [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op
>> 
>> Paul Durrant writes ("RE: [PATCH 5/7] public / x86: introduce
>> __HYPERCALL_iommu_op"):
>> > FWIW Linux appears to use a single '_' prefix and no suffix.
>> 
>> This practice of scattering underscores about, apparently at random,
>> is baffling to me.
>> 
>> It doesn't look like most of the people who do it are aware of the
>> rules.  For example, #defining any identifier starting __ is a licence
>> to the compiler to stuff demons up your nose.
>> 
>> We should do this:
>>   #define XEN_PUBLIC_IOMMU_OP_H
>> which is (i) not in any of the compiler's namespaces (ii) has XEN_ at
>> the beginning so we can justify thinking that it won't clash with
>> anyone else's identifiers (Iii) will never clash with any of our own
>> because it ends in _H.
>> 
> 
> Sounds ok to me. Patch to CODING_STYLE?

I've sent a patch already, but that's addressing the other aspect. I
don't think CODING_STYLE needs to talk about conforming with
language standards. To reduce the risk of misguiding people, I agree
we should see about reducing the number of existing violations. We've
been doing this for quite a while, but the process is rather slow going,
largely because so far we mostly change things we need to touch
anyway.

Jan



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

Re: [Xen-devel] [PATCH] multiboot2: clarify usage of the address tag

[Daniel Kiper]

On Thu, Jun 07, 2018 at 04:46:37PM +0200, Roger Pau Monné wrote:
> On Wed, Jun 06, 2018 at 07:28:20PM +0200, Daniel Kiper wrote:
> > On Tue, Jun 05, 2018 at 11:55:36AM +0200, Roger Pau Monne wrote:
> > > Add a note to spell out that if the address tag is not present the
> > > file should be loaded using the elf header.
> > >
> > > Signed-off-by: Roger Pau Monné 
> > > ---
> > > Cc: Daniel Kiper 
> > > Cc: xen-devel@lists.xenproject.org
> > > ---
> > >  doc/multiboot.texi | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > > index 2e2d7e74a..196f9c17a 100644
> > > --- a/doc/multiboot.texi
> > > +++ b/doc/multiboot.texi
> > > @@ -509,6 +509,12 @@ assumes that no bss segment is present.
> > >
> > >  @end table
> > >
> > > +Note: This information does not need to be provided if the kernel
> > > +image is in elf format, but it must be provided if the image is in
> >
> > s/elf/@sc{elf}/
> >
> > > +a.out format or in some other format. Compliant boot loaders must be
> > > +able to load images that are either in elf format or contain the
> >
> > Ditto.
> >
> > > +address tag embedded in the Multiboot header.
> >
> > s/Multiboot/Multiboot2/
> >
> > I think that it is also worth mentioning that the address tag has
> > preference over relevant data provided in ELF header.
> >
> > Additionally, may I ask you to provide similar patch for Multiboot spec?
> > You can find it in multiboot branch. Please look for "The address fields
> > of Multiboot header" paragraph.
>
> Multiboot1 already has such paragraph in the "3.1.2 The magic fields
> of Multiboot header" section.

Yep, you are right. So, please just send me updated Multiboot2 spec patch.

Daniel

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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Paul Durrant]

> -Original Message-
> From: Ian Jackson [mailto:ian.jack...@citrix.com]
> Sent: 07 June 2018 15:21
> To: Paul Durrant 
> Cc: George Dunlap ; Jan Beulich
> ; Andrew Cooper ; Wei
> Liu ; Stefano Stabellini ; xen-
> devel ; Konrad Rzeszutek Wilk
> ; Daniel de Graaf ; Tim
> (Xen.org) 
> Subject: RE: [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op
> 
> Paul Durrant writes ("RE: [PATCH 5/7] public / x86: introduce
> __HYPERCALL_iommu_op"):
> > FWIW Linux appears to use a single '_' prefix and no suffix.
> 
> This practice of scattering underscores about, apparently at random,
> is baffling to me.
> 
> It doesn't look like most of the people who do it are aware of the
> rules.  For example, #defining any identifier starting __ is a licence
> to the compiler to stuff demons up your nose.
> 
> We should do this:
>   #define XEN_PUBLIC_IOMMU_OP_H
> which is (i) not in any of the compiler's namespaces (ii) has XEN_ at
> the beginning so we can justify thinking that it won't clash with
> anyone else's identifiers (Iii) will never clash with any of our own
> because it ends in _H.
> 

Sounds ok to me. Patch to CODING_STYLE?

  Paul

> Ian.

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

[Xen-devel] [PATCH v7 15/15] x86/domctl: Don't pause the whole domain if only getting vcpu state

[Alexandru Isaila]

This patch is focused moving the for loop to the caller so
now we can save info for a single vcpu instance.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/cpu/mcheck/vmce.c |   3 +-
 xen/arch/x86/hvm/hpet.c|   3 +-
 xen/arch/x86/hvm/hvm.c |  12 ++---
 xen/arch/x86/hvm/i8254.c   |   3 +-
 xen/arch/x86/hvm/irq.c |   9 ++--
 xen/arch/x86/hvm/mtrr.c|   3 +-
 xen/arch/x86/hvm/pmtimer.c |   3 +-
 xen/arch/x86/hvm/rtc.c |   3 +-
 xen/arch/x86/hvm/save.c| 118 ++---
 xen/arch/x86/hvm/vioapic.c |   3 +-
 xen/arch/x86/hvm/viridian.c|   7 +--
 xen/arch/x86/hvm/vlapic.c  |  34 
 xen/arch/x86/hvm/vpic.c|   3 +-
 xen/include/asm-x86/hvm/save.h |   2 +-
 14 files changed, 125 insertions(+), 81 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index ead1f73..88541b7 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,10 +349,9 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
-static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+static int vmce_save_vcpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
 {
 struct hvm_vmce_vcpu ctxt;
-struct vcpu *v = NULL;
 
 ctxt.caps = v->arch.vmce.mcg_cap;
 ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 2837709..3ed6547 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -516,8 +516,9 @@ static const struct hvm_mmio_ops hpet_mmio_ops = {
 };
 
 
-static int hpet_save(struct domain *d, hvm_domain_context_t *h)
+static int hpet_save(struct vcpu *vcpu, hvm_domain_context_t *h)
 {
+struct domain *d = vcpu->domain;
 HPETState *hp = domain_vhpet(d);
 struct vcpu *v = pt_global_vcpu_target(d);
 int rc;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index a88efeb..70d90cc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -740,9 +740,8 @@ void hvm_domain_destroy(struct domain *d)
 destroy_vpci_mmcfg(d);
 }
 
-static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_tsc_adjust(struct vcpu *v, hvm_domain_context_t *h)
 {
-struct vcpu *v = NULL;
 struct hvm_tsc_adjust ctxt;
 
 ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
@@ -772,11 +771,10 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
-static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_cpu_ctxt(struct vcpu *v, hvm_domain_context_t *h)
 {
 struct segment_register seg;
 struct hvm_hw_cpu ctxt = {};
-struct vcpu *v = NULL;
 
 /* We don't need to save state for a vcpu that is down; the restore
  * code will leave it down if there is nothing saved. */
@@ -1160,9 +1158,8 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, 
hvm_load_cpu_ctxt,
save_area) + \
   xstate_ctxt_size(xcr0))
 
-static int hvm_save_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_cpu_xsave_states(struct vcpu *v, hvm_domain_context_t *h)
 {
-struct vcpu *v = NULL;
 struct hvm_hw_cpu_xsave *ctxt;
 unsigned int size = HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum);
 
@@ -1322,9 +1319,8 @@ static const uint32_t msrs_to_send[] = {
 };
 static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
 
-static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h)
+static int hvm_save_cpu_msrs(struct vcpu *v, hvm_domain_context_t *h)
 {
-struct vcpu *v = NULL;
 struct hvm_save_descriptor *desc = _p(>data[h->cur]);
 struct hvm_msr *ctxt;
 unsigned int i;
diff --git a/xen/arch/x86/hvm/i8254.c b/xen/arch/x86/hvm/i8254.c
index 992f08d..e0d2255 100644
--- a/xen/arch/x86/hvm/i8254.c
+++ b/xen/arch/x86/hvm/i8254.c
@@ -390,8 +390,9 @@ void pit_stop_channel0_irq(PITState *pit)
 spin_unlock(>lock);
 }
 
-static int pit_save(struct domain *d, hvm_domain_context_t *h)
+static int pit_save(struct vcpu *v, hvm_domain_context_t *h)
 {
+struct domain *d = v->domain;
 PITState *pit = domain_vpit(d);
 int rc;
 
diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c
index c85d004..72acb73 100644
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -630,8 +630,9 @@ static int __init dump_irq_info_key_init(void)
 }
 __initcall(dump_irq_info_key_init);
 
-static int irq_save_pci(struct domain *d, hvm_domain_context_t *h)
+static int irq_save_pci(struct vcpu *v, hvm_domain_context_t *h)
 {
+struct domain *d = v->domain;
 struct hvm_irq *hvm_irq = hvm_domain_irq(d);
 unsigned int asserted, pdev, pintx;
 int rc;
@@ -662,16 +663,18 @@ static int 

[Xen-devel] [PATCH v7 13/15] x86/hvm: Remove loop from hvm_save_mtrr_msr func

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/mtrr.c | 33 -
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index d311031..4c1e850 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -666,46 +666,37 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, 
uint64_t gfn_start,
 return 0;
 }
 
-static void hvm_save_mtrr_msr_one(struct vcpu *v, struct hvm_hw_mtrr *hw_mtrr)
+static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
 {
+struct vcpu *v = NULL;
+struct hvm_hw_mtrr hw_mtrr;
 struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
 int i;
+/* save mtrr */
 
-hvm_get_guest_pat(v, _mtrr->msr_pat_cr);
+hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
 
-hw_mtrr->msr_mtrr_def_type = mtrr_state->def_type
+hw_mtrr.msr_mtrr_def_type = mtrr_state->def_type
 | (mtrr_state->enabled << 10);
-hw_mtrr->msr_mtrr_cap = mtrr_state->mtrr_cap;
+hw_mtrr.msr_mtrr_cap = mtrr_state->mtrr_cap;
 
 for ( i = 0; i < MTRR_VCNT; i++ )
 {
 /* save physbase */
-hw_mtrr->msr_mtrr_var[i*2] =
+hw_mtrr.msr_mtrr_var[i*2] =
 ((uint64_t*)mtrr_state->var_ranges)[i*2];
 /* save physmask */
-hw_mtrr->msr_mtrr_var[i*2+1] =
+hw_mtrr.msr_mtrr_var[i*2+1] =
 ((uint64_t*)mtrr_state->var_ranges)[i*2+1];
 }
 
 for ( i = 0; i < NUM_FIXED_MSR; i++ )
-hw_mtrr->msr_mtrr_fixed[i] =
+hw_mtrr.msr_mtrr_fixed[i] =
 ((uint64_t*)mtrr_state->fixed_ranges)[i];
 
-}
-
-static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
-{
-struct vcpu *v;
-struct hvm_hw_mtrr hw_mtrr;
-/* save mtrr */
-
-for_each_vcpu(d, v)
-{
-hvm_save_mtrr_msr_one(v, _mtrr);
+if ( hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr) != 0 )
+return 1;
 
-if ( hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr) != 0 )
-return 1;
-}
 return 0;
 }
 
-- 
2.7.4


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

[Xen-devel] [PATCH v7 00/15] x86/domctl: Save info for one vcpu instance

[Alexandru Isaila]

Hi all,

This patch series addresses the ideea of saving data from a single vcpu 
instance.
First it starts by adding *save_one functions, then it removes the for loops 
from
the *save functions and it merges them to the *save_one functions.
In the final patch, the hvm_save and hvm_save_one functions are changed to make 
use   
of the new *save functions.

Cheers,

Alexandru Isaila (15):

 x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func
 x86/hvm: Introduce hvm_save_tsc_adjust_one() func
 x86/hvm: Introduce hvm_save_cpu_ctxt_one func
 x86/hvm: Introduce hvm_save_cpu_xsave_states_one
 x86/hvm: Introduce hvm_save_cpu_msrs_one func
 x86/hvm: Introduce hvm_save_mtrr_msr_one func
 x86/hvm: Introduce viridian_save_vcpu_ctxt_one()
 x86/cpu: Remove loop form vmce_save_vcpu_ctxt() func
 x86/hvm: Remove loop from hvm_save_tsc_adjust() func
 x86/hvm: Remove loop from hvm_save_cpu_ctxt func
 x86/hvm: Remove loop from hvm_save_cpu_xsave_states
 x86/hvm: Remove loop from hvm_save_cpu_msrs func
 x86/hvm: Remove loop from hvm_save_mtrr_msr func
 x86/hvm: Remove loop from viridian_save_vcpu_ctxt()
 x86/domctl: Don't pause the whole domain if only getting vcpu state

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

[Xen-devel] [PATCH v7 07/15] x86/hvm: Introduce viridian_save_vcpu_ctxt_one() func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 

---
Changes since V6:
- Add memset to 0 for ctxt
---
 xen/arch/x86/hvm/viridian.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 694eae6..bab606e 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -1026,6 +1026,13 @@ static int viridian_load_domain_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
   viridian_load_domain_ctxt, 1, HVMSR_PER_DOM);
 
+static void viridian_save_vcpu_ctxt_one(struct vcpu *v, struct 
hvm_viridian_vcpu_context *ctxt)
+{
+memset(ctxt, 0, sizeof(*ctxt));
+ctxt->vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw;
+ctxt->vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending;
+}
+
 static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -1034,10 +1041,9 @@ static int viridian_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return 0;
 
 for_each_vcpu( d, v ) {
-struct hvm_viridian_vcpu_context ctxt = {
-.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw,
-.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending,
-};
+struct hvm_viridian_vcpu_context ctxt;
+
+viridian_save_vcpu_ctxt_one(v, );
 
 if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, ) != 0 )
 return 1;
-- 
2.7.4


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

[Xen-devel] [PATCH v7 04/15] x86/hvm: Introduce hvm_save_cpu_xsave_states_one

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index b254378..e8ecabf 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1183,6 +1183,13 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, 
hvm_load_cpu_ctxt,
save_area) + \
   xstate_ctxt_size(xcr0))
 
+static void hvm_save_cpu_xsave_states_one(struct vcpu *v, struct 
hvm_hw_cpu_xsave *ctxt)
+{
+ctxt->xfeature_mask = xfeature_mask;
+ctxt->xcr0 = v->arch.xcr0;
+ctxt->xcr0_accum = v->arch.xcr0_accum;
+}
+
 static int hvm_save_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -1202,9 +1209,7 @@ static int hvm_save_cpu_xsave_states(struct domain *d, 
hvm_domain_context_t *h)
 ctxt = (struct hvm_hw_cpu_xsave *)>data[h->cur];
 h->cur += size;
 
-ctxt->xfeature_mask = xfeature_mask;
-ctxt->xcr0 = v->arch.xcr0;
-ctxt->xcr0_accum = v->arch.xcr0_accum;
+hvm_save_cpu_xsave_states_one(v, ctxt);
 expand_xsave_states(v, >save_area,
 size - offsetof(typeof(*ctxt), save_area));
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v7 12/15] x86/hvm: Remove loop from hvm_save_cpu_msrs func

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 58 +++---
 1 file changed, 22 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2542cbd..a88efeb 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1322,10 +1322,18 @@ static const uint32_t msrs_to_send[] = {
 };
 static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
 
-static int hvm_save_cpu_msrs_one(struct vcpu *v, struct hvm_msr *ctxt)
+static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h)
 {
+struct vcpu *v = NULL;
+struct hvm_save_descriptor *desc = _p(>data[h->cur]);
+struct hvm_msr *ctxt;
 unsigned int i;
 
+if ( _hvm_init_entry(h, CPU_MSR_CODE, v->vcpu_id,
+ HVM_CPU_MSR_SIZE(msr_count_max)) )
+return 1;
+ctxt = (struct hvm_msr *)>data[h->cur];
+ctxt->count = 0;
 for ( i = 0; i < ARRAY_SIZE(msrs_to_send); ++i )
 {
 uint64_t val;
@@ -1351,46 +1359,24 @@ static int hvm_save_cpu_msrs_one(struct vcpu *v, struct 
hvm_msr *ctxt)
 ctxt->msr[ctxt->count].index = msrs_to_send[i];
 ctxt->msr[ctxt->count++].val = val;
 }
-return 0;
-}
 
-static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h)
-{
-struct vcpu *v;
+if ( hvm_funcs.save_msr )
+hvm_funcs.save_msr(v, ctxt);
 
-for_each_vcpu ( d, v )
-{
-struct hvm_save_descriptor *desc = _p(>data[h->cur]);
-struct hvm_msr *ctxt;
-unsigned int i;
+ASSERT(ctxt->count <= msr_count_max);
 
-if ( _hvm_init_entry(h, CPU_MSR_CODE, v->vcpu_id,
- HVM_CPU_MSR_SIZE(msr_count_max)) )
-return 1;
-ctxt = (struct hvm_msr *)>data[h->cur];
-ctxt->count = 0;
-
-if ( hvm_save_cpu_msrs_one(v, ctxt) == -ENXIO )
-return -ENXIO;
-
-if ( hvm_funcs.save_msr )
-hvm_funcs.save_msr(v, ctxt);
-
-ASSERT(ctxt->count <= msr_count_max);
-
-for ( i = 0; i < ctxt->count; ++i )
-ctxt->msr[i]._rsvd = 0;
+for ( i = 0; i < ctxt->count; ++i )
+ctxt->msr[i]._rsvd = 0;
 
-if ( ctxt->count )
-{
-/* Rewrite length to indicate how much space we actually used. */
-desc->length = HVM_CPU_MSR_SIZE(ctxt->count);
-h->cur += HVM_CPU_MSR_SIZE(ctxt->count);
-}
-else
-/* or rewind and remove the descriptor from the stream. */
-h->cur -= sizeof(struct hvm_save_descriptor);
+if ( ctxt->count )
+{
+/* Rewrite length to indicate how much space we actually used. */
+desc->length = HVM_CPU_MSR_SIZE(ctxt->count);
+h->cur += HVM_CPU_MSR_SIZE(ctxt->count);
 }
+else
+/* or rewind and remove the descriptor from the stream. */
+h->cur -= sizeof(struct hvm_save_descriptor);
 
 return 0;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v7 10/15] x86/hvm: Remove loop from hvm_save_cpu_ctxt func

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c| 166 ++
 xen/include/asm-x86/hvm/support.h |   2 +
 2 files changed, 80 insertions(+), 88 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 701e81c..38e5e96 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -772,123 +772,113 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
-static void hvm_save_cpu_ctxt_one(struct vcpu *v, struct hvm_hw_cpu *ctxt)
+static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct segment_register seg;
+struct hvm_hw_cpu ctxt = {};
+struct vcpu *v = NULL;
+
+/* We don't need to save state for a vcpu that is down; the restore
+ * code will leave it down if there is nothing saved. */
+if ( v->pause_flags & VPF_down )
+   return CONTINUE;
 
 /* Architecture-specific vmcs/vmcb bits */
-hvm_funcs.save_cpu_ctxt(v, ctxt);
+hvm_funcs.save_cpu_ctxt(v, );
 
-ctxt->tsc = hvm_get_guest_tsc_fixed(v, 
v->domain->arch.hvm_domain.sync_tsc);
+ctxt.tsc = hvm_get_guest_tsc_fixed(v, v->domain->arch.hvm_domain.sync_tsc);
 
-ctxt->msr_tsc_aux = hvm_msr_tsc_aux(v);
+ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
 
 hvm_get_segment_register(v, x86_seg_idtr, );
-ctxt->idtr_limit = seg.limit;
-ctxt->idtr_base = seg.base;
+ctxt.idtr_limit = seg.limit;
+ctxt.idtr_base = seg.base;
 
 hvm_get_segment_register(v, x86_seg_gdtr, );
-ctxt->gdtr_limit = seg.limit;
-ctxt->gdtr_base = seg.base;
+ctxt.gdtr_limit = seg.limit;
+ctxt.gdtr_base = seg.base;
 
 hvm_get_segment_register(v, x86_seg_cs, );
-ctxt->cs_sel = seg.sel;
-ctxt->cs_limit = seg.limit;
-ctxt->cs_base = seg.base;
-ctxt->cs_arbytes = seg.attr;
+ctxt.cs_sel = seg.sel;
+ctxt.cs_limit = seg.limit;
+ctxt.cs_base = seg.base;
+ctxt.cs_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_ds, );
-ctxt->ds_sel = seg.sel;
-ctxt->ds_limit = seg.limit;
-ctxt->ds_base = seg.base;
-ctxt->ds_arbytes = seg.attr;
+ctxt.ds_sel = seg.sel;
+ctxt.ds_limit = seg.limit;
+ctxt.ds_base = seg.base;
+ctxt.ds_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_es, );
-ctxt->es_sel = seg.sel;
-ctxt->es_limit = seg.limit;
-ctxt->es_base = seg.base;
-ctxt->es_arbytes = seg.attr;
+ctxt.es_sel = seg.sel;
+ctxt.es_limit = seg.limit;
+ctxt.es_base = seg.base;
+ctxt.es_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_ss, );
-ctxt->ss_sel = seg.sel;
-ctxt->ss_limit = seg.limit;
-ctxt->ss_base = seg.base;
-ctxt->ss_arbytes = seg.attr;
+ctxt.ss_sel = seg.sel;
+ctxt.ss_limit = seg.limit;
+ctxt.ss_base = seg.base;
+ctxt.ss_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_fs, );
-ctxt->fs_sel = seg.sel;
-ctxt->fs_limit = seg.limit;
-ctxt->fs_base = seg.base;
-ctxt->fs_arbytes = seg.attr;
+ctxt.fs_sel = seg.sel;
+ctxt.fs_limit = seg.limit;
+ctxt.fs_base = seg.base;
+ctxt.fs_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_gs, );
-ctxt->gs_sel = seg.sel;
-ctxt->gs_limit = seg.limit;
-ctxt->gs_base = seg.base;
-ctxt->gs_arbytes = seg.attr;
+ctxt.gs_sel = seg.sel;
+ctxt.gs_limit = seg.limit;
+ctxt.gs_base = seg.base;
+ctxt.gs_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_tr, );
-ctxt->tr_sel = seg.sel;
-ctxt->tr_limit = seg.limit;
-ctxt->tr_base = seg.base;
-ctxt->tr_arbytes = seg.attr;
+ctxt.tr_sel = seg.sel;
+ctxt.tr_limit = seg.limit;
+ctxt.tr_base = seg.base;
+ctxt.tr_arbytes = seg.attr;
 
 hvm_get_segment_register(v, x86_seg_ldtr, );
-ctxt->ldtr_sel = seg.sel;
-ctxt->ldtr_limit = seg.limit;
-ctxt->ldtr_base = seg.base;
-ctxt->ldtr_arbytes = seg.attr;
+ctxt.ldtr_sel = seg.sel;
+ctxt.ldtr_limit = seg.limit;
+ctxt.ldtr_base = seg.base;
+ctxt.ldtr_arbytes = seg.attr;
 
 if ( v->fpu_initialised )
 {
-memcpy(ctxt->fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt->fpu_regs));
-ctxt->flags = XEN_X86_FPU_INITIALISED;
-}
-
-ctxt->rax = v->arch.user_regs.rax;
-ctxt->rbx = v->arch.user_regs.rbx;
-ctxt->rcx = v->arch.user_regs.rcx;
-ctxt->rdx = v->arch.user_regs.rdx;
-ctxt->rbp = v->arch.user_regs.rbp;
-ctxt->rsi = v->arch.user_regs.rsi;
-ctxt->rdi = v->arch.user_regs.rdi;
-ctxt->rsp = v->arch.user_regs.rsp;
-ctxt->rip = v->arch.user_regs.rip;
-ctxt->rflags = v->arch.user_regs.rflags;
-ctxt->r8  = v->arch.user_regs.r8;
-ctxt->r9  = v->arch.user_regs.r9;
-ctxt->r10 = v->arch.user_regs.r10;
-ctxt->r11 = v->arch.user_regs.r11;
-ctxt->r12 = v->arch.user_regs.r12;
-

[Xen-devel] [PATCH v7 09/15] x86/hvm: Remove loop from hvm_save_tsc_adjust() func

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7e90bf2..701e81c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -740,26 +740,13 @@ void hvm_domain_destroy(struct domain *d)
 destroy_vpci_mmcfg(d);
 }
 
-static void hvm_save_tsc_adjust_one(struct vcpu *v, struct hvm_tsc_adjust 
*ctxt)
-{
-ctxt->tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
-}
-
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
 {
-struct vcpu *v;
+struct vcpu *v = NULL;
 struct hvm_tsc_adjust ctxt;
-int err = 0;
 
-for_each_vcpu ( d, v )
-{
-hvm_save_tsc_adjust_one(v, );
-err = hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
-if ( err )
-break;
-}
-
-return err;
+ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
+return hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
 }
 
 static int hvm_load_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
-- 
2.7.4


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

[Xen-devel] [PATCH v7 14/15] x86/hvm: Remove loop from viridian_save_vcpu_ctxt() func

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/viridian.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index bab606e..86a43ee 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -1026,28 +1026,20 @@ static int viridian_load_domain_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(VIRIDIAN_DOMAIN, viridian_save_domain_ctxt,
   viridian_load_domain_ctxt, 1, HVMSR_PER_DOM);
 
-static void viridian_save_vcpu_ctxt_one(struct vcpu *v, struct 
hvm_viridian_vcpu_context *ctxt)
-{
-memset(ctxt, 0, sizeof(*ctxt));
-ctxt->vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw;
-ctxt->vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending;
-}
 
 static int viridian_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
-struct vcpu *v;
+struct vcpu *v = NULL;
+struct hvm_viridian_vcpu_context ctxt = {
+.vp_assist_msr = v->arch.hvm_vcpu.viridian.vp_assist.msr.raw,
+.vp_assist_pending = v->arch.hvm_vcpu.viridian.vp_assist.pending,
+};
 
 if ( !is_viridian_domain(d) )
 return 0;
 
-for_each_vcpu( d, v ) {
-struct hvm_viridian_vcpu_context ctxt;
-
-viridian_save_vcpu_ctxt_one(v, );
-
-if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, ) != 0 )
-return 1;
-}
+if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, ) != 0 )
+return 1;
 
 return 0;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v7 03/15] x86/hvm: Introduce hvm_save_cpu_ctxt_one func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 195 +
 1 file changed, 100 insertions(+), 95 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 76f7db9..b254378 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -785,11 +785,109 @@ static int hvm_load_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 HVM_REGISTER_SAVE_RESTORE(TSC_ADJUST, hvm_save_tsc_adjust,
   hvm_load_tsc_adjust, 1, HVMSR_PER_VCPU);
 
+static void hvm_save_cpu_ctxt_one(struct vcpu *v, struct hvm_hw_cpu *ctxt)
+{
+struct segment_register seg;
+
+/* Architecture-specific vmcs/vmcb bits */
+hvm_funcs.save_cpu_ctxt(v, ctxt);
+
+ctxt->tsc = hvm_get_guest_tsc_fixed(v, 
v->domain->arch.hvm_domain.sync_tsc);
+
+ctxt->msr_tsc_aux = hvm_msr_tsc_aux(v);
+
+hvm_get_segment_register(v, x86_seg_idtr, );
+ctxt->idtr_limit = seg.limit;
+ctxt->idtr_base = seg.base;
+
+hvm_get_segment_register(v, x86_seg_gdtr, );
+ctxt->gdtr_limit = seg.limit;
+ctxt->gdtr_base = seg.base;
+
+hvm_get_segment_register(v, x86_seg_cs, );
+ctxt->cs_sel = seg.sel;
+ctxt->cs_limit = seg.limit;
+ctxt->cs_base = seg.base;
+ctxt->cs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ds, );
+ctxt->ds_sel = seg.sel;
+ctxt->ds_limit = seg.limit;
+ctxt->ds_base = seg.base;
+ctxt->ds_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_es, );
+ctxt->es_sel = seg.sel;
+ctxt->es_limit = seg.limit;
+ctxt->es_base = seg.base;
+ctxt->es_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ss, );
+ctxt->ss_sel = seg.sel;
+ctxt->ss_limit = seg.limit;
+ctxt->ss_base = seg.base;
+ctxt->ss_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_fs, );
+ctxt->fs_sel = seg.sel;
+ctxt->fs_limit = seg.limit;
+ctxt->fs_base = seg.base;
+ctxt->fs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_gs, );
+ctxt->gs_sel = seg.sel;
+ctxt->gs_limit = seg.limit;
+ctxt->gs_base = seg.base;
+ctxt->gs_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_tr, );
+ctxt->tr_sel = seg.sel;
+ctxt->tr_limit = seg.limit;
+ctxt->tr_base = seg.base;
+ctxt->tr_arbytes = seg.attr;
+
+hvm_get_segment_register(v, x86_seg_ldtr, );
+ctxt->ldtr_sel = seg.sel;
+ctxt->ldtr_limit = seg.limit;
+ctxt->ldtr_base = seg.base;
+ctxt->ldtr_arbytes = seg.attr;
+
+if ( v->fpu_initialised )
+{
+memcpy(ctxt->fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt->fpu_regs));
+ctxt->flags = XEN_X86_FPU_INITIALISED;
+}
+
+ctxt->rax = v->arch.user_regs.rax;
+ctxt->rbx = v->arch.user_regs.rbx;
+ctxt->rcx = v->arch.user_regs.rcx;
+ctxt->rdx = v->arch.user_regs.rdx;
+ctxt->rbp = v->arch.user_regs.rbp;
+ctxt->rsi = v->arch.user_regs.rsi;
+ctxt->rdi = v->arch.user_regs.rdi;
+ctxt->rsp = v->arch.user_regs.rsp;
+ctxt->rip = v->arch.user_regs.rip;
+ctxt->rflags = v->arch.user_regs.rflags;
+ctxt->r8  = v->arch.user_regs.r8;
+ctxt->r9  = v->arch.user_regs.r9;
+ctxt->r10 = v->arch.user_regs.r10;
+ctxt->r11 = v->arch.user_regs.r11;
+ctxt->r12 = v->arch.user_regs.r12;
+ctxt->r13 = v->arch.user_regs.r13;
+ctxt->r14 = v->arch.user_regs.r14;
+ctxt->r15 = v->arch.user_regs.r15;
+ctxt->dr0 = v->arch.debugreg[0];
+ctxt->dr1 = v->arch.debugreg[1];
+ctxt->dr2 = v->arch.debugreg[2];
+ctxt->dr3 = v->arch.debugreg[3];
+ctxt->dr6 = v->arch.debugreg[6];
+ctxt->dr7 = v->arch.debugreg[7];
+}
+
 static int hvm_save_cpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
 struct hvm_hw_cpu ctxt;
-struct segment_register seg;
 
 for_each_vcpu ( d, v )
 {
@@ -799,100 +897,7 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 continue;
 
 memset(, 0, sizeof(ctxt));
-
-/* Architecture-specific vmcs/vmcb bits */
-hvm_funcs.save_cpu_ctxt(v, );
-
-ctxt.tsc = hvm_get_guest_tsc_fixed(v, d->arch.hvm_domain.sync_tsc);
-
-ctxt.msr_tsc_aux = hvm_msr_tsc_aux(v);
-
-hvm_get_segment_register(v, x86_seg_idtr, );
-ctxt.idtr_limit = seg.limit;
-ctxt.idtr_base = seg.base;
-
-hvm_get_segment_register(v, x86_seg_gdtr, );
-ctxt.gdtr_limit = seg.limit;
-ctxt.gdtr_base = seg.base;
-
-hvm_get_segment_register(v, x86_seg_cs, );
-ctxt.cs_sel = seg.sel;
-ctxt.cs_limit = seg.limit;
-ctxt.cs_base = seg.base;
-ctxt.cs_arbytes = seg.attr;
-
-hvm_get_segment_register(v, x86_seg_ds, );
-ctxt.ds_sel = seg.sel;
-ctxt.ds_limit = seg.limit;
-ctxt.ds_base = seg.base;
-ctxt.ds_arbytes = seg.attr;
-
-hvm_get_segment_register(v, x86_seg_es, 

[Xen-devel] [PATCH v7 02/15] x86/hvm: Introduce hvm_save_tsc_adjust_one() func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c23983c..76f7db9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -740,6 +740,11 @@ void hvm_domain_destroy(struct domain *d)
 destroy_vpci_mmcfg(d);
 }
 
+static void hvm_save_tsc_adjust_one(struct vcpu *v, struct hvm_tsc_adjust 
*ctxt)
+{
+ctxt->tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
+}
+
 static int hvm_save_tsc_adjust(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -748,7 +753,7 @@ static int hvm_save_tsc_adjust(struct domain *d, 
hvm_domain_context_t *h)
 
 for_each_vcpu ( d, v )
 {
-ctxt.tsc_adjust = v->arch.hvm_vcpu.msr_tsc_adjust;
+hvm_save_tsc_adjust_one(v, );
 err = hvm_save_entry(TSC_ADJUST, v->vcpu_id, h, );
 if ( err )
 break;
-- 
2.7.4


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

[Xen-devel] [PATCH v7 11/15] x86/hvm: Remove loop from hvm_save_cpu_xsave_states

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/hvm.c | 35 +--
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 38e5e96..2542cbd 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1160,36 +1160,27 @@ HVM_REGISTER_SAVE_RESTORE(CPU, hvm_save_cpu_ctxt, 
hvm_load_cpu_ctxt,
save_area) + \
   xstate_ctxt_size(xcr0))
 
-static void hvm_save_cpu_xsave_states_one(struct vcpu *v, struct 
hvm_hw_cpu_xsave *ctxt)
-{
-ctxt->xfeature_mask = xfeature_mask;
-ctxt->xcr0 = v->arch.xcr0;
-ctxt->xcr0_accum = v->arch.xcr0_accum;
-}
-
 static int hvm_save_cpu_xsave_states(struct domain *d, hvm_domain_context_t *h)
 {
-struct vcpu *v;
+struct vcpu *v = NULL;
 struct hvm_hw_cpu_xsave *ctxt;
+unsigned int size = HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum);
 
 if ( !cpu_has_xsave )
 return 0;   /* do nothing */
 
-for_each_vcpu ( d, v )
-{
-unsigned int size = HVM_CPU_XSAVE_SIZE(v->arch.xcr0_accum);
-
-if ( !xsave_enabled(v) )
-continue;
-if ( _hvm_init_entry(h, CPU_XSAVE_CODE, v->vcpu_id, size) )
-return 1;
-ctxt = (struct hvm_hw_cpu_xsave *)>data[h->cur];
-h->cur += size;
+if ( !xsave_enabled(v) )
+return CONTINUE;
+if ( _hvm_init_entry(h, CPU_XSAVE_CODE, v->vcpu_id, size) )
+return 1;
+ctxt = (struct hvm_hw_cpu_xsave *)>data[h->cur];
+h->cur += size;
+ctxt->xfeature_mask = xfeature_mask;
+ctxt->xcr0 = v->arch.xcr0;
+ctxt->xcr0_accum = v->arch.xcr0_accum;
 
-hvm_save_cpu_xsave_states_one(v, ctxt);
-expand_xsave_states(v, >save_area,
-size - offsetof(typeof(*ctxt), save_area));
-}
+expand_xsave_states(v, >save_area,
+size - offsetof(typeof(*ctxt), save_area));
 
 return 0;
 }
-- 
2.7.4


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

[Xen-devel] [PATCH v7 01/15] x86/cpu: Introduce vmce_save_vcpu_ctxt_one() func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/cpu/mcheck/vmce.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index e07cd2f..404f27e 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,6 +349,14 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
+static void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
+{
+ctxt->caps = v->arch.vmce.mcg_cap;
+ctxt->mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
+ctxt->mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
+ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
+}
+
 static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -356,13 +364,9 @@ static int vmce_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 
 for_each_vcpu ( d, v )
 {
-struct hvm_vmce_vcpu ctxt = {
-.caps = v->arch.vmce.mcg_cap,
-.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2,
-.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2,
-.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl,
-};
+struct hvm_vmce_vcpu ctxt;
 
+vmce_save_vcpu_ctxt_one(v, );
 err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
 if ( err )
 break;
-- 
2.7.4


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

[Xen-devel] [PATCH v7 08/15] x86/cpu: Remove loop form vmce_save_vcpu_ctxt() func

[Alexandru Isaila]

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/cpu/mcheck/vmce.c | 27 +++
 1 file changed, 7 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 404f27e..ead1f73 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -349,30 +349,17 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 return ret;
 }
 
-static void vmce_save_vcpu_ctxt_one(struct vcpu *v, struct hvm_vmce_vcpu *ctxt)
-{
-ctxt->caps = v->arch.vmce.mcg_cap;
-ctxt->mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
-ctxt->mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
-ctxt->mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
-}
-
 static int vmce_save_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
 {
-struct vcpu *v;
-int err = 0;
-
-for_each_vcpu ( d, v )
-{
-struct hvm_vmce_vcpu ctxt;
+struct hvm_vmce_vcpu ctxt;
+struct vcpu *v = NULL;
 
-vmce_save_vcpu_ctxt_one(v, );
-err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
-if ( err )
-break;
-}
+ctxt.caps = v->arch.vmce.mcg_cap;
+ctxt.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
+ctxt.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
+ctxt.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
 
-return err;
+return hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
 }
 
 static int vmce_load_vcpu_ctxt(struct domain *d, hvm_domain_context_t *h)
-- 
2.7.4


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

[Xen-devel] [PATCH v7 05/15] x86/hvm: Introduce hvm_save_cpu_msrs_one func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 

---
Changes since V5:
- Check the return value of hvm_save_cpu_msrs_one()
---
 xen/arch/x86/hvm/hvm.c | 60 --
 1 file changed, 34 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index e8ecabf..7e90bf2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1354,6 +1354,38 @@ static const uint32_t msrs_to_send[] = {
 };
 static unsigned int __read_mostly msr_count_max = ARRAY_SIZE(msrs_to_send);
 
+static int hvm_save_cpu_msrs_one(struct vcpu *v, struct hvm_msr *ctxt)
+{
+unsigned int i;
+
+for ( i = 0; i < ARRAY_SIZE(msrs_to_send); ++i )
+{
+uint64_t val;
+int rc = guest_rdmsr(v, msrs_to_send[i], );
+
+/*
+ * It is the programmers responsibility to ensure that
+ * msrs_to_send[] contain generally-read/write MSRs.
+ * X86EMUL_EXCEPTION here implies a missing feature, and that the
+ * guest doesn't have access to the MSR.
+ */
+if ( rc == X86EMUL_EXCEPTION )
+continue;
+
+if ( rc != X86EMUL_OKAY )
+{
+ASSERT_UNREACHABLE();
+return -ENXIO;
+}
+
+if ( !val )
+   continue; /* Skip empty MSRs. */
+ctxt->msr[ctxt->count].index = msrs_to_send[i];
+ctxt->msr[ctxt->count++].val = val;
+}
+return 0;
+}
+
 static int hvm_save_cpu_msrs(struct domain *d, hvm_domain_context_t *h)
 {
 struct vcpu *v;
@@ -1370,32 +1402,8 @@ static int hvm_save_cpu_msrs(struct domain *d, 
hvm_domain_context_t *h)
 ctxt = (struct hvm_msr *)>data[h->cur];
 ctxt->count = 0;
 
-for ( i = 0; i < ARRAY_SIZE(msrs_to_send); ++i )
-{
-uint64_t val;
-int rc = guest_rdmsr(v, msrs_to_send[i], );
-
-/*
- * It is the programmers responsibility to ensure that
- * msrs_to_send[] contain generally-read/write MSRs.
- * X86EMUL_EXCEPTION here implies a missing feature, and that the
- * guest doesn't have access to the MSR.
- */
-if ( rc == X86EMUL_EXCEPTION )
-continue;
-
-if ( rc != X86EMUL_OKAY )
-{
-ASSERT_UNREACHABLE();
-return -ENXIO;
-}
-
-if ( !val )
-continue; /* Skip empty MSRs. */
-
-ctxt->msr[ctxt->count].index = msrs_to_send[i];
-ctxt->msr[ctxt->count++].val = val;
-}
+if ( hvm_save_cpu_msrs_one(v, ctxt) == -ENXIO )
+return -ENXIO;
 
 if ( hvm_funcs.save_msr )
 hvm_funcs.save_msr(v, ctxt);
-- 
2.7.4


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

[Xen-devel] [PATCH v7 06/15] x86/hvm: Introduce hvm_save_mtrr_msr_one func

[Alexandru Isaila]

This is used to save data from a single instance.

Signed-off-by: Alexandru Isaila 
---
 xen/arch/x86/hvm/mtrr.c | 52 +++--
 1 file changed, 29 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index b721c63..d311031 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -666,36 +666,42 @@ int hvm_set_mem_pinned_cacheattr(struct domain *d, 
uint64_t gfn_start,
 return 0;
 }
 
-static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
+static void hvm_save_mtrr_msr_one(struct vcpu *v, struct hvm_hw_mtrr *hw_mtrr)
 {
+struct mtrr_state *mtrr_state = >arch.hvm_vcpu.mtrr;
 int i;
-struct vcpu *v;
-struct hvm_hw_mtrr hw_mtrr;
-struct mtrr_state *mtrr_state;
-/* save mtrr */
-for_each_vcpu(d, v)
+
+hvm_get_guest_pat(v, _mtrr->msr_pat_cr);
+
+hw_mtrr->msr_mtrr_def_type = mtrr_state->def_type
+| (mtrr_state->enabled << 10);
+hw_mtrr->msr_mtrr_cap = mtrr_state->mtrr_cap;
+
+for ( i = 0; i < MTRR_VCNT; i++ )
 {
-mtrr_state = >arch.hvm_vcpu.mtrr;
+/* save physbase */
+hw_mtrr->msr_mtrr_var[i*2] =
+((uint64_t*)mtrr_state->var_ranges)[i*2];
+/* save physmask */
+hw_mtrr->msr_mtrr_var[i*2+1] =
+((uint64_t*)mtrr_state->var_ranges)[i*2+1];
+}
 
-hvm_get_guest_pat(v, _mtrr.msr_pat_cr);
+for ( i = 0; i < NUM_FIXED_MSR; i++ )
+hw_mtrr->msr_mtrr_fixed[i] =
+((uint64_t*)mtrr_state->fixed_ranges)[i];
 
-hw_mtrr.msr_mtrr_def_type = mtrr_state->def_type
-| (mtrr_state->enabled << 10);
-hw_mtrr.msr_mtrr_cap = mtrr_state->mtrr_cap;
+}
 
-for ( i = 0; i < MTRR_VCNT; i++ )
-{
-/* save physbase */
-hw_mtrr.msr_mtrr_var[i*2] =
-((uint64_t*)mtrr_state->var_ranges)[i*2];
-/* save physmask */
-hw_mtrr.msr_mtrr_var[i*2+1] =
-((uint64_t*)mtrr_state->var_ranges)[i*2+1];
-}
+static int hvm_save_mtrr_msr(struct domain *d, hvm_domain_context_t *h)
+{
+struct vcpu *v;
+struct hvm_hw_mtrr hw_mtrr;
+/* save mtrr */
 
-for ( i = 0; i < NUM_FIXED_MSR; i++ )
-hw_mtrr.msr_mtrr_fixed[i] =
-((uint64_t*)mtrr_state->fixed_ranges)[i];
+for_each_vcpu(d, v)
+{
+hvm_save_mtrr_msr_one(v, _mtrr);
 
 if ( hvm_save_entry(MTRR, v->vcpu_id, h, _mtrr) != 0 )
 return 1;
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Jan Beulich]

>>> On 07.06.18 at 16:49,  wrote:
> Am Thu, 07 Jun 2018 08:44:41 -0600
> schrieb "Jan Beulich" :
> 
>> The re-use of the field is acceptable only if all existing senders reliably
>> fill zero in there.
> 
> How do we know all senders? I just know about write_tsc_info from xen-4.6+.

I don't think we care about senders other than ones using libxc, so
by knowing whether all libxc versions conform to the requirement,
we could declare we're fine.

Jan



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

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Olaf Hering]

Am Thu, 07 Jun 2018 08:44:41 -0600
schrieb "Jan Beulich" :

> The re-use of the field is acceptable only if all existing senders reliably 
> fill zero in there.

How do we know all senders? I just know about write_tsc_info from xen-4.6+.

Olaf


pgp7WNmQ7W4Jd.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] multiboot2: clarify usage of the address tag

[Roger Pau Monné]

On Wed, Jun 06, 2018 at 07:28:20PM +0200, Daniel Kiper wrote:
> On Tue, Jun 05, 2018 at 11:55:36AM +0200, Roger Pau Monne wrote:
> > Add a note to spell out that if the address tag is not present the
> > file should be loaded using the elf header.
> >
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Daniel Kiper 
> > Cc: xen-devel@lists.xenproject.org
> > ---
> >  doc/multiboot.texi | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/doc/multiboot.texi b/doc/multiboot.texi
> > index 2e2d7e74a..196f9c17a 100644
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -509,6 +509,12 @@ assumes that no bss segment is present.
> >
> >  @end table
> >
> > +Note: This information does not need to be provided if the kernel
> > +image is in elf format, but it must be provided if the image is in
> 
> s/elf/@sc{elf}/
> 
> > +a.out format or in some other format. Compliant boot loaders must be
> > +able to load images that are either in elf format or contain the
> 
> Ditto.
> 
> > +address tag embedded in the Multiboot header.
> 
> s/Multiboot/Multiboot2/
> 
> I think that it is also worth mentioning that the address tag has
> preference over relevant data provided in ELF header.
> 
> Additionally, may I ask you to provide similar patch for Multiboot spec?
> You can find it in multiboot branch. Please look for "The address fields
> of Multiboot header" paragraph.

Multiboot1 already has such paragraph in the "3.1.2 The magic fields
of Multiboot header" section.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Jan Beulich]

>>> On 07.06.18 at 15:47,  wrote:
> Am Thu, 07 Jun 2018 07:31:26 -0600
> schrieb "Jan Beulich" :
> 
>> Hmm, I find this description concerning. Is the field reliably zero when
>> coming from older Xen, or is it not?
> 
> It depends on how old.
> If the other sending side has write_tsc_info from 4.6+, then _res1 is zero.
> If it is older, the XC_SAVE_ID_TSC_INFO is eventually not handled anymore.
> At least I could not find the relevant code, even in staging-4.6.
> But then, it is unlikely that migration from 4.5 to 4.6 did not work.
> 
> Also, in general the input comes from "remote". So it is untrusted.

But isn't this exactly the concern Andrew had voiced? If so, we're not
any closer to this having a chance to go in. The re-use of the field is
acceptable only if all existing senders reliably fill zero in there.

Jan



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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Ian Jackson]

Paul Durrant writes ("RE: [PATCH 5/7] public / x86: introduce 
__HYPERCALL_iommu_op"):
> FWIW Linux appears to use a single '_' prefix and no suffix.

This practice of scattering underscores about, apparently at random,
is baffling to me.

It doesn't look like most of the people who do it are aware of the
rules.  For example, #defining any identifier starting __ is a licence
to the compiler to stuff demons up your nose.

We should do this:
  #define XEN_PUBLIC_IOMMU_OP_H
which is (i) not in any of the compiler's namespaces (ii) has XEN_ at
the beginning so we can justify thinking that it won't clash with
anyone else's identifiers (Iii) will never clash with any of our own
because it ends in _H.

Ian.

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

[Xen-devel] [PATCH 3.16 311/410] x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend

[Ben Hutchings]

3.16.57-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Juergen Gross 

commit 71c208dd54ab971036d83ff6d9837bae4976e623 upstream.

Older Xen versions (4.5 and before) might have problems migrating pv
guests with MSR_IA32_SPEC_CTRL having a non-zero value. So before
suspending zero that MSR and restore it after being resumed.

Signed-off-by: Juergen Gross 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Jan Beulich 
Cc: xen-devel@lists.xenproject.org
Cc: boris.ostrov...@oracle.com
Link: https://lkml.kernel.org/r/20180226140818.4849-1-jgr...@suse.com
[bwh: Backported to 3.16:
 - Include  instead of 
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -1,10 +1,13 @@
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -12,6 +15,8 @@
 #include "xen-ops.h"
 #include "mmu.h"
 
+static DEFINE_PER_CPU(u64, spec_ctrl);
+
 static void xen_pv_pre_suspend(void)
 {
xen_mm_pin_all();
@@ -84,6 +89,9 @@ static void xen_vcpu_notify_restore(void
 {
unsigned long reason = (unsigned long)data;
 
+   if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+   wrmsrl(MSR_IA32_SPEC_CTRL, this_cpu_read(spec_ctrl));
+
/* Boot processor notified via generic timekeeping_resume() */
if ( smp_processor_id() == 0)
return;
@@ -93,6 +101,13 @@ static void xen_vcpu_notify_restore(void
 
 static void xen_vcpu_notify_suspend(void *data)
 {
+   u64 tmp;
+
+   if (xen_pv_domain() && boot_cpu_has(X86_FEATURE_SPEC_CTRL)) {
+   rdmsrl(MSR_IA32_SPEC_CTRL, tmp);
+   this_cpu_write(spec_ctrl, tmp);
+   wrmsrl(MSR_IA32_SPEC_CTRL, 0);
+   }
 }
 
 void xen_arch_resume(void)


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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Paul Durrant]

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 07 June 2018 14:45
> To: Jan Beulich ; Paul Durrant
> 
> Cc: Andrew Cooper ; Ian Jackson
> ; Wei Liu ; Stefano Stabellini
> ; xen-devel ;
> Konrad Rzeszutek Wilk ; Daniel de Graaf
> ; Tim (Xen.org) 
> Subject: Re: [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op
> 
> On 06/07/2018 02:21 PM, Jan Beulich wrote:
>  On 07.06.18 at 13:42,  wrote:
> >>> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> Sent: 16 March 2018 12:25
> >> On 12.02.18 at 11:47,  wrote:
>  --- a/xen/arch/x86/Makefile
>  +++ b/xen/arch/x86/Makefile
>  @@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
>   obj-y += hypercall.o
>   obj-y += i387.o
>   obj-y += i8259.o
>  +obj-y += iommu_op.o
> >>>
> >>> As mentioned in other contexts, I'd prefer if we stopped using
> >>> underscores in places where dashes (or other separators not
> >>> usable in C identifiers) are fine.
> >>
> >> I don't see any guidance in CODING_STYLE or elsewhere, and also the
> majority
> >> of the codebase seems to prefer using underscores in module names.
> Personally
> >> I'd prefer new code remain consistent.
> >
> > The lack of statement to this effect is why I've said "I'd prefer". See
> > alternative-asm.h, x86-defns.h, or x86-vendors.h for _recent_
> > examples of moving into the other direction. On all keyboards I've
> > seen or used, an underscore requires two keys to be pressed, while
> > a dash takes only one. This isn't much for an individual instance, but
> > it sums up. It's the same reason why I'm advocating against the use
> > of underscores in new command line option names.
> >
> > In the end, looking at the history of typography, I think underscore
> > is a relatively late (and presumably artificial) addition; in particular I
> > don't recall mechanical type writers to even have a key for it.
> 
> The mechanical typewriters I learned on had an underscore to
> allow you to go back and underline words.
> 
> > It's
> > use as a visual separator is necessary in e.g. programming
> > languages, as commonly dash designated the operator for "minus"
> > there. Extending such naming to non-identifiers (file system names
> > and command line options are just prominent examples) is simply
> > misguided imo.
> 
> Well in any case, maybe this should be discussed in a patch to
> CODING_STYLE, rather than in the middle of a patch series about
> something completely different.
> 
>  +#ifndef __XEN_PUBLIC_IOMMU_OP_H__
>  +#define __XEN_PUBLIC_IOMMU_OP_H__
> >>>
> >>> Please can you avoid introducing further name space violations
> >>> into the public headers?
> >>
> >> I assume you mean the leading '__'? Again, I chose the name based on
> >> consistency with other code and I'd prefer to remain consistent. Could
> you
> >> explain why having a leading '__' is problematic?
> >
> > Names starting with double underscores are reserved (as are, btw,
> > names starting with a single underscore and an upper case letter).
> > While it's unlikely for a compiler to ever want to use
> > __XEN_PUBLIC_IOMMU_OP_H__ for its internal purposes, we couldn't
> > validly complain if one did.
> 
> I'm with Jan on this one.  At the moment I'm not sure about using dashes
> instead of underscores for filenames, but in this case the extra
> underscores at the beginning and end are redundant; the "XEN_..._H" is
> sufficient to make the contents unique.
> 

FWIW Linux appears to use a single '_' prefix and no suffix.

  Paul

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

Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning

[Juergen Gross]

On 07/06/18 13:23, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper
>> Sent: 07 June 2018 11:28
>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>> linux-ker...@vger.kernel.org
>> Cc: Juergen Gross ; Boris Ostrovsky
>> ; Dan Carpenter
>> 
>> Subject: Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning
>>
>> On 07/06/18 11:21, Paul Durrant wrote:
>>> Commit 3ad0876554ca ("xen/privcmd: add
>> IOCTL_PRIVCMD_MMAP_RESOURCE")
>>> introduced a static checker warning:
>>>
>>>   drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource()
>>>   warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()'
>>> 64 vs 32.
>>>
>>> caused by this cast:
>>>
>>>827  num = xen_remap_domain_mfn_array(vma,
>>>828   kdata.addr & PAGE_MASK,
>>>829   pfns, kdata.num, (int *)pfns,
>>>   ^^^
>>>
>>> The reason for the cast is that xen_remap_domain_mfn_array() requires
>> an
>>> array of ints to store error codes. It is actually safe to re-use the
>>> pfns array for this purpose but it does look odd (as well as leading to
>>> the warning). It would also be easy for a future implementation change
>>> to make this re-use unsafe so this patch modifies privcmd to use a
>>> separately allocated array for error codes.
>>>
>>> Reported-by: Dan Carpenter 
>>> Signed-off-by: Paul Durrant 
>>
>> It may be safe to reuse pfns[] as the storage space for the errs array,
>> but code is incorrect when sizeof(pfn) != sizeof(int).  In such a case,
>> you skip over every other err, and second half of pfns[] is junk from
>> the point of view of the errs loop.
>>
> 
> Yep, that is indeed what happens without this patch.

Can you please update the commit message accordingly?


Juergen

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

Re: [Xen-devel] [PATCH 1/3] xen/kbdif: Move multi-touch device parameters to backend nodes

[Juergen Gross]

On 07/06/18 15:29, Konrad Rzeszutek Wilk wrote:
> On Wed, May 23, 2018 at 09:19:21AM +0300, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko 
>>
>> In current kbdif protocol definition multi-touch device parameters
>> are described as a part of frontend's XenBus configuration nodes while
>> they belong to backend's configuration. Fix this by moving
>> the parameters to the proper section.
>>
>> Fixes: b7a3ce49d528 ("xen/kbdif: add multi-touch support")
>>
>> Signed-off-by: Oleksandr Andrushchenko 
>> Reported-by: Oleksandr Grytsov 
>> Reviewed-by: Oleksandr Grytsov 
> 
> Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Juergen, you OK if I check this in?

Looking at the changes tehy seem to be low risk. ;-)

Release-acked-by: Juergen Gross 


Juergen

> 
>> ---
>>  xen/include/public/io/kbdif.h | 38 +--
>>  1 file changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
>> index 23d1f70d5210..a68da0f1a37f 100644
>> --- a/xen/include/public/io/kbdif.h
>> +++ b/xen/include/public/io/kbdif.h
>> @@ -96,6 +96,25 @@
>>   *  Maximum Y coordinate (height) to be used by the frontend
>>   *  while reporting input events, pixels, [0; UINT32_MAX].
>>   *
>> + *--- Multi-touch Device Parameters 
>> --
>> + *
>> + * multi-touch-num-contacts
>> + *  Values: 
>> + *
>> + *  Number of simultaneous touches reported.
>> + *
>> + * multi-touch-width
>> + *  Values: 
>> + *
>> + *  Width of the touch area to be used by the frontend
>> + *  while reporting input events, pixels, [0; UINT32_MAX].
>> + *
>> + * multi-touch-height
>> + *  Values: 
>> + *
>> + *  Height of the touch area to be used by the frontend
>> + *  while reporting input events, pixels, [0; UINT32_MAX].
>> + *
>>   
>> *
>>   *Frontend XenBus Nodes
>>   
>> *
>> @@ -143,25 +162,6 @@
>>   *
>>   *  OBSOLETE, not recommended for use.
>>   *  PFN of the shared page.
>> - *
>> - *--- Multi-touch Device Parameters 
>> ---
>> - *
>> - * multi-touch-num-contacts
>> - *  Values: 
>> - *
>> - *  Number of simultaneous touches reported.
>> - *
>> - * multi-touch-width
>> - *  Values: 
>> - *
>> - *  Width of the touch area to be used by the frontend
>> - *  while reporting input events, pixels, [0; UINT32_MAX].
>> - *
>> - * multi-touch-height
>> - *  Values: 
>> - *
>> - *  Height of the touch area to be used by the frontend
>> - *  while reporting input events, pixels, [0; UINT32_MAX].
>>   */
>>  
>>  /*
>> -- 
>> 2.17.0
>>
> 


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

[Xen-devel] [PATCH] CODING_STYLE: discourage use of underscores where alternatives exist

[Jan Beulich]

Underscores commonly require two keypresses while hyphen / dash requires
just one, and the visual separation effect of both is basically the same.

Signed-off-by: Jan Beulich 

--- a/CODING_STYLE  2017-08-09 14:07:41.565057836 +0200
+++ b/CODING_STYLE  2018-06-07 15:52:55.136611092 +0200
@@ -106,6 +106,15 @@ separate lines and each line should begi
  * Note beginning and end markers on separate lines and leading '*'.
  */
 
+Choice of names
+---
+
+While for identifiers underscores are unavoidable when a visual
+separator beween name components is wanted, in other cases, where a
+wider set of non-alphanumeric characters can be chosen from, the use
+of underscores is discouraged.  For example, for file names and
+command line options a hyphen / dash is commonly easier to type.
+
 Emacs local variables
 -
 



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

Re: [Xen-devel] [RFC] OVMF NVRAM Variable Retention

[aaron . young]

On 06/07/18 01:59, Ross Lagerwall wrote:

On 06/06/2018 04:01 PM, aaron.yo...@oracle.com wrote:


   Hello all,

   I have been tasked with the issue of UEFI NVRAM variable retention 
with Xen HVM/OVMF based guests and wanted to consult the experts 
before I undertake any significant coding effort. I am new to Xen so 
any help/direction would be appreciated.


   What I hope to gain from this RFC inquiry is the following:

   1. Has there been any significant past discussion regarding this 
issue? If so, can somebody kindly point me to these discussion(s) 
and/or give me an overview of the findings?


   2. Is there any current coding effort going on in this area?


Yes! I'm working on this at the moment.


Great! I'm glad I asked before starting implementation.





   3. Any suggestions or proposals on how to fix the issue including 
any issues or caveats that I should be aware of?



Issue details:

  In a nutshell, if a Xen guest which has been configured to use OVMF 
is destroyed and re-created, the UEFI NVRAM variables are not 
retained. This seems to be a well-known issue to which there is no 
resolution. The issue seems to center around the fact that these Xen 
guests are not configured to use a file-backed backing store for the 
NVRAM variables (such as is commonly used with QEMU/KVM guests).


  This issue can cause OVMF OS boot option(s) to be lost preventing 
the ability to boot the OS after a guest is destroyed/re-created. It 
also has implications on secure boot (which require NVRAM variables 
to be retained).



Some key observations:

  1. OVMF currently supports memory-mapped, file-backed 'pflash' 
devices from Qemu. i.e. Qemu can map varstore files into memory for 
use by OVMF via -drive parameters such as:


   -drive if=pflash,format=raw,readonly,file=OVMF_CODE.fd \
   -drive if=pflash,format=raw,file=OVMF_VARS.fd

 OVMF scans the flash device (i.e. the Non-volatile data storage 
FV) for a mapped varstore and if found will use it store NVRAM 
variables (via its QemuFlashFvbServicesRuntimeDxe driver)


 This is outlined well in the OVMF whitepaper 
(http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt)


  2. When Xen HVM/OVMF guests are created, the qemu process that is 
executed (from xl) does not contain these -drive arguments. Thus qemu 
does not map a varstore for use by OVMF causing OVMF to fallback and 
use a simple memory buffer for NVRAM variables (if I'm not mistaken 
here). This causes the variables to not be retained across 
destroy/create operations on the VM.


  3. Unlike qemu/kvm guests where both OVMF and the varstore file are 
loaded/mapped into memory and executed directly by qemu, Xen appears 
to only use qemu as a "device model" and OVMF is not mapped/loaded 
directly by qemu. Instead, under Xen, OVMF is loaded indirectly by 
hvmloader (which is loaded by qemu). This could complicate the fix 
idea below.



Possible idea for fix:

Since OVMF currently has support for QEMU mapped varstore files, 
it seems the most straightforward way to fix this issue would be for 
Xen (i.e. xl) to pass a -drive argument to qemu to specify a varstore 
file and to enhance the Xen memory init code in qemu (i.e. 
xen_hvm.c:xen_[hvm|ram]_init()) to map this file into memory for use 
by OVMF (possibly taking advantage of the already present qemu code 
to do such a mapping (i.e. code out of pc_memory_init()). As 
mentioned above, this would have to (somehow) be compatible with how 
OVMF is loaded indirectly by hvmloader.


   Any comments/suggestions/opinions/caveats on this approach?


I did this a while back. It is easy enough to do:

1) Have Xen load OVMF_code.fd rather than the combined blob.

2) Tweak the location in guest memory where hvmloader loads the blob.

3) Tweak QEMU to load the OVMF_vars.fd blob at the correct location.

4) Start QEMU with emulated flash for OVMF_vars.fd only.

Tweaking the locations ensures that the various parts of OVMF are at 
the location it expects. If you want, I could probably dig up some 
patches (hacks) which do this.


Yes, this is the _exact_ solution I had in mind.

I would very much like to see your patches so I can see how you did 
it (which would assist me in learning the code). If you wouldn't mind, 
could please send the patches to me privately? I'd greatly appreciate 
it. Thanks!!






   Or any other suggested approaches on how to fix this issue?


However... I did not like this approach for two reasons:

1) Having an emulated flash blob is difficult to manage outside of the 
guest (i.e. populating initial state, updating variables if needed). 
For XenServer, we want more flexibility.


2) While Secure Boot can be enabled with this implementation, it is 
not sufficiently secure because the guest is able to write anything it 
wants to the emulated flash. KVM solved this problem with SMM mode but 
I don't like that solution either.


So I am busy implementing:

A UEFI driver frontend which 

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[George Dunlap]

On 06/07/2018 02:21 PM, Jan Beulich wrote:
 On 07.06.18 at 13:42,  wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: 16 March 2018 12:25
>> On 12.02.18 at 11:47,  wrote:
 --- a/xen/arch/x86/Makefile
 +++ b/xen/arch/x86/Makefile
 @@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
  obj-y += hypercall.o
  obj-y += i387.o
  obj-y += i8259.o
 +obj-y += iommu_op.o
>>>
>>> As mentioned in other contexts, I'd prefer if we stopped using
>>> underscores in places where dashes (or other separators not
>>> usable in C identifiers) are fine.
>>
>> I don't see any guidance in CODING_STYLE or elsewhere, and also the majority 
>> of the codebase seems to prefer using underscores in module names. 
>> Personally 
>> I'd prefer new code remain consistent.
> 
> The lack of statement to this effect is why I've said "I'd prefer". See
> alternative-asm.h, x86-defns.h, or x86-vendors.h for _recent_
> examples of moving into the other direction. On all keyboards I've
> seen or used, an underscore requires two keys to be pressed, while
> a dash takes only one. This isn't much for an individual instance, but
> it sums up. It's the same reason why I'm advocating against the use
> of underscores in new command line option names.
> 
> In the end, looking at the history of typography, I think underscore
> is a relatively late (and presumably artificial) addition; in particular I
> don't recall mechanical type writers to even have a key for it.

The mechanical typewriters I learned on had an underscore to
allow you to go back and underline words.

> It's
> use as a visual separator is necessary in e.g. programming
> languages, as commonly dash designated the operator for "minus"
> there. Extending such naming to non-identifiers (file system names
> and command line options are just prominent examples) is simply
> misguided imo.

Well in any case, maybe this should be discussed in a patch to
CODING_STYLE, rather than in the middle of a patch series about
something completely different.

 +#ifndef __XEN_PUBLIC_IOMMU_OP_H__
 +#define __XEN_PUBLIC_IOMMU_OP_H__
>>>
>>> Please can you avoid introducing further name space violations
>>> into the public headers?
>>
>> I assume you mean the leading '__'? Again, I chose the name based on 
>> consistency with other code and I'd prefer to remain consistent. Could you 
>> explain why having a leading '__' is problematic?
> 
> Names starting with double underscores are reserved (as are, btw,
> names starting with a single underscore and an upper case letter).
> While it's unlikely for a compiler to ever want to use
> __XEN_PUBLIC_IOMMU_OP_H__ for its internal purposes, we couldn't
> validly complain if one did.

I'm with Jan on this one.  At the moment I'm not sure about using dashes
instead of underscores for filenames, but in this case the extra
underscores at the beginning and end are redundant; the "XEN_..._H" is
sufficient to make the contents unique.

 -George

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

Re: [Xen-devel] [PATCH 3/3] xen/displif: Add unique display connector identifier

[Oleksandr Andrushchenko]

On 06/07/2018 04:29 PM, Konrad Rzeszutek Wilk wrote:

On Wed, May 23, 2018 at 09:19:23AM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

If frontend is configured to expose multiple connectors then backend may
require a way to uniquely identify concrete virtual connector within the
frontend. This is useful for use-cases where connector needs to be
matched to physical display connector.
Add XenBus "unique-id" node parameter, so this sort of use-cases can
be implemented.

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

diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
index 8a94f1f9b9d0..78158f739cf5 100644
--- a/xen/include/public/io/displif.h
+++ b/xen/include/public/io/displif.h
@@ -189,6 +189,13 @@
   *
   *- Connector settings 

   *
+ * unique-id
+ *  Values: 

Ditto, perhaps an string instead?

Ditto ;)
String is way better, but we have to decide if we want to be consistent 
with sndif

+ *
+ *  After device instance initialization each connector is assigned a
+ *  unique ID (within the front driver), so it can be identified by the
+ *  backend by this ID.
+ *
   * resolution
   *  Values: x
   *
@@ -368,6 +375,7 @@
  #define XENDISPL_FIELD_EVT_CHANNEL"evt-event-channel"
  #define XENDISPL_FIELD_RESOLUTION "resolution"
  #define XENDISPL_FIELD_BE_ALLOC   "be-alloc"
+#define XENDISPL_FIELD_UNIQUE_ID  "unique-id"
  
  /*

   
**
--
2.17.0


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



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

Re: [Xen-devel] [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Oleksandr Andrushchenko]

On 06/07/2018 04:28 PM, Konrad Rzeszutek Wilk wrote:

On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

If frontend is configured to expose multiple input device instances
then backend may require a way to uniquely identify concrete input
device within the frontend. This is useful for use-cases where
virtual input device needs to be matched to physical input device.
Add XenBus "unique-id" node parameter, so this sort of use-cases can
be implemented.

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

diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
index a68da0f1a37f..45e4ff5b0a05 100644
--- a/xen/include/public/io/kbdif.h
+++ b/xen/include/public/io/kbdif.h
@@ -82,6 +82,15 @@
   *  for pointer devices should set this to 1. Raw (unscaled) values have
   *  a range of [0, 0x7fff].
   *
+ *---  Device Instance Parameters 
+ *
+ * unique-id
+ *  Values: 

Wouldn't a string be easier? That way you can extend this in the future
to also have an UUID or so?

Much easier. We were thinking about that as well, but sndif already has it
as uint32_t. If you are ok to change uniquie-id for sndif to string then 
that

would be much better: UUID as you mention + all protocols have unique-id
consistently defined as string.
sndif's unique-id is not used by the frontend driver and we are about
to start libx/xl support for sound, so I think this is the right time for
such a change.
If you are fine with that then I'll send yet another patch for sndif.

+ *
+ *  After device instance initialization it is assigned a unique ID
+ *  (within the front driver), so every instance of the frontend can be
+ *  identified by the backend by this ID.
+ *
   *- Pointer Device Parameters 
   *
   * width
@@ -204,6 +213,7 @@
  #define XENKBD_FIELD_MT_WIDTH  "multi-touch-width"
  #define XENKBD_FIELD_MT_HEIGHT "multi-touch-height"
  #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
+#define XENKBD_FIELD_UNIQUE_ID "unique-id"
  
  /* OBSOLETE, not recommended for use */

  #define XENKBD_FIELD_RING_REF  "page-ref"
--
2.17.0




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

[Xen-devel] [linux-next test] 123847: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-shadow   10 debian-install   fail REGR. vs. 123792
 test-amd64-amd64-xl  10 debian-install   fail REGR. vs. 123792
 test-amd64-amd64-xl-credit2  10 debian-install   fail REGR. vs. 123792
 test-amd64-amd64-xl-xsm  10 debian-install   fail REGR. vs. 123792
 test-amd64-i386-xl   10 debian-install   fail REGR. vs. 123792
 test-amd64-i386-qemut-rhel6hvm-intel 10 redhat-install   fail REGR. vs. 123792
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 123792
 test-amd64-i386-freebsd10-amd64 10 freebsd-install   fail REGR. vs. 123792
 test-amd64-i386-freebsd10-i386 10 freebsd-installfail REGR. vs. 123792
 test-amd64-amd64-pair16 debian-install/dst_host  fail REGR. vs. 123792
 test-amd64-amd64-libvirt 10 debian-install   fail REGR. vs. 123792
 test-amd64-i386-qemut-rhel6hvm-amd 10 redhat-install fail REGR. vs. 123792
 test-amd64-amd64-libvirt-xsm 10 debian-install   fail REGR. vs. 123792
 test-amd64-amd64-xl-pvhv2-amd 10 debian-install  fail REGR. vs. 123792
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 123792
 test-amd64-amd64-xl-qemut-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
123792
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 10 debian-hvm-install fail REGR. vs. 
123792
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
REGR. vs. 123792
 test-amd64-amd64-amd64-pvgrub 16 guest-saverestore.2 fail REGR. vs. 123792
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 123792
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-saverestore.2 
fail REGR. vs. 123792
 test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 123792
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install  fail REGR. vs. 123792
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-saverestore.2 fail REGR. 
vs. 123792
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 10 debian-hvm-install fail 
REGR. vs. 123792
 test-amd64-i386-xl-raw   10 debian-di-installfail REGR. vs. 123792
 test-amd64-i386-xl-qemuu-win7-amd64 10 windows-install   fail REGR. vs. 123792
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-install  fail REGR. vs. 123792
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 123792
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 123792
 test-armhf-armhf-xl-xsm   7 xen-boot fail REGR. vs. 123792
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 123792
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 123792
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 123792
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 123792
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install   fail REGR. vs. 123792
 test-armhf-armhf-xl-cubietruck  7 xen-boot   fail REGR. vs. 123792
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 123792
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 123792
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 123792
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 123792
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 123792
 test-amd64-amd64-xl-qemuu-win7-amd64 10 windows-install  fail REGR. vs. 123792

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 10 debian-install   fail REGR. vs. 123792
 test-armhf-armhf-xl-rtds  7 xen-boot fail REGR. vs. 123792

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  10 debian-install  fail blocked in 123792
 test-amd64-i386-libvirt  10 debian-install  fail blocked in 123792
 test-amd64-i386-libvirt-pair 16 debian-install/dst_host fail blocked in 123792
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail 
blocked in 123792
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123792
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   

Re: [Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Jan Beulich]

>>> On 07.06.18 at 15:08,  wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.
> 
> One option to avoid the TSC option is to run domUs with tsc_mode=native.
> This has the drawback that migrating a domU from a "2.3GHz" class host
> to a "2.4GHz" class host may change the rate at wich the TSC counter
> increases, the domU may not be prepared for that.
> 
> With the new option the host admin can decide how a domU should behave
> when it is migrated across systems of the same class. Since there is
> always some jitter when Xen calibrates the cpu_khz value, all hosts of
> the same class will most likely have slightly different values. As a
> result vTSC emulation is unavoidable. Data collected during the incident
> which triggered this change showed a jitter of up to 200 KHz across
> systems of the same class.
> 
> Existing padding fields are reused to store vtsc_khz_tolerance as u16.
> The padding is sent as zero in write_tsc_info to the receving host.
> The padding is undefined if the changed code runs as receiver.
> handle_tsc_info has no code to verify that padding is indeed zero. Due
> to the lack of a version field it is impossible to know if the sender
> already has the newly introduced vtsc_tolerance field. In the worst
> case the receiving domU will get an unemulated TSC.

Hmm, I find this description concerning. Is the field reliably zero when
coming from older Xen, or is it not?

> Signed-off-by: Olaf Hering 
> Reviewed-by: Wei Liu  (v07/v08)
> Reviewed-by: Jan Beulich  (v08)

To avoid this getting committed prematurely: I gave this R-b pending
Andrew finding his prior concerns addressed.

Jan



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

Re: [Xen-devel] [PATCH 1/3] xen/kbdif: Move multi-touch device parameters to backend nodes

[Konrad Rzeszutek Wilk]

On Wed, May 23, 2018 at 09:19:21AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> In current kbdif protocol definition multi-touch device parameters
> are described as a part of frontend's XenBus configuration nodes while
> they belong to backend's configuration. Fix this by moving
> the parameters to the proper section.
> 
> Fixes: b7a3ce49d528 ("xen/kbdif: add multi-touch support")
> 
> Signed-off-by: Oleksandr Andrushchenko 
> Reported-by: Oleksandr Grytsov 
> Reviewed-by: Oleksandr Grytsov 

Reviewed-by: Konrad Rzeszutek Wilk 

Juergen, you OK if I check this in?

> ---
>  xen/include/public/io/kbdif.h | 38 +--
>  1 file changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index 23d1f70d5210..a68da0f1a37f 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -96,6 +96,25 @@
>   *  Maximum Y coordinate (height) to be used by the frontend
>   *  while reporting input events, pixels, [0; UINT32_MAX].
>   *
> + *--- Multi-touch Device Parameters 
> --
> + *
> + * multi-touch-num-contacts
> + *  Values: 
> + *
> + *  Number of simultaneous touches reported.
> + *
> + * multi-touch-width
> + *  Values: 
> + *
> + *  Width of the touch area to be used by the frontend
> + *  while reporting input events, pixels, [0; UINT32_MAX].
> + *
> + * multi-touch-height
> + *  Values: 
> + *
> + *  Height of the touch area to be used by the frontend
> + *  while reporting input events, pixels, [0; UINT32_MAX].
> + *
>   
> *
>   *Frontend XenBus Nodes
>   
> *
> @@ -143,25 +162,6 @@
>   *
>   *  OBSOLETE, not recommended for use.
>   *  PFN of the shared page.
> - *
> - *--- Multi-touch Device Parameters 
> ---
> - *
> - * multi-touch-num-contacts
> - *  Values: 
> - *
> - *  Number of simultaneous touches reported.
> - *
> - * multi-touch-width
> - *  Values: 
> - *
> - *  Width of the touch area to be used by the frontend
> - *  while reporting input events, pixels, [0; UINT32_MAX].
> - *
> - * multi-touch-height
> - *  Values: 
> - *
> - *  Height of the touch area to be used by the frontend
> - *  while reporting input events, pixels, [0; UINT32_MAX].
>   */
>  
>  /*
> -- 
> 2.17.0
> 

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

Re: [Xen-devel] [PATCH 3/3] xen/displif: Add unique display connector identifier

[Konrad Rzeszutek Wilk]

On Wed, May 23, 2018 at 09:19:23AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> If frontend is configured to expose multiple connectors then backend may
> require a way to uniquely identify concrete virtual connector within the
> frontend. This is useful for use-cases where connector needs to be
> matched to physical display connector.
> Add XenBus "unique-id" node parameter, so this sort of use-cases can
> be implemented.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/include/public/io/displif.h | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h
> index 8a94f1f9b9d0..78158f739cf5 100644
> --- a/xen/include/public/io/displif.h
> +++ b/xen/include/public/io/displif.h
> @@ -189,6 +189,13 @@
>   *
>   *- Connector settings 
> 
>   *
> + * unique-id
> + *  Values: 

Ditto, perhaps an string instead?
> + *
> + *  After device instance initialization each connector is assigned a
> + *  unique ID (within the front driver), so it can be identified by the
> + *  backend by this ID.
> + *
>   * resolution
>   *  Values: x
>   *
> @@ -368,6 +375,7 @@
>  #define XENDISPL_FIELD_EVT_CHANNEL"evt-event-channel"
>  #define XENDISPL_FIELD_RESOLUTION "resolution"
>  #define XENDISPL_FIELD_BE_ALLOC   "be-alloc"
> +#define XENDISPL_FIELD_UNIQUE_ID  "unique-id"
>  
>  /*
>   
> **
> -- 
> 2.17.0
> 

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

Re: [Xen-devel] [PATCH 2/3] xen/kbdif: Add unique input device identifier

[Konrad Rzeszutek Wilk]

On Wed, May 23, 2018 at 09:19:22AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko 
> 
> If frontend is configured to expose multiple input device instances
> then backend may require a way to uniquely identify concrete input
> device within the frontend. This is useful for use-cases where
> virtual input device needs to be matched to physical input device.
> Add XenBus "unique-id" node parameter, so this sort of use-cases can
> be implemented.
> 
> Signed-off-by: Oleksandr Andrushchenko 
> ---
>  xen/include/public/io/kbdif.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/xen/include/public/io/kbdif.h b/xen/include/public/io/kbdif.h
> index a68da0f1a37f..45e4ff5b0a05 100644
> --- a/xen/include/public/io/kbdif.h
> +++ b/xen/include/public/io/kbdif.h
> @@ -82,6 +82,15 @@
>   *  for pointer devices should set this to 1. Raw (unscaled) values have
>   *  a range of [0, 0x7fff].
>   *
> + *---  Device Instance Parameters 
> 
> + *
> + * unique-id
> + *  Values: 

Wouldn't a string be easier? That way you can extend this in the future
to also have an UUID or so?

> + *
> + *  After device instance initialization it is assigned a unique ID
> + *  (within the front driver), so every instance of the frontend can be
> + *  identified by the backend by this ID.
> + *
>   *- Pointer Device Parameters 
> 
>   *
>   * width
> @@ -204,6 +213,7 @@
>  #define XENKBD_FIELD_MT_WIDTH  "multi-touch-width"
>  #define XENKBD_FIELD_MT_HEIGHT "multi-touch-height"
>  #define XENKBD_FIELD_MT_NUM_CONTACTS   "multi-touch-num-contacts"
> +#define XENKBD_FIELD_UNIQUE_ID "unique-id"
>  
>  /* OBSOLETE, not recommended for use */
>  #define XENKBD_FIELD_RING_REF  "page-ref"
> -- 
> 2.17.0
> 

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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Jan Beulich]

>>> On 07.06.18 at 13:42,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 16 March 2018 12:25
>> >>> On 12.02.18 at 11:47,  wrote:
>> > --- a/xen/arch/x86/Makefile
>> > +++ b/xen/arch/x86/Makefile
>> > @@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
>> >  obj-y += hypercall.o
>> >  obj-y += i387.o
>> >  obj-y += i8259.o
>> > +obj-y += iommu_op.o
>> 
>> As mentioned in other contexts, I'd prefer if we stopped using
>> underscores in places where dashes (or other separators not
>> usable in C identifiers) are fine.
> 
> I don't see any guidance in CODING_STYLE or elsewhere, and also the majority 
> of the codebase seems to prefer using underscores in module names. Personally 
> I'd prefer new code remain consistent.

The lack of statement to this effect is why I've said "I'd prefer". See
alternative-asm.h, x86-defns.h, or x86-vendors.h for _recent_
examples of moving into the other direction. On all keyboards I've
seen or used, an underscore requires two keys to be pressed, while
a dash takes only one. This isn't much for an individual instance, but
it sums up. It's the same reason why I'm advocating against the use
of underscores in new command line option names.

In the end, looking at the history of typography, I think underscore
is a relatively late (and presumably artificial) addition; in particular I
don't recall mechanical type writers to even have a key for it. It's
use as a visual separator is necessary in e.g. programming
languages, as commonly dash designated the operator for "minus"
there. Extending such naming to non-identifiers (file system names
and command line options are just prominent examples) is simply
misguided imo.

>> > --- /dev/null
>> > +++ b/xen/include/public/iommu_op.h
>> > @@ -0,0 +1,55 @@
>> > +/*
>> > + * Permission is hereby granted, free of charge, to any person obtaining a
>> copy
>> > + * of this software and associated documentation files (the "Software"),
>> to
>> > + * deal in the Software without restriction, including without limitation 
>> > the
>> > + * rights to use, copy, modify, merge, publish, distribute, sublicense,
>> and/or
>> > + * sell copies of the Software, and to permit persons to whom the
>> Software is
>> > + * furnished to do so, subject to the following conditions:
>> > + *
>> > + * The above copyright notice and this permission notice shall be included
>> in
>> > + * all copies or substantial portions of the Software.
>> > + *
>> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
>> KIND, EXPRESS OR
>> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
>> MERCHANTABILITY,
>> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
>> EVENT SHALL THE
>> > + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
>> DAMAGES OR OTHER
>> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>> OTHERWISE, ARISING
>> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
>> OR OTHER
>> > + * DEALINGS IN THE SOFTWARE.
>> > + *
>> > + * Copyright (C) 2018 Citrix Systems Inc
>> > + */
>> > +
>> > +#ifndef __XEN_PUBLIC_IOMMU_OP_H__
>> > +#define __XEN_PUBLIC_IOMMU_OP_H__
>> 
>> Please can you avoid introducing further name space violations
>> into the public headers?
> 
> I assume you mean the leading '__'? Again, I chose the name based on 
> consistency with other code and I'd prefer to remain consistent. Could you 
> explain why having a leading '__' is problematic?

Names starting with double underscores are reserved (as are, btw,
names starting with a single underscore and an upper case letter).
While it's unlikely for a compiler to ever want to use
__XEN_PUBLIC_IOMMU_OP_H__ for its internal purposes, we couldn't
validly complain if one did.

Jan



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

[Xen-devel] [PATCH v9] new config option vtsc_tolerance_khz to avoid TSC emulation

[Olaf Hering]

Add an option to control when vTSC emulation will be activated for a
domU with tsc_mode=default. Without such option each TSC access from
domU will be emulated, which causes a significant perfomance drop for
workloads that make use of rdtsc.

One option to avoid the TSC option is to run domUs with tsc_mode=native.
This has the drawback that migrating a domU from a "2.3GHz" class host
to a "2.4GHz" class host may change the rate at wich the TSC counter
increases, the domU may not be prepared for that.

With the new option the host admin can decide how a domU should behave
when it is migrated across systems of the same class. Since there is
always some jitter when Xen calibrates the cpu_khz value, all hosts of
the same class will most likely have slightly different values. As a
result vTSC emulation is unavoidable. Data collected during the incident
which triggered this change showed a jitter of up to 200 KHz across
systems of the same class.

Existing padding fields are reused to store vtsc_khz_tolerance as u16.
The padding is sent as zero in write_tsc_info to the receving host.
The padding is undefined if the changed code runs as receiver.
handle_tsc_info has no code to verify that padding is indeed zero. Due
to the lack of a version field it is impossible to know if the sender
already has the newly introduced vtsc_tolerance field. In the worst
case the receiving domU will get an unemulated TSC.

Signed-off-by: Olaf Hering 
Reviewed-by: Wei Liu  (v07/v08)
Reviewed-by: Jan Beulich  (v08)
--

v9:
 - extend commit msg, mention potential issues with xc_sr_rec_tsc_info._res1
v8:
 - adjust also python stream checker for added tolerance member
v7:
 - use uint16 in libxl_types.idl to match type used elsewhere in the patch
v6:
 - mention default value in xl.cfg
 - tsc_set_info: remove usage of __func__, use %d for domid
 - tsc_set_info: use ABS to calculate khz_diff
v5:
 - reduce functionality to allow setting of the tolerance value
   only at initial domU startup
v4:
 - add missing copyback in XEN_DOMCTL_set_vtsc_tolerance_khz
v3:
 - rename vtsc_khz_tolerance to vtsc_tolerance_khz
 - separate domctls to adjust values
 - more docs
 - update libxl.h
 - update python tests
 - flask check bound to tsc permissions
 - not runtime tested due to dlsym() build errors in staging
---
 docs/man/xen-tscmode.pod.7   | 16 +
 docs/man/xl.cfg.pod.5.in | 10 
 docs/specs/libxc-migration-stream.pandoc |  6 +++--
 tools/libxc/include/xenctrl.h|  2 ++
 tools/libxc/xc_domain.c  |  4 
 tools/libxc/xc_sr_common_x86.c   |  6 +++--
 tools/libxc/xc_sr_stream_format.h|  3 ++-
 tools/libxl/libxl.h  |  6 +
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/libxl_x86.c  |  3 ++-
 tools/python/xen/lowlevel/xc/xc.c|  2 +-
 tools/python/xen/migration/libxc.py  |  8 +++
 tools/xl/xl_parse.c  |  3 +++
 xen/arch/x86/domain.c|  2 +-
 xen/arch/x86/domctl.c|  2 ++
 xen/arch/x86/time.c  | 30 +---
 xen/include/asm-x86/domain.h |  1 +
 xen/include/asm-x86/time.h   |  6 +++--
 xen/include/public/domctl.h  |  3 ++-
 19 files changed, 96 insertions(+), 18 deletions(-)

diff --git a/docs/man/xen-tscmode.pod.7 b/docs/man/xen-tscmode.pod.7
index 3bbc96f201..122ae36679 100644
--- a/docs/man/xen-tscmode.pod.7
+++ b/docs/man/xen-tscmode.pod.7
@@ -99,6 +99,9 @@ whether or not the VM has been saved/restored/migrated
 
 =back
 
+If the tsc_mode is set to "default" the decision to emulate TSC can be
+tweaked further with the "vtsc_tolerance_khz" option.
+
 To understand this in more detail, the rest of this document must
 be read.
 
@@ -211,6 +214,19 @@ is emulated.  Note that, though emulated, the "apparent" 
TSC frequency
 will be the TSC frequency of the initial physical machine, even after
 migration.
 
+Since the calibration of the TSC frequency may not be 100% accurate, the
+exact value of the frequency can change even across reboots. This means
+also several otherwise identical systems can have a slightly different
+TSC frequency. As a result TSC access will be emulated if a domU is
+migrated from one host to another, identical host. To avoid the
+performance impact of TSC emulation a certain tolerance of the measured
+host TSC frequency can be specified with "vtsc_tolerance_khz". If the
+measured "cpu_khz" value is within the tolerance range, TSC access
+remains native. Otherwise it will be emulated. This allows to migrate
+domUs between identical hardware. If the domU will be migrated to a
+different kind of hardware, say from a "2.3GHz" to a "2.5GHz" system,
+TSC will be emualted to maintain the TSC frequency expected by the domU.
+
 For environments where both TSC-safeness AND highest performance
 even across migration is a requirement, application code can be 

Re: [Xen-devel] [xen-unstable test] 123831: trouble: broken/fail/pass

[Juergen Gross]

On 07/06/18 13:58, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 123831: trouble: 
> broken/fail/pass"):
>> Are you fine then to lift the current commit moratorium?
> 
> That seems sensible, if you don't expect to be trying to branch RSN
> because of the save/restore bug.

Okay, committers, you can commit release-acked patches again.


Juergen

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

[Xen-devel] [OSSTEST PATCH] sg-report-flight: When justifying, disregard out-of-flight build jobs

[Ian Jackson]

When we are looking for a previous job which justifies a failure, we
need to check that the putative justifying job used the same revision
as the baseline we are judging against.  So we investigate the build
jobs referred to by that putative justifying job.

However, there are cases where this is not appropriate.  Currently,
the most obvious example is freebsdbuildjob.

The freebsd arrangements involve referencing an anointed
freebsdbuildjob, which was in turn built from a previous
freebsdbuildjob, eventually terminating in some kind of ad-hoc job.
We would not want to investigate all of those even if we were trying
to analyse a flight on a freebsd branch.

The real thing we want to check that the build jobs *in the same
flight as the justifying job* used the right revisions.  Build jobs
from other flights were either (i) build jobs for components not being
targed for testing by this branch, but which were necessary for the
justifying job and for which we decided to reuse another build job
(in which case we don't really care what versions they used, even
if underlying it all there might be a different version of a tree
we are actually interested in (ii) the kind of continuous update
thing seen with freebsdbuildjob.

There is no corresponding issue with cs-bisection-step, because it
only looks for the *buildjob runvars of the test it is actually
interested in, and does not recurse.

Signed-off-by: Ian Jackson 
---
 sg-report-flight | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sg-report-flight b/sg-report-flight
index 2f5c391..a1adf95 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -258,6 +258,7 @@ END
while (@binfos_todo) {
my ($why,$bflight,$bjob) = @{ shift @binfos_todo };
next if $binfos{$bflight}{$bjob};
+next unless $bflight == $tflight;
$binfos{$bflight}{$bjob} = $why;
$buildjobsq->execute($bflight,$bjob);
$binfos_queue->($bflight,$buildjobsq,$why);
-- 
2.1.4


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

Re: [Xen-devel] [xen-unstable test] 123831: trouble: broken/fail/pass

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 123831: trouble: 
broken/fail/pass"):
> Are you fine then to lift the current commit moratorium?

That seems sensible, if you don't expect to be trying to branch RSN
because of the save/restore bug.

Ian.

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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 16 March 2018 12:25
> To: Paul Durrant 
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Stefano Stabellini
> ; xen-devel@lists.xenproject.org; KonradRzeszutek
> Wilk ; Daniel De Graaf ;
> Tim (Xen.org) 
> Subject: Re: [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op
> 
> >>> On 12.02.18 at 11:47,  wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -33,6 +33,7 @@ obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
> >  obj-y += hypercall.o
> >  obj-y += i387.o
> >  obj-y += i8259.o
> > +obj-y += iommu_op.o
> 
> As mentioned in other contexts, I'd prefer if we stopped using
> underscores in places where dashes (or other separators not
> usable in C identifiers) are fine.
> 

I don't see any guidance in CODING_STYLE or elsewhere, and also the majority of 
the codebase seems to prefer using underscores in module names. Personally I'd 
prefer new code remain consistent.

> > --- /dev/null
> > +++ b/xen/arch/x86/iommu_op.c
> > @@ -0,0 +1,169 @@
> >
> +/*
> *
> > + * x86/iommu_op.c
> > + *
> > + * Paravirtualised IOMMU functionality
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; If not, see .
> > + *
> > + * Copyright (C) 2018 Citrix Systems Inc
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static bool can_control_iommu(void)
> > +{
> > +struct domain *currd = current->domain;
> > +
> > +/*
> > + * IOMMU mappings cannot be manipulated if:
> > + * - the IOMMU is not enabled or,
> > + * - the IOMMU is passed through or,
> 
> "is passed through" isn't really a proper description of what
> iommu_passthrough means, I'm afraid. The description of the
> option says "Control whether to disable DMA remapping for
> Dom0." Perhaps "is bypassed"? But then it would be better
> to qualify the check with is_hardware_domain(), despite you
> restricting things to Dom0 for now anyway.
> 

I think I'm going to add a hypercall for a domain to enable PV IOMMU at start 
of day, so I'll re-work all this in a separate patch.

> > + * - shared EPT configured or,
> > + * - Xen is maintaining an identity map.
> 
> Is this meant to describe ...
> 
> > + */
> > +if ( !iommu_enabled || iommu_passthrough ||
> > + iommu_use_hap_pt(currd) || need_iommu(currd) )
> 
> ... need_iommu() here? How is that implying an identity map?
> 
> > +return false;
> > +
> > +return true;
> 
> Please make this a singe return statement (with the expression as
> operand).
> 
> > +long do_iommu_op(XEN_GUEST_HANDLE_PARAM(xen_iommu_op_t)
> uops,
> > + unsigned int count)
> > +{
> > +unsigned int i;
> > +int rc;
> > +
> > +rc = xsm_iommu_op(XSM_PRIV, current->domain);
> > +if ( rc )
> > +return rc;
> > +
> > +if ( !can_control_iommu() )
> > +return -EACCES;
> > +
> > +for ( i = 0; i < count; i++ )
> > +{
> > +xen_iommu_op_t op;
> > +
> > +if ( ((i & 0xff) == 0xff) && hypercall_preempt_check() )
> > +{
> > +rc = i;
> 
> For this to be correct for large enough values of "count", rc needs
> to have long type.

Yes, it does indeed.

> 
> > +break;
> > +}
> > +
> > +if ( copy_from_guest_offset(, uops, i, 1) )
> > +{
> > +rc = -EFAULT;
> > +break;
> > +}
> > +
> > +iommu_op();
> > +
> > +if ( copy_to_guest_offset(uops, i, , 1) )
> 
> __copy_to_guest_offset()
> 
> Also do you really need to copy back other than the status?

At this stage, no. I'll restrict it here and it can expand later if need be.

> 
> > --- /dev/null
> > +++ b/xen/include/public/iommu_op.h
> > @@ -0,0 +1,55 @@
> > +/*
> > + * Permission is hereby granted, free of charge, to any person obtaining a
> copy
> > + * of this software and associated documentation files (the "Software"),
> to
> > + * deal in the Software without restriction, including without limitation 
> > the
> > + * rights to use, copy, modify, merge, publish, distribute, sublicense,
> and/or
> > + * sell copies of the Software, and to permit persons to whom the
> Software is
> > + * furnished to do so, subject to the following conditions:
> > + *
> 

Re: [Xen-devel] [xen-unstable test] 123831: trouble: broken/fail/pass

[Juergen Gross]

On 07/06/18 12:29, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 123831: trouble: 
> broken/fail/pass"):
>> The same host (italia1) that had the failed xtf test yesterday. The two
>> failures are looking very similar to me.
>>
>> Again the question: should we do a force push?
> 
> I think the final decision is up to you, but I would reason along
> these lines:
> 
> The point of the push gate is to stop regressions making it into
> master.  However, osstest cannot currently handle heisenbugs well, so
> it punts: when something is identified as a heisenbug, it is not
> considered a regression.
> 
> 
> There is this failure in 123831
> (3960f3a52346348e6b0306f65d19375612bd35b9, staging)
> 
>  test-xtf-amd64-amd64-5  broken
>  test-xtf-amd64-amd64-5 4 host-install(4) broken pass in 123670
> 
> This is an infrastructure problem.  It means that that xtf test didn't
> run.  However, each flight runs the same battery of tests on 5
> different hosts; so identical tests were run on other hosts.  We're
> just missing 20% of the XTF test host diversity we would have had.
> 
> So on that basis a force push is justified, because we can see that
> the failure in 123831 does not really give any reason to suspect a
> regression and the test coverage was only slightly reduced compared to
> what was planned.
> 
> 
> However, there are these failures in 123799
> (06f542f8f2e446c01bd0edab51e9450af7f6e05b, master)
> 
>  test-armhf-armhf-xl-arndale
>5 host-ping-check-native   fail
>REGR. vs. 123323
> 
> This is very likely the known arndale bug and not a cause for concern.
> 
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
>14 guest-saverestore.2 fail
>REGR. vs. 123323b
> 
> This failure is being discussed in email.  Obviously this is not a
> regression from master, since it's *in* master.  But it might be a
> release critical bug.

I'm quite sure it is. OTOH I suspect it should have been addressed
in 4.10 already...

Thinking more about it I believe this is the right time to try
fixing that bug. In case there is no objection I'd like to declare it
as being release critical.

> If it is a release critical bug then branching (and consequently
> opening staging again) might entrench the bug, both by allowing
> effort to go to "shiny new stuff", and by making it harder to fix as
> staging diverges from staging-4.11.

Right.

> So I think overall, I would say this justifies a force push but if the
> reason for wanting a force push was to enable branching, there is an
> actual decision to be made, which is a matter of judgement.

Thanks for the detailed answer, which is more or less following the same
line of thoughts I've had.

So lets wait and see whether there is progress catching the domain save
bug.

Are you fine then to lift the current commit moratorium?


Juergen

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

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

[Juergen Gross]

On 06/06/18 11:40, Juergen Gross wrote:
> On 06/06/18 11:35, Jan Beulich wrote:
> On 05.06.18 at 18:19,  wrote:
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 
>>>
>>> I thought I would reply again with the key point from my earlier mail
>>> highlighted, and go a bit further.  The first thing to go wrong in
>>> this was:
>>>
>>> 2018-05-30 22:12:49.320+: xc: Failed to get types for pfn batch (14 = 
>>> Bad address): Internal error
>>> 2018-05-30 22:12:49.483+: xc: Save failed (14 = Bad address): Internal 
>>> error
>>> 2018-05-30 22:12:49.648+: libxl-save-helper: complete r=-1: Bad address
>>>
>>> You can see similar messages in the other logfile:
>>>
>>> 2018-05-30 22:12:49.650+: libxl: 
>>> libxl_stream_write.c:350:libxl__xc_domain_save_done: Domain 3:saving 
>>> domain: domain responded to suspend request: Bad address
>>>
>>> All of these are reports of the same thing: xc_get_pfn_type_batch at
>>> xc_sr_save.c:133 failed with EFAULT.  I'm afraid I don't know why.
>>>
>>> There is no corresponding message in the host's serial log nor the
>>> dom0 kernel log.
>>
>> I vaguely recall from the time when I had looked at the similar Windows
>> migration issues that the guest is already in the process of being cleaned
>> up when these occur. Commit 2dbe9c3cd2 ("x86/mm: silence a pointless
>> warning") intentionally suppressed a log message here, and the
>> immediately following debugging code (933f966bcd x86/mm: add
>> temporary debugging code to get_page_from_gfn_p2m()) was reverted
>> a little over a month later. This wasn't as a follow-up to another patch
>> (fix), but following the discussion rooted at
>> https://lists.xenproject.org/archives/html/xen-devel/2017-06/msg00324.html
> 
> That was -ESRCH, not -EFAULT.

I've looked a little bit more into this.

As we are seeing EFAULT being returned by the hypervisor this either
means the tools are specifying an invalid address (quite unlikely)
or the buffers are not as MAP_LOCKED as we wish them to be.

Is there a way to see whether the host was experiencing some memory
shortage, so the buffers might have been swapped out?

man mmap tells me: "This implementation will try to populate (prefault)
the whole range but the mmap call doesn't fail with ENOMEM if this
fails. Therefore major faults might happen later on."

And: "One should use mmap(2) plus mlock(2) when major faults are not
acceptable after the initialization of the mapping."

With osdep_alloc_pages() in tools/libs/call/linux.c touching all the
hypercall buffer pages before doing the hypercall I'm not sure this
could be an issue.

Any thoughts on that?


Juergen

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

Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 07 June 2018 11:28
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> linux-ker...@vger.kernel.org
> Cc: Juergen Gross ; Boris Ostrovsky
> ; Dan Carpenter
> 
> Subject: Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning
> 
> On 07/06/18 11:21, Paul Durrant wrote:
> > Commit 3ad0876554ca ("xen/privcmd: add
> IOCTL_PRIVCMD_MMAP_RESOURCE")
> > introduced a static checker warning:
> >
> >   drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource()
> >   warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()'
> > 64 vs 32.
> >
> > caused by this cast:
> >
> >827  num = xen_remap_domain_mfn_array(vma,
> >828   kdata.addr & PAGE_MASK,
> >829   pfns, kdata.num, (int *)pfns,
> >   ^^^
> >
> > The reason for the cast is that xen_remap_domain_mfn_array() requires
> an
> > array of ints to store error codes. It is actually safe to re-use the
> > pfns array for this purpose but it does look odd (as well as leading to
> > the warning). It would also be easy for a future implementation change
> > to make this re-use unsafe so this patch modifies privcmd to use a
> > separately allocated array for error codes.
> >
> > Reported-by: Dan Carpenter 
> > Signed-off-by: Paul Durrant 
> 
> It may be safe to reuse pfns[] as the storage space for the errs array,
> but code is incorrect when sizeof(pfn) != sizeof(int).  In such a case,
> you skip over every other err, and second half of pfns[] is junk from
> the point of view of the errs loop.
> 

Yep, that is indeed what happens without this patch.

  Paul

> ~Andrew
> 
> > ---
> > Cc: Boris Ostrovsky 
> > Cc: Juergen Gross 
> > Cc: Dan Carpenter 
> > ---
> >  drivers/xen/privcmd.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> > index 8ae0349..8507c13 100644
> > --- a/drivers/xen/privcmd.c
> > +++ b/drivers/xen/privcmd.c
> > @@ -822,11 +822,18 @@ static long privcmd_ioctl_mmap_resource(struct
> file *file, void __user *udata)
> > unsigned int domid =
> > (xdata.flags & XENMEM_rsrc_acq_caller_owned) ?
> > DOMID_SELF : kdata.dom;
> > +   int *errs;
> > int num;
> >
> > +   errs = kcalloc(kdata.num, sizeof(*errs), GFP_KERNEL);
> > +   if (!errs) {
> > +   rc = -ENOMEM;
> > +   goto out;
> > +   }
> > +
> > num = xen_remap_domain_mfn_array(vma,
> >  kdata.addr & PAGE_MASK,
> > -pfns, kdata.num, (int *)pfns,
> > +pfns, kdata.num, errs,
> >  vma->vm_page_prot,
> >  domid,
> >  vma->vm_private_data);
> > @@ -836,12 +843,14 @@ static long privcmd_ioctl_mmap_resource(struct
> file *file, void __user *udata)
> > unsigned int i;
> >
> > for (i = 0; i < num; i++) {
> > -   rc = pfns[i];
> > +   rc = errs[i];
> > if (rc < 0)
> > break;
> > }
> > } else
> > rc = 0;
> > +
> > +   kfree(errs);
> > }
> >
> >  out:

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

Re: [Xen-devel] [PATCH 02/11] x86/vmx: Don't clobber %dr6 while debugging state is lazy

[Jan Beulich]

>>> On 06.06.18 at 16:16,  wrote:
> On 06/06/18 14:50, Jan Beulich wrote:
> On 04.06.18 at 15:59,  wrote:
>>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>>> @@ -3696,6 +3696,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
>>>   */
>>>  __vmread(EXIT_QUALIFICATION, _qualification);
>>>  HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
>>> +__restore_debug_registers(v);
>>>  write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
>> The change is certainly correct as is, but I'd still like to put out for
>> discussion the alternative option:
>>
>> if ( v->arch.hvm_vcpu.flag_dr_dirty )
>> write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
>> else
>> v->arch.debugreg[6] = exit_qualification | DR_STATUS_RESERVED_ONE;
>>
>> After all the guest may know it's single stepping, and may not care to
>> read DR6 at all.
> 
> All of this code changes across the series (so this specific suggestion
> is incorrect), but to the recommendation in general...

While I've not made it through the second half of the series yet,
another consideration: To avoid the double DR6 write, yet still avoid
an immediate further exit to restore debug registers, why not

if ( v->arch.hvm_vcpu.flag_dr_dirty )
write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
else
{
v->arch.debugreg[6] = exit_qualification | DR_STATUS_RESERVED_ONE;
__restore_debug_registers(v);
}

Jan



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

Re: [Xen-devel] [PATCH 06/11] x86: Reorganise and rename debug register fields in struct vcpu

[Jan Beulich]

>>> On 06.06.18 at 17:21,  wrote:
> On 06/06/18 16:00, Jan Beulich wrote:
> On 04.06.18 at 15:59,  wrote:
>>> @@ -518,7 +524,10 @@ struct arch_vcpu
>>>  void  *fpu_ctxt;
>>>  unsigned long  vgc_flags;
>>>  struct cpu_user_regs user_regs;
>>> -unsigned long  debugreg[8];
>>> +
>>> +/* Debug registers. */
>>> +unsigned long dr[4];
>>> +unsigned long dr6, dr7;
>> Since you make the last two separate fields, and since their upper
>> 32 bits are reserved-zero, why not make them uint32_t, just like
>> dr7_emul is?
> 
> Because __vmread() takes unsigned long *.
> 
> I did initially make them uint32_t, then had the compiler complain at
> me.  I indented to leave a note in the commit message, but I forgot.  Sorry.

That's for dr7 only, then. dr6 and dr7_emul could then share the other
64-bit slot.

Jan



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

Re: [Xen-devel] [PATCH v5 01/10] xen/arm64: Added handling of the trapped access to OSLSR register

[Mirela Simonovic]

Hi Julien,

On Tue, Jun 5, 2018 at 8:00 PM, Julien Grall  wrote:

>
>
> On 05/06/18 18:24, Julien Grall wrote:
>
>> Hi Mirela,
>>
>> On 01/06/18 14:17, Mirela Simonovic wrote:
>>
>>> Linux/dom0 accesses OSLSR register when saving CPU context during the
>>> suspend procedure. Xen traps access to this register, but has no handling
>>> for it. Consequently, Xen injects undef exception to linux, causing it to
>>> crash. This patch adds handling of the trapped access to OSLSR as read
>>> only as a fixed value.
>>>
>>
>> Can you please mention that you introduced handle_ro_read_val() and
>> rework handle_ro_raz()?
>>
>>
>>> Signed-off-by: Mirela Simonovic 
>>> Reviewed-by: Stefano Stabellini 
>>> Acked-by: Julien Grall 
>>>
>>
>> The reviewed-by/acked-by tags should only be kept when there are minor
>> changes in the code (and the reviewer is happy with them). This is very
>> important for the former as the tag means the reviewer read your code and
>> confirm this is correct.
>>
>> As you change quite a bit the patch, those 2 tags should have been
>> removed.
>>
>> Stefano, are you still happy with the Reviewed-by?
>>
>
> Stefano mentioned on IRC he was happy with the reviewed-by kept.
>
> I will go ahead with merging the series. For this patch, I will add the
> following in the commit message:
>
> "For convenience, introduce a new helper handle_ro_read_val() based on
> handle_ro_raz() that will return a specified value on read and re-implement
> handle_ro_raz() based on the new helper".
>
>
Great, thanks!


> Cheers,
>
> --
> Julien Grall
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] ARM: Issues while Enabling hibernation in domU(linux) on jacinto-j6

[Mirela Simonovic]

Hi,

On Wed, Jun 6, 2018 at 8:00 PM, Julien Grall  wrote:
> (+ Stefano, Mirela, Juergen and Boris)
>
> On 06/06/18 09:17, moin anjnawala wrote:
>>
>> Hi Julien,
>
>
> Hi,
>
>> As you specified earlier I am now able to boot using xen4.10. I am
>> using linux4.4 as dom0 as well as domU.In domU, I have enabled
>> hibenation related configs and I am trying suspend to disk.With xen
>> 4.10, hibernation is done sucessfuly but resume crashes.
>
>
> It would have been nice to switch to a more recent Linux as well because I
> don't think anyone worked on suspend/resume 2 years ago. There are effort to
> support suspend/resume in Xen (and I guess guest) but I suspect some work is
> still missing in newer kernel. Although that would be a better start than a
> 2 years old kernel for the guest.
>
>
>> I have used given config file for domU.
>> name = "domU"
>> kernel = "/ZI-uh1"
>> memory = 200
>> vcpus = 1
>> cpus = 1
>> disk = [ 'phy:/rfs1.img,xvda,rw']
>>
>> extra = 'no_console_suspend loglevel=8 console=hvc0 xenconsole=tty
>> earlyprintk=xx
>> en rw dhcp=off resume=/dev/xvda resume_offset=331776 root=/dev/xvda
>> rootwait'
>>
>> The hibernate(domU console) and resume logs are shown as below:
>>
>>
>> root@debian-jessie:~# swapon /swapfile.img
>>
>> swapon: /swapfile.img: insecure permissions 0644, 0600 suggested.
>> [   50.064545] Adding 102396k swap on /swapfile.img.  Priority:-1
>> extents:1 across:102396k SS
>> root@debian-jessie:~#
>> root@debian-jessie:~#
>> root@debian-jessie:~# echo disk > /sys/power/state
>> [   56.649793] PM: Syncing filesystems ... done.
>> [   56.686770] Freezing user space processes ... (elapsed 0.002 seconds)
>> done.
>> [   56.689454] PM: Basic memory bitmaps created
>> [   56.689497] PM: Preallocating image memory... done (allocated 11077
>> pages)
>> [   57.119960] PM: Allocated 44308 kbytes in 0.43 seconds (103.04 MB/s)
>> [   57.120010] Freezing remaining freezable tasks ... (elapsed 0.009
>> seconds) done.
>> [   58.922629] PM: freeze of devices complete after 1791.756 msecs
>> [   58.925167] PM: late freeze of devices complete after 2.485 msecs
>> [   58.927231] PM: noirq freeze of devices complete after 2.010 msecs
>> [   58.927275] Disabling non-boot CPUs ...
>> [   58.927307] PM: Creating hibernation image:
>> [   58.927307] PM: Need to copy 10790 pages
>> [   58.927307] PM: Normal pages needed: 10790 + 1024, available pages:
>> 40398
>> [   58.927307] PM: Hibernation image created (10790 pages copied)
>> [   58.928629] PM: noirq thaw of devices complete after 1.310 msecs
>> [   58.930334] PM: early thaw of devices complete after 1.589 msecs
>> [   60.634498] PM: thaw of devices complete after 1704.114 msecs
>> [   60.635878] PM: writing image.
>> [   60.680038] PM: Using 1 thread(s) for compression.
>> [   60.680038] PM: Compressing and saving image data (10801 pages)...
>> [   60.680170] PM: Image saving progress:   0%
>> [   61.288932] PM: Image saving progress:  10%
>> [   61.809937] PM: Image saving progress:  20%
>> [   61.994594] PM: Image saving progress:  30%
>> [   62.360616] PM: Image saving progress:  40%
>> [   62.583613] random: nonblocking pool is initialized
>> [   62.592295] PM: Image saving progress:  50%
>> [   62.665052] PM: Image saving progress:  60%
>> [   62.700022] PM: Image saving progress:  70%
>> [   62.759685] PM: Image saving progress:  80%
>> [   62.821796] PM: Image saving progress:  90%
>> [   62.854694] PM: Image saving progress: 100%
>> [   62.855175] PM: Image saving done.
>> [   62.855210] PM: Wrote 43204 kbytes in 2.17 seconds (19.90 MB/s)
>> [   62.863308] PM: S|
>> [   62.921029] reboot: Power down
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~#
>> root@Dom0:~# xl create -c /vnc_l.cfg
>> Parsing config from /vnc_l.cfg
>> (XEN) d2v0: vGICD: unhandled word write 0x to ICACTIVER0
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 4.4.91-2-g89baae6-dirty
>
>
> I don't seem to be able to find that commit in Linux and it also says dirty.
> What are your modification on top of Linux 4.4?
>
>
>> (omkar.bolla@CPU-308U) (gcc version 4.8.4 (Ubuntu/Linaro
>> 4.8.4-2ubuntu1~14.04.1) ) #107 SMP PR
>> EEMPT Tue Jun 5 16:51:21 IST 2018
>> [0.00] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7),
>> cr=50c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction
>> cache
>> [0.00] Machine model: XENVM-4.10
>> [0.00] cma: Reserved 24 MiB at 0x4b00
>> [0.00] Memory policy: Data cache writealloc
>> [0.00] On node 0 totalpages: 51200
>> [0.00] free_area_init_node: node 0, pgdat c07eb740,
>> node_mem_map cae2b000
>> [0.00]   Normal zone: 450 pages used for memmap
>> [0.00]   Normal zone: 0 

Re: [Xen-devel] [xen-unstable test] 123831: trouble: broken/fail/pass

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [xen-unstable test] 123831: trouble: 
broken/fail/pass"):
> The same host (italia1) that had the failed xtf test yesterday. The two
> failures are looking very similar to me.
> 
> Again the question: should we do a force push?

I think the final decision is up to you, but I would reason along
these lines:

The point of the push gate is to stop regressions making it into
master.  However, osstest cannot currently handle heisenbugs well, so
it punts: when something is identified as a heisenbug, it is not
considered a regression.


There is this failure in 123831
(3960f3a52346348e6b0306f65d19375612bd35b9, staging)

 test-xtf-amd64-amd64-5  broken
 test-xtf-amd64-amd64-5 4 host-install(4) broken pass in 123670

This is an infrastructure problem.  It means that that xtf test didn't
run.  However, each flight runs the same battery of tests on 5
different hosts; so identical tests were run on other hosts.  We're
just missing 20% of the XTF test host diversity we would have had.

So on that basis a force push is justified, because we can see that
the failure in 123831 does not really give any reason to suspect a
regression and the test coverage was only slightly reduced compared to
what was planned.


However, there are these failures in 123799
(06f542f8f2e446c01bd0edab51e9450af7f6e05b, master)

 test-armhf-armhf-xl-arndale
   5 host-ping-check-native   fail
   REGR. vs. 123323

This is very likely the known arndale bug and not a cause for concern.

 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
   14 guest-saverestore.2 fail
   REGR. vs. 123323b

This failure is being discussed in email.  Obviously this is not a
regression from master, since it's *in* master.  But it might be a
release critical bug.

If it is a release critical bug then branching (and consequently
opening staging again) might entrench the bug, both by allowing
effort to go to "shiny new stuff", and by making it harder to fix as
staging diverges from staging-4.11.


So I think overall, I would say this justifies a force push but if the
reason for wanting a force push was to enable branching, there is an
actual decision to be made, which is a matter of judgement.

Ian.

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

Re: [Xen-devel] [PATCH] xen/privcmd: fix static checker warning

[Andrew Cooper]

On 07/06/18 11:21, Paul Durrant wrote:
> Commit 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE")
> introduced a static checker warning:
>
>   drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource()
>   warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()'
> 64 vs 32.
>
> caused by this cast:
>
>827  num = xen_remap_domain_mfn_array(vma,
>828   kdata.addr & PAGE_MASK,
>829   pfns, kdata.num, (int *)pfns,
>   ^^^
>
> The reason for the cast is that xen_remap_domain_mfn_array() requires an
> array of ints to store error codes. It is actually safe to re-use the
> pfns array for this purpose but it does look odd (as well as leading to
> the warning). It would also be easy for a future implementation change
> to make this re-use unsafe so this patch modifies privcmd to use a
> separately allocated array for error codes.
>
> Reported-by: Dan Carpenter 
> Signed-off-by: Paul Durrant 

It may be safe to reuse pfns[] as the storage space for the errs array,
but code is incorrect when sizeof(pfn) != sizeof(int).  In such a case,
you skip over every other err, and second half of pfns[] is junk from
the point of view of the errs loop.

~Andrew

> ---
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Dan Carpenter 
> ---
>  drivers/xen/privcmd.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
> index 8ae0349..8507c13 100644
> --- a/drivers/xen/privcmd.c
> +++ b/drivers/xen/privcmd.c
> @@ -822,11 +822,18 @@ static long privcmd_ioctl_mmap_resource(struct file 
> *file, void __user *udata)
>   unsigned int domid =
>   (xdata.flags & XENMEM_rsrc_acq_caller_owned) ?
>   DOMID_SELF : kdata.dom;
> + int *errs;
>   int num;
>  
> + errs = kcalloc(kdata.num, sizeof(*errs), GFP_KERNEL);
> + if (!errs) {
> + rc = -ENOMEM;
> + goto out;
> + }
> +
>   num = xen_remap_domain_mfn_array(vma,
>kdata.addr & PAGE_MASK,
> -  pfns, kdata.num, (int *)pfns,
> +  pfns, kdata.num, errs,
>vma->vm_page_prot,
>domid,
>vma->vm_private_data);
> @@ -836,12 +843,14 @@ static long privcmd_ioctl_mmap_resource(struct file 
> *file, void __user *udata)
>   unsigned int i;
>  
>   for (i = 0; i < num; i++) {
> - rc = pfns[i];
> + rc = errs[i];
>   if (rc < 0)
>   break;
>   }
>   } else
>   rc = 0;
> +
> + kfree(errs);
>   }
>  
>  out:


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

Re: [Xen-devel] [RFC] OVMF NVRAM Variable Retention

[Roger Pau Monné]

On Thu, Jun 07, 2018 at 09:59:10AM +0100, Ross Lagerwall wrote:
> On 06/06/2018 04:01 PM, aaron.yo...@oracle.com wrote:
> >    Any comments/suggestions/opinions/caveats on this approach?
> 
> I did this a while back. It is easy enough to do:
> 
> 1) Have Xen load OVMF_code.fd rather than the combined blob.
> 
> 2) Tweak the location in guest memory where hvmloader loads the blob.
> 
> 3) Tweak QEMU to load the OVMF_vars.fd blob at the correct location.
> 
> 4) Start QEMU with emulated flash for OVMF_vars.fd only.
> 
> Tweaking the locations ensures that the various parts of OVMF are at the
> location it expects. If you want, I could probably dig up some patches
> (hacks) which do this.

I don't like to tie UEFI (OVMF) to QEMU. We want to also run guests
with UEFI firmware without QEMU, see below.

> > 
> >    Or any other suggested approaches on how to fix this issue?
> 
> However... I did not like this approach for two reasons:
> 
> 1) Having an emulated flash blob is difficult to manage outside of the guest
> (i.e. populating initial state, updating variables if needed). For
> XenServer, we want more flexibility.
> 
> 2) While Secure Boot can be enabled with this implementation, it is not
> sufficiently secure because the guest is able to write anything it wants to
> the emulated flash. KVM solved this problem with SMM mode but I don't like
> that solution either.
> 
> So I am busy implementing:
> 
> A UEFI driver frontend which implements variable services by proxying
> requests to a backend running in dom0 (could be part of QEMU). This ensures
> security because the guest cannot directly write to the variable storage and
> the authentication checks are done outside of guest context. It allows
> flexibility because the backend can store the variables in any form (e.g. an
> sqlite database) rather than being restricted to an emulated flash blob.

This seems like a good idea, specially because that means we don't
need QEMU to load anything into the guest, and this approach could be
likely used by PVH guests running with UEFI also.

Roger.

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

[Xen-devel] [distros-debian-wheezy test] 74794: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   74767

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



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

Logs, config files, etc. are available at
http://osstest.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.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-2   broken  in 123492
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 123091
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 123091
 test-amd64-amd64-livepatch7 xen-boot fail REGR. vs. 123091
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 123091
 build-i386-pvops  6 kernel-build fail REGR. vs. 123091
 build-armhf   6 xen-buildfail REGR. vs. 123091
 test-amd64-i386-rumprun-i386  7 xen-boot   fail in 123609 REGR. vs. 123091
 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail in 123609 REGR. vs. 
123091
 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-boot fail in 123609 REGR. vs. 123091
 test-amd64-i386-libvirt-xsm   7 xen-boot   fail in 123609 REGR. vs. 123091

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-2   4 host-install(4) broken in 123492 pass in 123844
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail in 123609 pass in 123492
 test-amd64-i386-migrupgrade 10 xen-boot/src_host fail in 123609 pass in 123492
 test-amd64-i386-migrupgrade 11 xen-boot/dst_host fail in 123609 pass in 123492
 test-amd64-amd64-xl-credit2   7 xen-boot   fail pass in 123609
 test-amd64-amd64-pair10 xen-boot/src_host  fail pass in 123609
 test-amd64-amd64-pair11 xen-boot/dst_host  fail pass in 123609
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail pass in 
123701
 test-xtf-amd64-amd64-37 xen-boot   fail pass in 123809

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   

[Xen-devel] [ovmf test] 123855: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf cb004eb0ad308a4bac86037ce67a56d9ed924e50
baseline version:
 ovmf 91c31ff04a7a72b4b0e476972ad3c76e03a106a2

Last test of basis   123829  2018-06-05 18:40:54 Z1 days
Testing same since   123855  2018-06-06 12:10:34 Z0 days1 attempts


People who touched revisions under test:
  Ezra Godfrey 
  Star Zeng 
  Yunhua Feng 

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



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

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

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

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


Not pushing.


commit cb004eb0ad308a4bac86037ce67a56d9ed924e50
Author: Ezra Godfrey 
Date:   Mon Apr 30 22:33:31 2018 +0800

BaseTools/VolInfo: Update EFI FV FILETYPES for new MM types.

Add support for the following types to VolInfo:
  EFI_FV_FILETYPE_MM_STANDALONE
  EFI_FV_FILETYPE_MM_CORE_STANDALONE

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ezra Godfrey 
Reviewed-by: Jiewen Yao 

commit 179c2f97f949509ec55f0ec7cb84480fb0c015a7
Author: Yunhua Feng 
Date:   Thu May 24 10:25:21 2018 +0800

BaseTools: Display both Hex and integer value format of PCD value

If the PCD's datum type is UINT8, UINT16, UINT32 or UINT64, then in
the report will display both hexadecimal format and integer format
of PCD value.

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

commit 238d9b5c64520acdd784667a29326804dde7ea31
Author: Yunhua Feng 
Date:   Thu May 24 11:25:21 2018 +0800

BaseTools: Sort PCD by token space first then by PcdCName

Sort PCD by token space first, then by PcdCName in the build report.

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

commit 8653ea2088a386075c0d65bfc891ad3c8072db9f
Author: Star Zeng 
Date:   Tue Jun 5 16:04:38 2018 +0800

IntelSiliconPkg IntelVTdDxe: Fix incorrect code to clear VTd error

According to VTd spec, Software writes the value read from this
field (F) to Clear it. But current code is using 0 to clear the
field, that is incorrect.

And R_FSTS_REG register value clearing should be not in the for loop.

Without this patch, we will see same VTd error message appears again
and again after it occurs first time.

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 

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

Re: [Xen-devel] [RFC] OVMF NVRAM Variable Retention

[Ross Lagerwall]

On 06/06/2018 04:01 PM, aaron.yo...@oracle.com wrote:


   Hello all,

   I have been tasked with the issue of UEFI NVRAM variable retention 
with Xen HVM/OVMF based guests and wanted to consult the experts before 
I undertake any significant coding effort. I am new to Xen so any 
help/direction would be appreciated.


   What I hope to gain from this RFC inquiry is the following:

   1. Has there been any significant past discussion regarding this 
issue? If so, can somebody kindly point me to these discussion(s) and/or 
give me an overview of the findings?


   2. Is there any current coding effort going on in this area?


Yes! I'm working on this at the moment.



   3. Any suggestions or proposals on how to fix the issue including any 
issues or caveats that I should be aware of?



Issue details:

  In a nutshell, if a Xen guest which has been configured to use OVMF is 
destroyed and re-created, the UEFI NVRAM variables are not retained. 
This seems to be a well-known issue to which there is no resolution. The 
issue seems to center around the fact that these Xen guests are not 
configured to use a file-backed backing store for the NVRAM variables 
(such as is commonly used with QEMU/KVM guests).


  This issue can cause OVMF OS boot option(s) to be lost preventing the 
ability to boot the OS after a guest is destroyed/re-created. It also 
has implications on secure boot (which require NVRAM variables to be 
retained).



Some key observations:

  1. OVMF currently supports memory-mapped, file-backed 'pflash' devices 
from Qemu. i.e. Qemu can map varstore files into memory for use by OVMF 
via -drive parameters such as:


   -drive if=pflash,format=raw,readonly,file=OVMF_CODE.fd   \
   -drive if=pflash,format=raw,file=OVMF_VARS.fd

     OVMF scans the flash device (i.e. the Non-volatile data storage FV) 
for a mapped varstore and if found will use it store NVRAM variables 
(via its QemuFlashFvbServicesRuntimeDxe driver)


     This is outlined well in the OVMF whitepaper 
(http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt)


  2. When Xen HVM/OVMF guests are created, the qemu process that is 
executed (from xl) does not contain these -drive arguments. Thus qemu 
does not map a varstore for use by OVMF causing OVMF to fallback and use 
a simple memory buffer for NVRAM variables (if I'm not mistaken here). 
This causes the variables to not be retained across destroy/create 
operations on the VM.


  3. Unlike qemu/kvm guests where both OVMF and the varstore file are 
loaded/mapped into memory and executed directly by qemu, Xen appears to 
only use qemu as a "device model" and OVMF is not mapped/loaded directly 
by qemu. Instead, under Xen, OVMF is loaded indirectly by hvmloader 
(which is loaded by qemu). This could complicate the fix idea below.



Possible idea for fix:

    Since OVMF currently has support for QEMU mapped varstore files, it 
seems the most straightforward way to fix this issue would be for Xen 
(i.e. xl) to pass a -drive argument to qemu to specify a varstore file 
and to enhance the Xen memory init code in qemu (i.e. 
xen_hvm.c:xen_[hvm|ram]_init()) to map this file into memory for use by 
OVMF (possibly taking advantage of the already present qemu code to do 
such a mapping (i.e. code out of pc_memory_init()). As mentioned above, 
this would have to (somehow) be compatible with how OVMF is loaded 
indirectly by hvmloader.


   Any comments/suggestions/opinions/caveats on this approach?


I did this a while back. It is easy enough to do:

1) Have Xen load OVMF_code.fd rather than the combined blob.

2) Tweak the location in guest memory where hvmloader loads the blob.

3) Tweak QEMU to load the OVMF_vars.fd blob at the correct location.

4) Start QEMU with emulated flash for OVMF_vars.fd only.

Tweaking the locations ensures that the various parts of OVMF are at the 
location it expects. If you want, I could probably dig up some patches 
(hacks) which do this.




   Or any other suggested approaches on how to fix this issue?


However... I did not like this approach for two reasons:

1) Having an emulated flash blob is difficult to manage outside of the 
guest (i.e. populating initial state, updating variables if needed). For 
XenServer, we want more flexibility.


2) While Secure Boot can be enabled with this implementation, it is not 
sufficiently secure because the guest is able to write anything it wants 
to the emulated flash. KVM solved this problem with SMM mode but I don't 
like that solution either.


So I am busy implementing:

A UEFI driver frontend which implements variable services by proxying 
requests to a backend running in dom0 (could be part of QEMU). This 
ensures security because the guest cannot directly write to the variable 
storage and the authentication checks are done outside of guest context. 
It allows flexibility because the backend can store the variables in any 
form (e.g. an sqlite database) rather than being restricted 

Re: [Xen-devel] [bug report] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Paul Durrant]

> -Original Message-
> From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
> Sent: 07 June 2018 09:32
> To: Paul Durrant 
> Cc: xen-devel@lists.xenproject.org
> Subject: [bug report] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE
> 
> Hello Paul Durrant,
> 
> The patch 3ad0876554ca: "xen/privcmd: add
> IOCTL_PRIVCMD_MMAP_RESOURCE" from May 9, 2018, leads to the
> following
> static checker warning:
> 
>   drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource()
>   warn: passing casted pointer 'pfns' to
> 'xen_remap_domain_mfn_array()' 64 vs 32.
> 
> drivers/xen/privcmd.c
>746  static long privcmd_ioctl_mmap_resource(struct file *file, void __user
> *udata)
>747  {
>748  struct privcmd_data *data = file->private_data;
>749  struct mm_struct *mm = current->mm;
>750  struct vm_area_struct *vma;
>751  struct privcmd_mmap_resource kdata;
>752  xen_pfn_t *pfns = NULL;
>753  struct xen_mem_acquire_resource xdata;
>754  int rc;
>755
>756  if (copy_from_user(, udata, sizeof(kdata)))
>757  return -EFAULT;
>758
>759  /* If restriction is in place, check the domid matches */
>760  if (data->domid != DOMID_INVALID && data->domid !=
> kdata.dom)
>761  return -EPERM;
>762
>763  down_write(>mmap_sem);
>764
>765  vma = find_vma(mm, kdata.addr);
>766  if (!vma || vma->vm_ops != _vm_ops) {
>767  rc = -EINVAL;
>768  goto out;
>769  }
>770
>771  pfns = kcalloc(kdata.num, sizeof(*pfns), GFP_KERNEL);
>772  if (!pfns) {
>773  rc = -ENOMEM;
>774  goto out;
>775  }
>776
>777  if (xen_feature(XENFEAT_auto_translated_physmap)) {
>778  unsigned int nr = DIV_ROUND_UP(kdata.num,
> XEN_PFN_PER_PAGE);
>779  struct page **pages;
>780  unsigned int i;
>781
>782  rc = alloc_empty_pages(vma, nr);
>783  if (rc < 0)
>784  goto out;
>785
>786  pages = vma->vm_private_data;
>787  for (i = 0; i < kdata.num; i++) {
>788  xen_pfn_t pfn =
>789  page_to_xen_pfn(pages[i / 
> XEN_PFN_PER_PAGE]);
>790
>791  pfns[i] = pfn + (i % XEN_PFN_PER_PAGE);
>792  }
>793  } else
>794  vma->vm_private_data = PRIV_VMA_LOCKED;
>795
>796  memset(, 0, sizeof(xdata));
>797  xdata.domid = kdata.dom;
>798  xdata.type = kdata.type;
>799  xdata.id = kdata.id;
>800  xdata.frame = kdata.idx;
>801  xdata.nr_frames = kdata.num;
>802  set_xen_guest_handle(xdata.frame_list, pfns);
>803
>804  xen_preemptible_hcall_begin();
>805  rc = HYPERVISOR_memory_op(XENMEM_acquire_resource,
> );
>806  xen_preemptible_hcall_end();
>807
>808  if (rc)
>809  goto out;
>810
>811  if (xen_feature(XENFEAT_auto_translated_physmap)) {
>812  struct remap_pfn r = {
>813  .mm = vma->vm_mm,
>814  .pages = vma->vm_private_data,
>815  .prot = vma->vm_page_prot,
>816  };
>817
>818  rc = apply_to_page_range(r.mm, kdata.addr,
>819   kdata.num << PAGE_SHIFT,
>820   remap_pfn_fn, );
>821  } else {
>822  unsigned int domid =
>823  (xdata.flags & XENMEM_rsrc_acq_caller_owned) ?
>824  DOMID_SELF : kdata.dom;
>825  int num;
>826
>827  num = xen_remap_domain_mfn_array(vma,
>828   kdata.addr & 
> PAGE_MASK,
>829   pfns, kdata.num, 
> (int *)pfns,
>   
> ^^^
> I'm a newbie to this code, but I don't understand how it can be right...
> The (int *)pfns argument is used to store integer error codes, but that
> will only write to the first half of the buffer?  Unless this only works
> on 32 bit CPUs?

No, it's supposed to work on 64 bit too and that is a very good point. The cast 
is still fine since the buffer re-use is safe but it needs to be correctly 
cast...

> 
>830   vma->vm_page_prot,
>831   domid,
>

Re: [Xen-devel] [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

[Oleksandr Andrushchenko]

On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:

On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:

On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:



+
+static struct sg_table *
+dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *attach,
+   enum dma_data_direction dir)
+{
+    struct gntdev_dmabuf_attachment *gntdev_dmabuf_attach =
attach->priv;
+    struct gntdev_dmabuf *gntdev_dmabuf = attach->dmabuf->priv;
+    struct sg_table *sgt;
+
+    pr_debug("Mapping %d pages for dev %p\n", gntdev_dmabuf->nr_pages,
+ attach->dev);
+
+    if (WARN_ON(dir == DMA_NONE || !gntdev_dmabuf_attach))

WARN_ON_ONCE. Here and elsewhere.

Why? The UAPI may be used by different applications, thus we might
lose warnings for some of them. Having WARN_ON will show problems
for multiple users, not for the first one.
Does this make sense to still use WARN_ON?


Just as with pr_err call somewhere else the concern here is that
userland (which I think is where this is eventually called from?) may
intentionally trigger the error, flooding the log.

And even this is not directly called from userland there is still a
possibility of triggering this error multiple times.

Ok, will use WARN_ON_ONCE



+
+    if (use_ptemod) {
+    pr_err("Cannot provide dma-buf: use_ptemode %d\n",
+   use_ptemod);

No pr_err here please. This can potentially become a DoS vector as it
comes directly from ioctl.

I would, in fact, revisit other uses of pr_err in this file.

Sure, all of pr_err can actually be pr_debug...

I'd check even further and see if any prink is needed. I think I saw a
couple that were not especially useful.

All those were useful while debugging the code and use-cases,
so I would prefer to have them all still available, but as pr_debug
instead of pr_err
If hyper_dmabuf will use this Xen dma-buf solution then I believe
those will help as well



+    return -EINVAL;
+    }
+
+    map = dmabuf_exp_alloc_backing_storage(priv, flags, count);

@count comes from userspace. dmabuf_exp_alloc_backing_storage only
checks for it to be >0. Should it be checked for some sane max value?

This is not easy as it is hard to tell what could be that
max value. For DMA buffers if count is too big then allocation
will fail, so need to check for max here  (dma_alloc_{xxx} will
filter out too big allocations).

OK, that may be sufficient. BTW, I believe there were other loops with
@count being the control variable. Please see if a user can pass a bogus
value.

Will check for op.count in IOCTLs

For Xen balloon allocations I cannot tell what could be that
max value neither. Tough question how to limit.

I think in balloon there is also a guarantee (of sorts) that something
prior to a loop will fail.


-boris

Thank you,
Oleksandr

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

[Xen-devel] [qemu-mainline baseline-only test] 74793: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 74793 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74793/

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu1d889f2a8baaa265939b339d2f52ec57f5b8a09c
baseline version:
 qemuuafd76ffba966a072a7bbd0048bdf3b2ab69d3d4a

Last test of basis74784  2018-06-05 21:46:54 Z1 days
Testing same since74793  2018-06-06 22:46:20 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Changpeng Liu 
  Cédric Le Goater 
  Daniel P. Berrangé 
  David Gibson 
  Dr. David Alan Gilbert 
  Fam Zheng 
  Gerd Hoffmann 
  Jeff Cody 
  Juan Quintela 
  Laurent Vivier 
  Lidong Chen 
  Lidong Chen 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Peter Maydell 
  Philippe Mathieu-Daudé 
  Richard Henderson 
  Ross Zwisler 
  Stefan Hajnoczi 
  Thomas Huth 
  Tiwei Bie 
  Xiao Guangrong 

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  fail
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  fail
 test-amd64-i386-xl-xsm 

Re: [Xen-devel] PROBLEM: xen-netfront: ethtool settings changed in 4.4.134 causing packet loss

[Ross Lagerwall]

On 06/05/2018 04:43 PM, Liam Shepherd wrote:

When upgrading from 4.4.132 to 4.4.135 I started observing about 3%
packet loss on PV on HVM domU interfaces. Specifically TX dropped
packets (As reported by ifconfig).

It seems that the default ethtool settings have changed.

Previously (4.4.132):
tx-checksumming: on
 tx-checksum-ipv4: on [fixed]
 tx-checksum-ip-generic: off [fixed]
 tx-checksum-ipv6: on
 tx-checksum-fcoe-crc: off [fixed]
 tx-checksum-sctp: off [fixed]
scatter-gather: on
 tx-scatter-gather: on
 tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
 tx-tcp-segmentation: on
 tx-tcp-ecn-segmentation: off [fixed]
 tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on

Now (4.4.135):
tx-checksumming: on
 tx-checksum-ipv4: on [fixed]
 tx-checksum-ip-generic: off [fixed]
 tx-checksum-ipv6: off
 tx-checksum-fcoe-crc: off [fixed]
 tx-checksum-sctp: off [fixed]
scatter-gather: off
 tx-scatter-gather: off
 tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
 tx-tcp-segmentation: off
 tx-tcp-ecn-segmentation: off [fixed]
 tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off [requested on]

Manually running 'ethtool -K INT tso on sg on' on all interfaces stops
the packet loss again. They're then set like this:
tx-checksumming: on
 tx-checksum-ipv4: on [fixed]
 tx-checksum-ip-generic: off [fixed]
 tx-checksum-ipv6: off
 tx-checksum-fcoe-crc: off [fixed]
 tx-checksum-sctp: off [fixed]
scatter-gather: on
 tx-scatter-gather: on
 tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
 tx-tcp-segmentation: on
 tx-tcp-ecn-segmentation: off [fixed]
 tx-tcp6-segmentation: off [requested on]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on

I've traced it to a commit in 4.4.134:
6be4fe832954db3b359b72107a6c60e34d939b26
xen-netfront: Fix race between device setup and open
[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
https://patchwork.kernel.org/patch/10328969/

Once that is reverted on 4.4.135, the ethtool settings are as 4.4.132
and there is no packet loss.

Thanks for the bug report. Changing the ethtool settings was certainly 
not intended with that change. I'll take a look to see what has gone wrong.


--
Ross Lagerwall

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

[Xen-devel] [bug report] xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE

[Dan Carpenter]

Hello Paul Durrant,

The patch 3ad0876554ca: "xen/privcmd: add
IOCTL_PRIVCMD_MMAP_RESOURCE" from May 9, 2018, leads to the following
static checker warning:

drivers/xen/privcmd.c:827 privcmd_ioctl_mmap_resource()
warn: passing casted pointer 'pfns' to 'xen_remap_domain_mfn_array()' 
64 vs 32.

drivers/xen/privcmd.c
   746  static long privcmd_ioctl_mmap_resource(struct file *file, void __user 
*udata)
   747  {
   748  struct privcmd_data *data = file->private_data;
   749  struct mm_struct *mm = current->mm;
   750  struct vm_area_struct *vma;
   751  struct privcmd_mmap_resource kdata;
   752  xen_pfn_t *pfns = NULL;
   753  struct xen_mem_acquire_resource xdata;
   754  int rc;
   755  
   756  if (copy_from_user(, udata, sizeof(kdata)))
   757  return -EFAULT;
   758  
   759  /* If restriction is in place, check the domid matches */
   760  if (data->domid != DOMID_INVALID && data->domid != kdata.dom)
   761  return -EPERM;
   762  
   763  down_write(>mmap_sem);
   764  
   765  vma = find_vma(mm, kdata.addr);
   766  if (!vma || vma->vm_ops != _vm_ops) {
   767  rc = -EINVAL;
   768  goto out;
   769  }
   770  
   771  pfns = kcalloc(kdata.num, sizeof(*pfns), GFP_KERNEL);
   772  if (!pfns) {
   773  rc = -ENOMEM;
   774  goto out;
   775  }
   776  
   777  if (xen_feature(XENFEAT_auto_translated_physmap)) {
   778  unsigned int nr = DIV_ROUND_UP(kdata.num, 
XEN_PFN_PER_PAGE);
   779  struct page **pages;
   780  unsigned int i;
   781  
   782  rc = alloc_empty_pages(vma, nr);
   783  if (rc < 0)
   784  goto out;
   785  
   786  pages = vma->vm_private_data;
   787  for (i = 0; i < kdata.num; i++) {
   788  xen_pfn_t pfn =
   789  page_to_xen_pfn(pages[i / 
XEN_PFN_PER_PAGE]);
   790  
   791  pfns[i] = pfn + (i % XEN_PFN_PER_PAGE);
   792  }
   793  } else
   794  vma->vm_private_data = PRIV_VMA_LOCKED;
   795  
   796  memset(, 0, sizeof(xdata));
   797  xdata.domid = kdata.dom;
   798  xdata.type = kdata.type;
   799  xdata.id = kdata.id;
   800  xdata.frame = kdata.idx;
   801  xdata.nr_frames = kdata.num;
   802  set_xen_guest_handle(xdata.frame_list, pfns);
   803  
   804  xen_preemptible_hcall_begin();
   805  rc = HYPERVISOR_memory_op(XENMEM_acquire_resource, );
   806  xen_preemptible_hcall_end();
   807  
   808  if (rc)
   809  goto out;
   810  
   811  if (xen_feature(XENFEAT_auto_translated_physmap)) {
   812  struct remap_pfn r = {
   813  .mm = vma->vm_mm,
   814  .pages = vma->vm_private_data,
   815  .prot = vma->vm_page_prot,
   816  };
   817  
   818  rc = apply_to_page_range(r.mm, kdata.addr,
   819   kdata.num << PAGE_SHIFT,
   820   remap_pfn_fn, );
   821  } else {
   822  unsigned int domid =
   823  (xdata.flags & XENMEM_rsrc_acq_caller_owned) ?
   824  DOMID_SELF : kdata.dom;
   825  int num;
   826  
   827  num = xen_remap_domain_mfn_array(vma,
   828   kdata.addr & PAGE_MASK,
   829   pfns, kdata.num, (int 
*)pfns,
  
^^^
I'm a newbie to this code, but I don't understand how it can be right...
The (int *)pfns argument is used to store integer error codes, but that
will only write to the first half of the buffer?  Unless this only works
on 32 bit CPUs?

   830   vma->vm_page_prot,
   831   domid,
   832   vma->vm_private_data);
   833  if (num < 0)
   834  rc = num;
   835  else if (num != kdata.num) {
   836  unsigned int i;
   837  
   838  for (i = 0; i < num; i++) {
   839  rc = pfns[i];
   840  if (rc < 0)
   841  break;
   842  }
   843  } else
   844  rc = 0;
   

Re: [Xen-devel] Xentop issues

[Dongli Zhang]

Isn't the page https://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project

Dongli Zhang

- Original Message -
From: sc...@viviotech.net
To: xen-de...@lists.xen.org
Sent: Thursday, June 7, 2018 1:30:47 PM GMT +08:00 Beijing / Chongqing / Hong 
Kong / Urumqi
Subject: [Xen-devel] Xentop issues

Firstly, I'm sorry if I am not sending the necessary information to
report a bug, but your "how to send bug reports" page isn't working
either: http://wiki.xen.org/xenwiki/ReportingBugs is giving a 404.

-- 
That guy (You know the one).


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

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

Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

[Oleksandr Andrushchenko]

On 06/07/2018 01:05 AM, Dongwon Kim wrote:

On Wed, Jun 06, 2018 at 05:51:38PM -0400, Boris Ostrovsky wrote:

On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote:

On 06/05/2018 01:36 AM, Boris Ostrovsky wrote:

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:

From: Oleksandr Andrushchenko 

Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.

Can you give an example of who'd be using these interfaces?

There is no use-case at the moment I can think of, but hyper dma-buf
[1], [2]
I let Intel folks (CCed) to defend this patch as it was done primarily
for them
and I don't use it in any of my use-cases. So, from this POV it can be
dropped,
at least from this series.


Yes, let's drop this until someone actually needs it.

-boris

I agree. We are working on re-architecturing hyper_dmabuf. We would use zcopy
apis however, not sure if we are going to do it from kernel or from userspace.
So please do not expose those for now.
Ok, as we are all on the same page for that then I'll drop this patch 
for now



-boris


[1] https://patchwork.freedesktop.org/series/38207/
[2] https://patchwork.freedesktop.org/patch/204447/

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



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

Re: [Xen-devel] [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

[Oleksandr Andrushchenko]

On 06/07/2018 12:32 AM, Boris Ostrovsky wrote:

On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:

On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
+struct gntdev_dmabuf_export_args {
+    int dummy;
+};

Please define the full structure (at least what you have in the next
patch) here.

Ok, will define what I have in the next patch, but won't
initialize anything until the next patch. Will this work for you?

Sure, I just didn't see the need for the dummy argument that you remove
later.

Ok

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 9813fc440c70..7d58dfb3e5e8 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c

...


   +#ifdef CONFIG_XEN_GNTDEV_DMABUF

This code belongs in gntdev-dmabuf.c.

The reason I have this code here is that it is heavily
tied to gntdev's internal functionality, e.g. map/unmap.
I do not want to extend gntdev's API, so gntdev-dmabuf can
access these. What is more dma-buf doesn't need to know about
maps done by gntdev as there is no use of that information
in gntdev-dmabuf. So, it seems more naturally to have
dma-buf's related map/unmap code where it is: in gntdev.

Sorry, I don't follow. Why would this require extending the API? It's
just moving routines to a different file that is linked to the same module.

I do understand your intention here and tried to avoid dma-buf
related code in gntdev.c as much as possible. So, let me explain
my decision in more detail.

There are 2 use-cases we have: dma-buf import and export.

While importing a dma-buf all the dma-buf related functionality can
easily be kept inside gntdev-dmabuf.c w/o any issue as all we need
from gntdev.c is dev, dma_buf_fd, count and domid for that.

But in case of dma-buf export we need to:
1. struct grant_map *map = gntdev_alloc_map(priv, count, dmabuf_flags);
2. gntdev_add_map(priv, map);
3. Set map->flags
4. ret = map_grant_pages(map);
5. And only now we are all set to export the new dma-buf from *map->pages*

So, until 5) we use private gtndev.c's API not exported to outside world:
a. struct grant_map
b. static struct grant_map *gntdev_alloc_map(struct gntdev_priv *priv, 
int count,

                      int dma_flags)
c. static void gntdev_add_map(struct gntdev_priv *priv, struct grant_map 
*add)

d. static int map_grant_pages(struct grant_map *map)

Thus, all the above cannot be accessed from gntdev-dmabuf.c
This is why I say that gntdev.c's API will need to be extended to 
provide the above

a-d if we want all dma-buf export code to leave in gntdev-dmabuf.c.
But that doesn't seem good to me and what is more a-d are really gntdev.c's
functionality, not dma-buf's which only needs pages and doesn't really 
care from

where those come.
That was the reason I partitioned export into 2 chunks: gntdev + 
gntdev-dmabuf.


You might also ask why importing side does Xen related things (granting 
references+)

in gntdev-dmabuf, not gntdev so it is consistent with the dma-buf exporter?
This is because importer uses grant-table's API which seems to be not 
natural for gntdev.c,
so it can leave in gntdev-dmabuf.c which has a use-case for that, while 
gntdev

remains the same.

Since this is under CONFIG_XEN_GNTDEV_DMABUF then why shouldn't it be in
gntdev-dmabuf.c? In my view that's the file where all dma-related
"stuff" lives.
Agree, but IMO grant_map stuff for dma-buf importer is right in its 
place in gntdev.c

and all the rest of dma-buf specifics live in gntdev-dmabuf.c as they should


-boris


-boris


Thank you,
Oleksandr

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 linuxb0b357c20ca6171b8ac698351f5202402b7ad7d5
baseline version:
 linuxb87af3ab9dae0dc53b201701725ed6e2af4f2f74

Last test of basis   123274  2018-05-27 22:03:44 Z   10 days
Failing since123396  2018-05-30 06:10:32 Z8 days6 attempts
Testing same since   123480  2018-05-31 17:23:55 Z6 days5 attempts


People who touched revisions under test:
  "Huang, Ying" 
  Aaro Koskinen 
  Aaron Brown 
  Al Viro 
  Alan Stern 
  Alex Estrin 
  Alex Williamson 
  Alexander Potapenko 
  Alexandre Belloni 
  Alexey Dobriyan 
  Anders Roxell 
  Andrea Parri 
  Andrew Morton 
  Andrzej Hajda 
  

Re: [Xen-devel] Xen 4.11.0 RC5 test result

[Hao, Xudong]

Nested Xen on Xen, KVM on Xen, VMware on Xen, and hyperv on Xen all failed.
Already updated the result: 
https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen


Thanks,
-Xudong

From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
Sent: Tuesday, June 5, 2018 6:28 PM
To: Hao, Xudong ; xen-de...@lists.xen.org
Cc: Lars Kurth ; Juergen Gross ; 
Julien Grall 
Subject: Re: [Xen-devel] Xen 4.11.0 RC5 test result

On 05/06/18 09:49, Hao, Xudong wrote:

Except Nested, other feature all passed of testing.
https://wiki.xenproject.org/wiki/Nested_Virtualization_in_Xen

Do you have any further information?

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