Re: [Xen-devel] [livepatch-build-tools part2 v2 5/6] create-diff-object: Add new entries to special sections array array

[Wieczorkiewicz, Pawel]

On 16. Aug 2019, at 11:40, Ross Lagerwall 
mailto:ross.lagerw...@citrix.com>> wrote:

On 8/8/19 1:35 PM, Pawel Wieczorkiewicz wrote:


…snip...

  * The rela groups in the .fixup section vary in size.  The beginning of each
  * .fixup rela group is referenced by the .ex_table section. To find the size
@@ -1072,6 +1090,18 @@ static struct special_section special_sections[] = {
  .name = ".altinstructions",
  .group_size = altinstructions_group_size,
  },
+ {
+ .name = ".altinstr_replacement",
+ .group_size = undefined_group_size,
+ },
+ {
+ .name = ".livepatch.hooks.load",
+ .group_size = livepatch_hooks_group_size,
+ },
+ {
+ .name = ".livepatch.hooks.unload",
+ .group_size = livepatch_hooks_group_size,
+ },
  {},
 };


Unless I'm misunderstanding something, I can't see how 
kpatch_regenerate_special_section would work with .altinstr_replacement having 
a group size of 0. It looks to me like the for loop in that function would 
become an infinite loop (due to incrementing by group_size) and 
should_keep_rela_group would always return false.


AFAICS, the group_size 0 sections are never actually processed by the 
kpatch_regenerate_special_section().
They are not RELA sections and the following check excludes them from this 
processing:

static void kpatch_process_special_sections(struct kpatch_elf *kelf)
{
[…]
for (special = special_sections; special->name; special++) {
[…]

sec = sec->rela;
if (!sec)
continue;

kpatch_regenerate_special_section(kelf, special, sec);
}

Nevertheless, you are right. It does not make much sense to rely on this 
assumption.
I will add explicit checks to kpatch_regenerate_special_section() and friends 
dealing with group_size 0 sections.

Regards,
--
Ross Lagerwall

Best,
Pawel Wieczorkiewicz




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


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

Re: [Xen-devel] [PATCH] libxlu: Handle += in config files

[Wei Liu]

On Tue, Aug 13, 2019 at 05:42:15PM +0100, Anthony PERARD wrote:
> On Tue, Aug 13, 2019 at 04:47:23PM +0100, Andrew Cooper wrote:
> > Error between user and terminal. :)
> > 
> > I'd sync'd xl and libxl.so, but not libxlu.so
> 
> I actually made the same mistake first time I tried.
> 
> > Ok, so that is working now.  I think 'cmdline+=" dom0=pvh
> > dom0-iommu=none"' is slightly less tortured syntax, but I guess there is
> > no way that this isn't going to be horrible.
> > 
> > As for the general mechanism, how usable is += for anything other than
> > cmdline?  Most strings in config files can't usefully be extended in
> > this matter - if they need changing, they need changing wholesale.
> 
> That's true, but one could imaging some maybe bad example like adding a
> suffix to the name of the guest: "name+='-ovmf';".
> Going through `man xl.cfg', maybe a good example other than cmdline
> could be "cpus+=',^1'" but maybe a space is fine here, or one could use
> a list instead.
> Other potential uses could be for "PATH", but in this case it would be
> better reset the setting rather that attempting to add a suffix to an
> existing one.
> 
> I wonder if instead of doing += on all strings, we should instead have
> `xl' whitelist the few options where += would make sense. (and at that
> point, it would be easy to add a ' ' where is make sense, like
> "cmdline"s. But then, how to tell users that it can't do "name+='-new'"?
> because xlu would just print a warning, and xl would keep going with
> name="".  Try "xl create memory+=42" ;-).

Not sure I follow. Can you limit this in xl? Isn't += handled in libxlu
already?

Wei.

> 
> -- 
> Anthony PERARD

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

Re: [Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID

[Wei Liu]

On Thu, Aug 15, 2019 at 09:44:00AM +, Pawel Wieczorkiewicz wrote:
> Extend the list of xc() object methods with additional one to display
> Xen's buildid. The implementation follows the libxl implementation
> (e.g. max buildid size assumption being XC_PAGE_SIZE).
> 
> Signed-off-by: Pawel Wieczorkiewicz 
> Reviewed-by: Martin Mazein 
> Reviewed-by: Andra-Irina Paraschiv 
> Reviewed-by: Norbert Manthey 

I'm a bit confused by the tag in the subject line. Which series does
this patch belong to?

Wei.

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

[Xen-devel] [PATCH 08/11] swiotlb-xen: use the same foreign page check everywhere

[Christoph Hellwig]

xen_dma_map_page uses a different and more complicated check for
foreign pages than the other three cache maintainance helpers.
Switch it to the simpler pfn_vali method a well.

Signed-off-by: Christoph Hellwig 
---
 include/xen/page-coherent.h | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/include/xen/page-coherent.h b/include/xen/page-coherent.h
index 7c32944de051..0f4d468e7a89 100644
--- a/include/xen/page-coherent.h
+++ b/include/xen/page-coherent.h
@@ -43,14 +43,9 @@ static inline void xen_dma_map_page(struct device *hwdev, 
struct page *page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
 enum dma_data_direction dir, unsigned long attrs)
 {
-   unsigned long page_pfn = page_to_xen_pfn(page);
-   unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
-   unsigned long compound_pages =
-   (1

[Xen-devel] [PATCH 06/11] swiotlb-xen: always use dma-direct helpers to alloc coherent pages

[Christoph Hellwig]

x86 currently calls alloc_pages, but using dma-direct works as well
there, with the added benefit of using the CMA pool if available.
The biggest advantage is of course to remove a pointless bit of
architecture specific code.

Signed-off-by: Christoph Hellwig 
---
 arch/x86/include/asm/xen/page-coherent.h | 16 
 drivers/xen/swiotlb-xen.c|  7 +++
 include/xen/arm/page-coherent.h  | 12 
 3 files changed, 3 insertions(+), 32 deletions(-)

diff --git a/arch/x86/include/asm/xen/page-coherent.h 
b/arch/x86/include/asm/xen/page-coherent.h
index 116777e7f387..8ee33c5edded 100644
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ b/arch/x86/include/asm/xen/page-coherent.h
@@ -5,22 +5,6 @@
 #include 
 #include 
 
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-   dma_addr_t *dma_handle, gfp_t flags,
-   unsigned long attrs)
-{
-   void *vstart = (void*)__get_free_pages(flags, get_order(size));
-   *dma_handle = virt_to_phys(vstart);
-   return vstart;
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-   void *cpu_addr, dma_addr_t dma_handle,
-   unsigned long attrs)
-{
-   free_pages((unsigned long) cpu_addr, get_order(size));
-}
-
 static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
 enum dma_data_direction dir, unsigned long attrs) { }
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index b8808677ae1d..f9dd4cb6e4b3 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -299,8 +299,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
 * address. In fact on ARM virt_to_phys only works for kernel direct
 * mapped RAM memory. Also see comment below.
 */
-   ret = xen_alloc_coherent_pages(hwdev, size, dma_handle, flags, attrs);
-
+   ret = dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
if (!ret)
return ret;
 
@@ -319,7 +318,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
else {
if (xen_create_contiguous_region(phys, order,
 fls64(dma_mask), dma_handle) 
!= 0) {
-   xen_free_coherent_pages(hwdev, size, ret, 
(dma_addr_t)phys, attrs);
+   dma_direct_free(hwdev, size, ret, (dma_addr_t)phys, 
attrs);
return NULL;
}
SetPageXenRemapped(virt_to_page(ret));
@@ -351,7 +350,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
TestClearPageXenRemapped(virt_to_page(vaddr)))
xen_destroy_contiguous_region(phys, order);
 
-   xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
+   dma_direct_free(hwdev, size, vaddr, (dma_addr_t)phys, attrs);
 }
 
 /*
diff --git a/include/xen/arm/page-coherent.h b/include/xen/arm/page-coherent.h
index da2cc09c8eda..4294a31305ca 100644
--- a/include/xen/arm/page-coherent.h
+++ b/include/xen/arm/page-coherent.h
@@ -16,18 +16,6 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir);
 
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-   dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
-   return dma_direct_alloc(hwdev, size, dma_handle, flags, attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-   void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
-   dma_direct_free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
 static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-- 
2.20.1


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

[Xen-devel] [PATCH 07/11] swiotlb-xen: provide a single page-coherent.h header

[Christoph Hellwig]

Merge the various page-coherent.h files into a single one that either
provides prototypes or stubs depending on the need for cache
maintainance.

For extra benefits alo include  in the file
actually implementing the interfaces provided.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/include/asm/xen/page-coherent.h   |  2 --
 arch/arm/xen/mm.c  |  1 +
 arch/arm64/include/asm/xen/page-coherent.h |  2 --
 arch/x86/include/asm/xen/page-coherent.h   | 22 --
 drivers/xen/swiotlb-xen.c  |  4 +---
 include/Kbuild |  2 +-
 include/xen/{arm => }/page-coherent.h  | 27 +++---
 7 files changed, 27 insertions(+), 33 deletions(-)
 delete mode 100644 arch/arm/include/asm/xen/page-coherent.h
 delete mode 100644 arch/arm64/include/asm/xen/page-coherent.h
 delete mode 100644 arch/x86/include/asm/xen/page-coherent.h
 rename include/xen/{arm => }/page-coherent.h (76%)

diff --git a/arch/arm/include/asm/xen/page-coherent.h 
b/arch/arm/include/asm/xen/page-coherent.h
deleted file mode 100644
index 27e984977402..
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#include 
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index a59980f1aa54..85482cdda1e5 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/arch/arm64/include/asm/xen/page-coherent.h 
b/arch/arm64/include/asm/xen/page-coherent.h
deleted file mode 100644
index 27e984977402..
--- a/arch/arm64/include/asm/xen/page-coherent.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#include 
diff --git a/arch/x86/include/asm/xen/page-coherent.h 
b/arch/x86/include/asm/xen/page-coherent.h
deleted file mode 100644
index 8ee33c5edded..
--- a/arch/x86/include/asm/xen/page-coherent.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_X86_XEN_PAGE_COHERENT_H
-#define _ASM_X86_XEN_PAGE_COHERENT_H
-
-#include 
-#include 
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs) { }
-
-static inline void xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-   size_t size, enum dma_data_direction dir,
-   unsigned long attrs) { }
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
-   dma_addr_t handle, size_t size, enum dma_data_direction dir) { }
-
-static inline void xen_dma_sync_single_for_device(struct device *hwdev,
-   dma_addr_t handle, size_t size, enum dma_data_direction dir) { }
-
-#endif /* _ASM_X86_XEN_PAGE_COHERENT_H */
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index f9dd4cb6e4b3..7b23929854e7 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -31,12 +31,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 /*
  * Used to do a quick range check in swiotlb_tbl_unmap_single and
diff --git a/include/Kbuild b/include/Kbuild
index c38f0d46b267..e2ae52ef9e1e 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -1189,7 +1189,6 @@ header-test-  += video/vga.h
 header-test-   += video/w100fb.h
 header-test-   += xen/acpi.h
 header-test-   += xen/arm/hypercall.h
-header-test-   += xen/arm/page-coherent.h
 header-test-   += xen/arm/page.h
 header-test-   += xen/balloon.h
 header-test-   += xen/events.h
@@ -1231,6 +1230,7 @@ header-test-  += xen/interface/xen.h
 header-test-   += xen/interface/xenpmu.h
 header-test-   += xen/mem-reservation.h
 header-test-   += xen/page.h
+header-test-   += xen/page-coherent.h
 header-test-   += xen/platform_pci.h
 header-test-   += xen/swiotlb-xen.h
 header-test-   += xen/xen-front-pgdir-shbuf.h
diff --git a/include/xen/arm/page-coherent.h b/include/xen/page-coherent.h
similarity index 76%
rename from include/xen/arm/page-coherent.h
rename to include/xen/page-coherent.h
index 4294a31305ca..7c32944de051 100644
--- a/include/xen/arm/page-coherent.h
+++ b/include/xen/page-coherent.h
@@ -1,10 +1,12 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _XEN_ARM_PAGE_COHERENT_H
-#define _XEN_ARM_PAGE_COHERENT_H
+#ifndef _XEN_PAGE_COHERENT_H
+#define _XEN_PAGE_COHERENT_H
 
 #include 
 #include 
 
+#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
+defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU)
 void __xen_dma_map_page(struct device *hwdev, struct page *page,
 dma_addr_t dev_addr, unsigned long 

[Xen-devel] [PATCH 05/11] xen: remove the exports for xen_{create, destroy}_contiguous_region

[Christoph Hellwig]

These routines are only used by swiotlb-xen, which cannot be modular.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/xen/mm.c | 2 --
 arch/x86/xen/mmu_pv.c | 2 --
 2 files changed, 4 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 388a45002bad..a59980f1aa54 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -175,13 +175,11 @@ int xen_create_contiguous_region(phys_addr_t pstart, 
unsigned int order,
*dma_handle = pstart;
return 0;
 }
-EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
 
 void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
 {
return;
 }
-EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
 int __init xen_mm_init(void)
 {
diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 26e8b326966d..c8dbee62ec2a 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -2625,7 +2625,6 @@ int xen_create_contiguous_region(phys_addr_t pstart, 
unsigned int order,
*dma_handle = virt_to_machine(vstart).maddr;
return success ? 0 : -ENOMEM;
 }
-EXPORT_SYMBOL_GPL(xen_create_contiguous_region);
 
 void xen_destroy_contiguous_region(phys_addr_t pstart, unsigned int order)
 {
@@ -2660,7 +2659,6 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, 
unsigned int order)
 
spin_unlock_irqrestore(_reservation_lock, flags);
 }
-EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
 static noinline void xen_flush_tlb_all(void)
 {
-- 
2.20.1


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

[Xen-devel] [PATCH 09/11] swiotlb-xen: simplify cache maintainance

[Christoph Hellwig]

Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore the value returned from it.  Instead we now have
Xen wrappers for the arch_sync_dma_for_{device,cpu} helpers that call
the special Xen versions of those routines for foreign pages.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/xen/mm.c   |  47 ++---
 drivers/xen/swiotlb-xen.c   |  19 ---
 include/xen/page-coherent.h | 100 +++-
 3 files changed, 42 insertions(+), 124 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 85482cdda1e5..0eb88f1355c2 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -86,59 +86,18 @@ static void dma_cache_maint(dma_addr_t handle, size_t size,
} while (left);
 }
 
-static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
-   size_t size, enum dma_data_direction dir)
+void __xen_dma_sync_for_cpu(struct device *dev, dma_addr_t handle, size_t size,
+   enum dma_data_direction dir)
 {
dma_cache_maint(handle, size, dir, DMA_UNMAP);
 }
 
-static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
+void __xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
 {
dma_cache_maint(handle, size, dir, DMA_MAP);
 }
 
-void __xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
-   if (dev_is_dma_coherent(hwdev))
-   return;
-   if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
-   return;
-
-   __xen_dma_page_cpu_to_dev(hwdev, dev_addr, size, dir);
-}
-
-void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t handle,
-   size_t size, enum dma_data_direction dir,
-   unsigned long attrs)
-
-{
-   if (dev_is_dma_coherent(hwdev))
-   return;
-   if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
-   return;
-
-   __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_cpu(struct device *hwdev,
-   dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-   if (dev_is_dma_coherent(hwdev))
-   return;
-   __xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
-}
-
-void __xen_dma_sync_single_for_device(struct device *hwdev,
-   dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-   if (dev_is_dma_coherent(hwdev))
-   return;
-   __xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
-}
-
 bool xen_arch_need_swiotlb(struct device *dev,
   phys_addr_t phys,
   dma_addr_t dev_addr)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 7b23929854e7..c3c383033ae4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -388,6 +388,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
if (map == (phys_addr_t)DMA_MAPPING_ERROR)
return DMA_MAPPING_ERROR;
 
+   phys = map;
dev_addr = xen_phys_to_bus(map);
 
/*
@@ -399,14 +400,9 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
return DMA_MAPPING_ERROR;
}
 
-   page = pfn_to_page(map >> PAGE_SHIFT);
-   offset = map & ~PAGE_MASK;
 done:
-   /*
-* we are not interested in the dma_addr returned by xen_dma_map_page,
-* only in the potential cache flushes executed by the function.
-*/
-   xen_dma_map_page(dev, page, dev_addr, offset, size, dir, attrs);
+   if (!dev_is_dma_coherent(dev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+   xen_dma_sync_for_device(dev, dev_addr, phys, size, dir);
return dev_addr;
 }
 
@@ -426,7 +422,8 @@ static void xen_unmap_single(struct device *hwdev, 
dma_addr_t dev_addr,
 
BUG_ON(dir == DMA_NONE);
 
-   xen_dma_unmap_page(hwdev, dev_addr, size, dir, attrs);
+   if (!dev_is_dma_coherent(hwdev) && !(attrs & DMA_ATTR_SKIP_CPU_SYNC))
+   xen_dma_sync_for_cpu(hwdev, dev_addr, paddr, size, dir);
 
/* NOTE: We use dev_addr here, not paddr! */
if (is_xen_swiotlb_buffer(dev_addr))
@@ -446,7 +443,8 @@ xen_swiotlb_sync_single_for_cpu(struct device *dev, 
dma_addr_t dma_addr,
 {
phys_addr_t paddr = xen_bus_to_phys(dma_addr);
 
-   xen_dma_sync_single_for_cpu(dev, dma_addr, size, dir);
+   if (!dev_is_dma_coherent(dev))
+   xen_dma_sync_for_cpu(dev, dma_addr, paddr, size, dir);
 
if (is_xen_swiotlb_buffer(dma_addr))

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

[osstest service owner]

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

Regressions :-(

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

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-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  49520e9e7d1c8e309ca71ccc49811fcfc1f26bb7
baseline version:
 libvirt  086764748e1a6b9aaf968db68145e05837eae3bd

Last test of basis   139829  2019-08-08 04:19:02 Z8 days
Failing since139853  2019-08-09 04:24:11 Z7 days8 attempts
Testing same since   140186  2019-08-16 04:19:11 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Daniel Henrique Barboza 
  Daniel P. Berrangé 
  Eric Blake 
  Han Han 
  Ilias Stamatis 
  Jiri Denemark 
  Ján Tomko 
  Laine Stump 
  Marc-André Lureau 
  Maxiwell S. Garcia 
  Menno Lageman 
  Michal Privoznik 
  Paolo Bonzini 
  Peter Krempa 
  Roman Bolshakov 
  Wim ten Have 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   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
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 

[Xen-devel] [PATCH 11/11] arm64: use asm-generic/dma-mapping.h

[Christoph Hellwig]

Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64  file, so switch to use the
asm-generic version instead.

Signed-off-by: Christoph Hellwig 
---
 arch/arm64/include/asm/Kbuild|  1 +
 arch/arm64/include/asm/dma-mapping.h | 22 --
 arch/arm64/mm/dma-mapping.c  |  1 +
 3 files changed, 2 insertions(+), 22 deletions(-)
 delete mode 100644 arch/arm64/include/asm/dma-mapping.h

diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index c52e151afab0..98a5405c8558 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -4,6 +4,7 @@ generic-y += delay.h
 generic-y += div64.h
 generic-y += dma.h
 generic-y += dma-contiguous.h
+generic-y += dma-mapping.h
 generic-y += early_ioremap.h
 generic-y += emergency-restart.h
 generic-y += hw_irq.h
diff --git a/arch/arm64/include/asm/dma-mapping.h 
b/arch/arm64/include/asm/dma-mapping.h
deleted file mode 100644
index 67243255a858..
--- a/arch/arm64/include/asm/dma-mapping.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Copyright (C) 2012 ARM Ltd.
- */
-#ifndef __ASM_DMA_MAPPING_H
-#define __ASM_DMA_MAPPING_H
-
-#ifdef __KERNEL__
-
-#include 
-#include 
-
-#include 
-#include 
-
-static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
-{
-   return NULL;
-}
-
-#endif /* __KERNEL__ */
-#endif /* __ASM_DMA_MAPPING_H */
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 4b244a037349..6578abcfbbc7 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
-- 
2.20.1


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

[Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Lars Kurth]

Unikraft repos follow the same syntax as xen.git with the
following exceptions:
* MAINTAINERS files are called MAINTAINERS.md
* M: ... etc blocks are preceded by whitespaces for rendering as
  markup files

This change will
- load MAINTAINERS.md if MAINTAINERS is not present
- deal with indented M: ... blocks

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

CC: Simon Kuenzer 
CC: Florian Schmidt 
CC: Felipe Huici 
---
 scripts/get_maintainer.pl | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index f1e9c904ee..bdb09f8f65 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
 my @typevalue = ();
 my %keyword_hash;
 
-open (my $maint, '<', "${xen_path}MAINTAINERS")
-or die "$P: Can't open MAINTAINERS: $!\n";
+my $maint;
+my $maintainers_file = "MAINTAINERS";
+if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
+$maintainers_file = "MAINTAINERS.md";
+open ($maint, '<', ${xen_path}.$maintainers_file)
+or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
+}
+
 while (<$maint>) {
 my $line = $_;
 
-if ($line =~ m/^([A-Z]):\s*(.*)/) {
+if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {
my $type = $1;
my $value = $2;
 
@@ -421,7 +427,7 @@ foreach my $file (@ARGV) {
 }
 if ($from_filename) {
push(@files, $file);
-   if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
+   if ($file ne $maintainers_file && -f $file && ($keywords || 
$file_emails)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };
-- 
2.13.0


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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Lars Kurth]

Hi Julien,

On 16/08/2019, 11:55, "Julien Grall"  wrote:

Hi Lars,

On 16/08/2019 11:42, Lars Kurth wrote:
> Unikraft repos follow the same syntax as xen.git with the
> following exceptions:
> * MAINTAINERS files are called MAINTAINERS.md
> * M: ... etc blocks are preceded by whitespaces for rendering as
>markup files

There is an other difference. The "fallback" category is "UNIKRAFT GENERAL" 
and 
not "THE REST".

That is right. But currently get_maintainers.pl: totally ignores the headlines. 
It just reads
M: ...
R: ...
Etc.

What is different is that "UNIKRAFT GENERAL" does not contain
F: entries, which have to be added, otherwise no e-mail addresses
from the section are added. So I was going to send a patch to fix this.

> This change will
> - load MAINTAINERS.md if MAINTAINERS is not present
> - deal with indented M: ... blocks

One process question. Does it mean Unikraft folks will have to checkout Xen 
in 
order to use {add, get}_maintainers.pl? If so, would it make sense to have 
add_maintainers.pl and script_maintainers.pl in a separate repo that can be 
added as submodule?

The way how the code is written they would either have to check out the 
repo or just get the two scripts and put them in the same directory somewhere
on the path.

For things like mini-os, xtf, osstest, ... you would always have a xen.git 
somewhere
In the unikraft case that is different. We could break it out, but maybe we can 
do this
at a later point in time.

> Signed-off-by: Lars Kurth 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> 
> CC: Simon Kuenzer 
> CC: Florian Schmidt 
> CC: Felipe Huici 
> ---
>   scripts/get_maintainer.pl | 14 ++
>   1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index f1e9c904ee..bdb09f8f65 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
>   my @typevalue = ();
>   my %keyword_hash;
>   
> -open (my $maint, '<', "${xen_path}MAINTAINERS")
> -or die "$P: Can't open MAINTAINERS: $!\n";
> +my $maint;
> +my $maintainers_file = "MAINTAINERS";
> +if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
> +$maintainers_file = "MAINTAINERS.md";
> +open ($maint, '<', ${xen_path}.$maintainers_file)
> +or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
> +}
> +
>   while (<$maint>) {
>   my $line = $_;
>   
> -if ($line =~ m/^([A-Z]):\s*(.*)/) {
> +if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {

As you allow space before the blocks M:, would not this catch the example 
at the 
beginning of the file?

M: Mail patches to: FullName 
R: Designated reviewer: FullName 

Good point. When I tested it (I sent the last few patches with the change in 
it), 
it didn't pick up the e-mail addresses. However, when I check with regex101.com
it is picked up.

Which means that the values are pushed to @typevalue, aka
{ "R",  "Designated reviewer: FullName " }
Etc.

@typevalue seem to be processed by find_first_section(), 
find_starting_index(), find_ending_index() 

And then basically the entries are not processed because the
block in the example is not consistent and fails the validation
further down the line

For example:
./scripts/get_maintainer.pl --email --git -f .
Etc.

Don't list the e-mail addresses in the examples

So, what I proposed is probably far too fragile to make sense.
And doing something which is more accurate will probably 
require major surgery to the scripts.

I can look at this in a bit more detail and see whether there
is a way to handle this.

But I don't want to invest the time to do this really as this
is probably rather complex.

@Simon, @Florian, @Felipe: would you be willing to
change the MAINTAINERS files in your repos such that
we don't have to implement lots of magic to make the
patch sending helper scripts work for you?

Regards
Lars

   

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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Paul Durrant]

> -Original Message-
> From: Lars Kurth 
> Sent: 16 August 2019 13:20
> To: Paul Durrant ; Anthony Perard 
> ; Julien Grall
> 
> Cc: xen-devel@lists.xenproject.org; Felipe Huici ; 
> Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk 
> ; George
> Dunlap ; Andrew Cooper ; 
> Ian Jackson
> ; Tim (Xen.org) ; Florian Schmidt 
> ;
> Jan Beulich ; Simon Kuenzer 
> Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the 
> script on unikraft repos
> 
> 
> 
> On 16/08/2019, 13:09, "Paul Durrant"  wrote:
> 
> > -Original Message-
> > From: Lars Kurth 
> > Sent: 16 August 2019 13:05
> > To: Anthony Perard ; Julien Grall 
> 
> > Cc: xen-devel@lists.xenproject.org; Felipe Huici 
> ; Stefano Stabellini
> > ; Wei Liu ; Konrad Rzeszutek Wilk 
> ;
> George
> > Dunlap ; Andrew Cooper 
> ; Ian Jackson
> > ; Tim (Xen.org) ; Florian Schmidt
> ;
> > Jan Beulich ; Simon Kuenzer 
> ; Paul Durrant
> > 
> > Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the 
> script on unikraft repos
> >
> > Added Paul Durrant
> >
> > On 16/08/2019, 12:17, "Anthony PERARD"  
> wrote:
> >
> > On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> > > Hi Lars,
> > >
> > > On 16/08/2019 11:42, Lars Kurth wrote:
> > > > Unikraft repos follow the same syntax as xen.git with the
> > > > following exceptions:
> > > > * MAINTAINERS files are called MAINTAINERS.md
> > > > * M: ... etc blocks are preceded by whitespaces for rendering as
> > > >markup files
> > >
> > > There is an other difference. The "fallback" category is 
> "UNIKRAFT GENERAL"
> > > and not "THE REST".
> > >
> > > >
> > > > This change will
> > > > - load MAINTAINERS.md if MAINTAINERS is not present
> > > > - deal with indented M: ... blocks
> > >
> > > One process question. Does it mean Unikraft folks will have to 
> checkout Xen
> > > in order to use {add, get}_maintainers.pl? If so, would it make 
> sense to
> > > have add_maintainers.pl and script_maintainers.pl in a separate 
> repo that
> > > can be added as submodule?
> >
> > Shouldn't instead the Unikraft repo have it's one get_maintainers
> > script? xen.git's script doesn't needs to have support for every 
> single
> > repo available on earth and Unikraft is a different project anyway.
> >
> > Usually, projects with a MAINTAINERS file have there own 
> get_maintainers
> > script.
> >
> > Well: Unikraft is part of the Xen Project.
> >
> > When I started to clean up the contribution docs it became apparent that
> > there is a lot of inconsistency. Ideally our contribution guide [0] 
> would apply
> > to pretty much *all* sub projects which use a mailing list based 
> workflows
> >
> > Consistency makes life for developers and also newcomers much easier. 
> And the
> > number of new devs who seem to trip over inconsistencies between 
> projects are
> > quite large (we had 3  cases in 3 weeks which I noticed).
> >
> > If we start improving our CI infrastructure (which we are), it would be 
> nice if other
> > sub projects had the possibility to easily hook into it or replicate 
> it. But that does require
> > some consistency.
> >
> > That's why I submitted [1] and [2]
> >
> > Sub-projects with mail based workflows
> > 1: Hypervisor
> > 2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
> > 3: Windows PV Drivers - which will require changes to their MAINTAINERS 
> file
> > 4: Unikraft
> >
> > Supporting 1 - 3 should be straightforward because you would almost 
> always
> > have xen.git checked out. 4 is more different.
> 
> I'd say that folks building 3 are unlikely to have xen.git checked out.
> 
> Good to know
> 
> If there was tooling available that simplifies your workflow, would
> members of the Windows PV Drivers sub-project be willing to use them?
> 

Sure, but our MAINTAINERS files are trivial, and most code changes are made by 
Owen and myself anyway. Not sure there's really a need for any extra tooling.

> It maybe that for Windows PV Drivers the workflow is not at all command
> line based and people tend to use an IDE instead.
> 

Some folks may use the Visual Studio IDE. I don't, and the Jenkins build 
workers do rely on the python (pre-9.0) or powershell (9.0 onwards) scripts so 
building via command line does need to be tested by contributors.

  Paul

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

Re: [Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism

[Wei Liu]

On Thu, Aug 15, 2019 at 11:27:50AM +, Pawel Wieczorkiewicz wrote:
> Extend the livepatch list operation to fetch also payloads' metadata.
> This is achieved by extending the sysctl list interface with 2 extra
> guest handles:
> * metadata - an array of arbitrary size strings
> * metadata_len - an array of metadata strings' lengths (uin32_t each)
> 
> Payloads' metadata is a string of arbitrary size and does not have an
> upper bound limit. It may also vary in size between payloads.
> 
> In order to let the userland allocate enough space for the incoming
> data add a metadata total size field to the list sysctl operation and
> fill it with total size of all payloads' metadata.
> 
> Extend the libxc to handle the metadata back-to-back data transfers
> as well as metadata length array data transfers.
> 
> The xen-livepatch userland tool is extended to always display the
> metadata for each received module. The metadata is received with the
> following format: key=value\0key=value\0...key=value\0. The format is
> modified to the following one: key=value;key=value;...key=value.
> The new format allows to easily parse the metadata for a given module
> by a machine.
> 
> Signed-off-by: Pawel Wieczorkiewicz 
> Reviewed-by: Andra-Irina Paraschiv 
> Reviewed-by: Martin Pohlack 
> Reviewed-by: Norbert Manthey 
> ---
>  tools/libxc/include/xenctrl.h | 22 +++
>  tools/libxc/xc_misc.c | 66 
> +++
>  tools/misc/xen-livepatch.c| 43 ++--
>  xen/common/livepatch.c| 22 +++
>  xen/include/public/sysctl.h   | 19 +

Mostly look good. One comment below...

> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index b86804b7a6..e4c8f4fe63 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h

If it hasn't been done for this release already, changing sysctl interface 
requires
bumping the version number in this header.

Wei.

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

Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

[Julien Grall]

On 16/08/2019 13:17, Lars Kurth wrote:

On 16/08/2019, 11:01, "Julien Grall"  wrote:
  From my understanding, any use on mini-os.git & co will be legitimate. 
However,
 we still print the WARNING in those cases.
 
 Usually WARNING means something needs attention. As most of the users will

 likely copy/paste from the wiki, we are going to have report asking why the
 WARNING is there.
 
 I think it would make sense to try to downgrade the message a bit when possible.

 For instance, we could check if the section "THE REST" is present in the 
file
 MAINTAINERS. If not, this is likely not a file we are able to support.
 
I thought about this and it is not as easy as it seems, because the script only parses

M: ...  lines


The script is able to parse the section name. See get_maintainer_role().

Although, I am not sure how early the function can get called.

But...



Maybe the best way to address this would be to include some identifier into the
MAINTAINERS file (after the header with all the definitions).

FORMAT: xen-project-maintainers 
(note that this is not currently picked up by the tool)

Or

V: xen-project-maintainers 
(note that this would be picked up by the tool)


Any of these solutions are also a potential alternative.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Julien Grall]

Hi Lars,

On 16/08/2019 11:42, Lars Kurth wrote:

Unikraft repos follow the same syntax as xen.git with the
following exceptions:
* MAINTAINERS files are called MAINTAINERS.md
* M: ... etc blocks are preceded by whitespaces for rendering as
   markup files


There is an other difference. The "fallback" category is "UNIKRAFT GENERAL" and 
not "THE REST".




This change will
- load MAINTAINERS.md if MAINTAINERS is not present
- deal with indented M: ... blocks


One process question. Does it mean Unikraft folks will have to checkout Xen in 
order to use {add, get}_maintainers.pl? If so, would it make sense to have 
add_maintainers.pl and script_maintainers.pl in a separate repo that can be 
added as submodule?




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

CC: Simon Kuenzer 
CC: Florian Schmidt 
CC: Felipe Huici 
---
  scripts/get_maintainer.pl | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index f1e9c904ee..bdb09f8f65 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
  my @typevalue = ();
  my %keyword_hash;
  
-open (my $maint, '<', "${xen_path}MAINTAINERS")

-or die "$P: Can't open MAINTAINERS: $!\n";
+my $maint;
+my $maintainers_file = "MAINTAINERS";
+if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
+$maintainers_file = "MAINTAINERS.md";
+open ($maint, '<', ${xen_path}.$maintainers_file)
+or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
+}
+
  while (<$maint>) {
  my $line = $_;
  
-if ($line =~ m/^([A-Z]):\s*(.*)/) {

+if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {


As you allow space before the blocks M:, would not this catch the example at the 
beginning of the file?


M: Mail patches to: FullName 
R: Designated reviewer: FullName 


my $type = $1;
my $value = $2;
  
@@ -421,7 +427,7 @@ foreach my $file (@ARGV) {

  }
  if ($from_filename) {
push(@files, $file);
-   if ($file ne "MAINTAINERS" && -f $file && ($keywords || $file_emails)) {
+   if ($file ne $maintainers_file && -f $file && ($keywords || 
$file_emails)) {
open(my $f, '<', $file)
or die "$P: Can't open $file: $!\n";
my $text = do { local($/) ; <$f> };



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE

[David Gibson]

On Fri, Aug 16, 2019 at 11:58:05AM +0200, Philippe Mathieu-Daudé wrote:
> Hi Tony,
> 
> On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote:
> > This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE.
> > 
> > v7:
> [...]
> > - Re-declared many native endian devices as little or big endian. This is 
> > why
> >   v7 has +16 patches.
> 
> Why are you doing that? What is the rational?
> 
> Anyhow if this not required by your series, you should split it out of
> it, and send it on your principal changes are merged.
> I'm worried because this these new patches involve many subsystems (thus
> maintainers) and reviewing them will now take a fair amount of time.
> 
> > For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
> > targets from the set of target/hw/*/device.o.
> >
> > If the set of targets are all little or all big endian, re-declare
> > the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
> > respectively.
> 
> If only little endian targets use a device, that doesn't mean the device
> is designed in little endian...
> 
> Then if a big endian target plan to use this device, it will require
> more work and you might have introduced regressions...

Uh.. only if they make the version of the device on a big endian
target big endian.  Which is a terrible idea - if you know a hardware
designer planning to do this, please slap them.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


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] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Lars Kurth]

Added Paul Durrant

On 16/08/2019, 12:17, "Anthony PERARD"  wrote:

On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> Hi Lars,
> 
> On 16/08/2019 11:42, Lars Kurth wrote:
> > Unikraft repos follow the same syntax as xen.git with the
> > following exceptions:
> > * MAINTAINERS files are called MAINTAINERS.md
> > * M: ... etc blocks are preceded by whitespaces for rendering as
> >markup files
> 
> There is an other difference. The "fallback" category is "UNIKRAFT 
GENERAL"
> and not "THE REST".
> 
> > 
> > This change will
> > - load MAINTAINERS.md if MAINTAINERS is not present
> > - deal with indented M: ... blocks
> 
> One process question. Does it mean Unikraft folks will have to checkout 
Xen
> in order to use {add, get}_maintainers.pl? If so, would it make sense to
> have add_maintainers.pl and script_maintainers.pl in a separate repo that
> can be added as submodule?

Shouldn't instead the Unikraft repo have it's one get_maintainers
script? xen.git's script doesn't needs to have support for every single
repo available on earth and Unikraft is a different project anyway.

Usually, projects with a MAINTAINERS file have there own get_maintainers
script.

Well: Unikraft is part of the Xen Project. 

When I started to clean up the contribution docs it became apparent that
there is a lot of inconsistency. Ideally our contribution guide [0] would apply 
to pretty much *all* sub projects which use a mailing list based workflows

Consistency makes life for developers and also newcomers much easier. And the 
number of new devs who seem to trip over inconsistencies between projects are 
quite large (we had 3  cases in 3 weeks which I noticed).

If we start improving our CI infrastructure (which we are), it would be nice if 
other 
sub projects had the possibility to easily hook into it or replicate it. But 
that does require 
some consistency.

That's why I submitted [1] and [2]

Sub-projects with mail based workflows
1: Hypervisor
2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
3: Windows PV Drivers - which will require changes to their MAINTAINERS file 
4: Unikraft

Supporting 1 - 3 should be straightforward because you would almost always
have xen.git checked out. 4 is more different.

When I did [1] supporting Unikraft looked quite straightforward, which is
why I submitted this patch. But, given the issues Julien highlighted maybe that 
is not the case. 

I think for now, maybe we should focus on 1 - 3 and let the Unikraft devs 
decide 
how to approach this. Then we can revisit the question of where to store these
scripts. For now, I think requiring to have xen.git checked out is OK.

Regards
Lars

[0] https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches 
[1] 
https://lists.xenproject.org/archives/html/xen-devel/2019-08/threads.html#01575
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2019-08/threads.html#01581


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

Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

[Lars Kurth]

On 16/08/2019, 11:01, "Julien Grall"  wrote:

Hi Lars,

Thank you for the patch.

On 15/08/2019 18:22, Lars Kurth wrote:
> Use-case: Allow using both scripts on xen repositories such as
> mini-os.git, osstest.git,
> 
> Tool changes:
> * add_maintainers.pl: $get_maintainer inherits path from $0
> * get_maintainer.pl: warn (instead fo die) when called
>from a different tree
> 
> Assumptions: the repository contains a MAINTAINERS file that
> follows the same conventions as the file in xen.git
> 
> A suggested template
> 
> 
> This file follows the same conventions as outlined in
> xen.git:MAINTAINERS. Please refer to the file in xen.git
> for more information.
> 
> THE REST
> M:MAINTAINER1 
> M:  MAINTAINER2 
> L:xen-devel@lists.xenproject.org
> S:Supported
> F:*/
> 
> 
> Signed-off-by: Lars Kurth 
> ---
>   scripts/add_maintainers.pl |  4 ++--
>   scripts/get_maintainer.pl  | 13 +++--
>   2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/scripts/add_maintainers.pl b/scripts/add_maintainers.pl
> index 09e9f6609f..5a6d0f631b 100755
> --- a/scripts/add_maintainers.pl
> +++ b/scripts/add_maintainers.pl
> @@ -26,9 +26,9 @@ sub insert ();
>   sub hastag ($$);
>   
>   # Tool Variables
> -my $get_maintainer  = "./scripts/get_maintainer.pl";
> -
>   my $tool = $0;
> +my $get_maintainer = $tool;
> +$get_maintainer =~ s/add_maintainers/get_maintainer/;
>   my $usage = <   OPTIONS:
>   
> diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
> index 174dfb7e40..f1e9c904ee 100755
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -266,8 +266,17 @@ if ($email &&
>   }
>   
>   if (!top_of_tree($xen_path)) {
> -die "$P: The current directory does not appear to be "
> - . "a Xen source tree.\n";
> +# Do not exit, but print an error message to STDERR to allow calling
> +# the tool from xen-related repos such as mini-os.git,
> +# live patch-build-tools.git, etc
> +print STDERR "$P:\n".
> +  "=\n".
> +  "WARNING: The current directory does not appear to be \n".
> +   "the xen.git source tree.\n\n".
> +  "The tool works outside of the xen.git tree, if the\n".
> +  "MAINTAINERS file follows the same format as that of\n".
> +  "xen.git. Use at your own peril.\n".
> +  "=\n";

 From my understanding, any use on mini-os.git & co will be legitimate. 
However, 
we still print the WARNING in those cases.

Usually WARNING means something needs attention. As most of the users will 
likely copy/paste from the wiki, we are going to have report asking why the 
WARNING is there.

I think it would make sense to try to downgrade the message a bit when 
possible. 
For instance, we could check if the section "THE REST" is present in the 
file 
MAINTAINERS. If not, this is likely not a file we are able to support.

I thought about this and it is not as easy as it seems, because the script only 
parses
M: ...  lines

Maybe the best way to address this would be to include some identifier into the
MAINTAINERS file (after the header with all the definitions). 

FORMAT: xen-project-maintainers   
(note that this is not currently picked up by the tool)

Or

V: xen-project-maintainers   
(note that this would be picked up by the tool)

Then any compliant version is easily identifiable and the warning can be 
supressed.

That would make maintainers look like 



V:  xen-project-maintainers 1.6

ACPI
M:  Jan Beulich   
...


This seems to be more of a can of worms than I thought.

Cheers
Lars


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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Julien Grall]

On 16/08/2019 12:41, Lars Kurth wrote:

Hi Julien,


Hi Lars,



On 16/08/2019, 11:55, "Julien Grall"  wrote:

 Hi Lars,
 
 On 16/08/2019 11:42, Lars Kurth wrote:

 > Unikraft repos follow the same syntax as xen.git with the
 > following exceptions:
 > * MAINTAINERS files are called MAINTAINERS.md
 > * M: ... etc blocks are preceded by whitespaces for rendering as
 >markup files
 
 There is an other difference. The "fallback" category is "UNIKRAFT GENERAL" and

 not "THE REST".

That is right. But currently get_maintainers.pl: totally ignores the headlines.
It just reads
M: ...
R: ...
Etc.


Not really, get_maintainer_role() will return the headline. This is for instance 
used to avoid CC "THE REST" when there are other maintainers:


# Check the role, if it is not "THE REST" then the file is not
# only maintained by "THE REST".
if ( get_maintainer_role($line) ne "supporter:THE REST" ) {
$file_maintained_by_the_rest = 0;
}

From my understanding "UNIKRAFT GENERAL" behaves exactly the same way.

The roles can also be printed with the option --roles.



What is different is that "UNIKRAFT GENERAL" does not contain
F: entries, which have to be added, otherwise no e-mail addresses
from the section are added. So I was going to send a patch to fix this.
 
 > This change will

 > - load MAINTAINERS.md if MAINTAINERS is not present
 > - deal with indented M: ... blocks
 
 One process question. Does it mean Unikraft folks will have to checkout Xen in

 order to use {add, get}_maintainers.pl? If so, would it make sense to have
 add_maintainers.pl and script_maintainers.pl in a separate repo that can be
 added as submodule?

The way how the code is written they would either have to check out the
repo or just get the two scripts and put them in the same directory somewhere
on the path.

For things like mini-os, xtf, osstest, ... you would always have a xen.git 
somewhere
In the unikraft case that is different. We could break it out, but maybe we can 
do this
at a later point in time.


Fair point.



 > Signed-off-by: Lars Kurth 
 > ---
 > Cc: Andrew Cooper 
 > Cc: George Dunlap 
 > Cc: Ian Jackson 
 > Cc: Jan Beulich 
 > Cc: Julien Grall 
 > Cc: Konrad Rzeszutek Wilk 
 > Cc: Stefano Stabellini 
 > Cc: Tim Deegan 
 > Cc: Wei Liu 
 >
 > CC: Simon Kuenzer 
 > CC: Florian Schmidt 
 > CC: Felipe Huici 
 > ---
 >   scripts/get_maintainer.pl | 14 ++
 >   1 file changed, 10 insertions(+), 4 deletions(-)
 >
 > diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
 > index f1e9c904ee..bdb09f8f65 100755
 > --- a/scripts/get_maintainer.pl
 > +++ b/scripts/get_maintainer.pl
 > @@ -284,12 +284,18 @@ if (!top_of_tree($xen_path)) {
 >   my @typevalue = ();
 >   my %keyword_hash;
 >
 > -open (my $maint, '<', "${xen_path}MAINTAINERS")
 > -or die "$P: Can't open MAINTAINERS: $!\n";
 > +my $maint;
 > +my $maintainers_file = "MAINTAINERS";
 > +if (! open ($maint, '<', ${xen_path}.$maintainers_file)) {
 > +$maintainers_file = "MAINTAINERS.md";
 > +open ($maint, '<', ${xen_path}.$maintainers_file)
 > +or die "$P: Can't open MAINTAINERS or MAINTAINERS.md: $!\n";
 > +}
 > +
 >   while (<$maint>) {
 >   my $line = $_;
 >
 > -if ($line =~ m/^([A-Z]):\s*(.*)/) {
 > +if ($line =~ m/^\s*([A-Z]):\s*(.*)/) {
 
 As you allow space before the blocks M:, would not this catch the example at the

 beginning of the file?
 
 	M: Mail patches to: FullName 

R: Designated reviewer: FullName 

Good point. When I tested it (I sent the last few patches with the change in 
it),
it didn't pick up the e-mail addresses. However, when I check with regex101.com
it is picked up.

Which means that the values are pushed to @typevalue, aka
{ "R",  "Designated reviewer: FullName " }
Etc.

@typevalue seem to be processed by find_first_section(),
find_starting_index(), find_ending_index()

And then basically the entries are not processed because the
block in the example is not consistent and fails the validation
further down the line

For example:
./scripts/get_maintainer.pl --email --git -f .
Etc.

Don't list the e-mail addresses in the examples
 
So, what I proposed is probably far too fragile to make sense.

And doing something which is more accurate will probably
require major surgery to the scripts.

I can look at this in a bit more detail and see whether there
is a way to handle this.

But I don't want to invest the time to do this really as this
is probably rather complex.

@Simon, @Florian, @Felipe: would you be willing to
change the MAINTAINERS files in your repos such that
we don't have to implement lots of magic to make the
patch sending helper scripts 

Re: [Xen-devel] [libvirt test] 140186: regressions - FAIL

[Jim Fehlig]

On 8/16/19 7:01 AM, osstest service owner wrote:
> flight 140186 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/140186/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>   build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 
> 139829
>   build-i386-libvirt6 libvirt-buildfail REGR. vs. 
> 139829
>   build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 
> 139829
>   build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 
> 139829

Should be fixed now by commit 3b7c5ab9

https://libvirt.org/git/?p=libvirt.git;a=commit;h=3b7c5ab983f4655ae02b8af4517d89839530ee5f

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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Anthony PERARD]

On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> Hi Lars,
> 
> On 16/08/2019 11:42, Lars Kurth wrote:
> > Unikraft repos follow the same syntax as xen.git with the
> > following exceptions:
> > * MAINTAINERS files are called MAINTAINERS.md
> > * M: ... etc blocks are preceded by whitespaces for rendering as
> >markup files
> 
> There is an other difference. The "fallback" category is "UNIKRAFT GENERAL"
> and not "THE REST".
> 
> > 
> > This change will
> > - load MAINTAINERS.md if MAINTAINERS is not present
> > - deal with indented M: ... blocks
> 
> One process question. Does it mean Unikraft folks will have to checkout Xen
> in order to use {add, get}_maintainers.pl? If so, would it make sense to
> have add_maintainers.pl and script_maintainers.pl in a separate repo that
> can be added as submodule?

Shouldn't instead the Unikraft repo have it's one get_maintainers
script? xen.git's script doesn't needs to have support for every single
repo available on earth and Unikraft is a different project anyway.

Usually, projects with a MAINTAINERS file have there own get_maintainers
script.

Cheers,

-- 
Anthony PERARD

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

Re: [Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID

[Wieczorkiewicz, Pawel]

On 16. Aug 2019, at 14:47, Wei Liu mailto:w...@xen.org>> wrote:

On Thu, Aug 15, 2019 at 09:44:00AM +, Pawel Wieczorkiewicz wrote:
Extend the list of xc() object methods with additional one to display
Xen's buildid. The implementation follows the libxl implementation
(e.g. max buildid size assumption being XC_PAGE_SIZE).

Signed-off-by: Pawel Wieczorkiewicz 
mailto:wipa...@amazon.de>>
Reviewed-by: Martin Mazein mailto:amaz...@amazon.de>>
Reviewed-by: Andra-Irina Paraschiv 
mailto:andra...@amazon.com>>
Reviewed-by: Norbert Manthey mailto:nmant...@amazon.de>>

I'm a bit confused by the tag in the subject line. Which series does
this patch belong to?

Wei.

Thanks for taking a look.

This is the series: https://marc.info/?t=15554198232=1=4

Best Regards,
Pawel Wieczorkiewicz



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


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

Re: [Xen-devel] [livepatch-build-tools part2 v2 5/6] create-diff-object: Add new entries to special sections array array

[Ross Lagerwall]

On 8/16/19 1:06 PM, Wieczorkiewicz, Pawel wrote:


On 16. Aug 2019, at 11:40, Ross Lagerwall > wrote:


On 8/8/19 1:35 PM, Pawel Wieczorkiewicz wrote:




…snip...

  * The rela groups in the .fixup section vary in size.  The 
beginning of each
  * .fixup rela group is referenced by the .ex_table section. To find 
the size
@@ -1072,6 +1090,18 @@ static struct special_section 
special_sections[] = {

.name= ".altinstructions",
.group_size= altinstructions_group_size,
},
+{
+.name= ".altinstr_replacement",
+.group_size= undefined_group_size,
+},
+{
+.name= ".livepatch.hooks.load",
+.group_size= livepatch_hooks_group_size,
+},
+{
+.name= ".livepatch.hooks.unload",
+.group_size= livepatch_hooks_group_size,
+},
{},
 };



Unless I'm misunderstanding something, I can't see how 
kpatch_regenerate_special_section would work with 
.altinstr_replacement having a group size of 0. It looks to me like 
the for loop in that function would become an infinite loop (due to 
incrementing by group_size) and should_keep_rela_group would always 
return false.




AFAICS, the group_size 0 sections are never actually processed by the 
kpatch_regenerate_special_section().
They are not RELA sections and the following check excludes them from 
this processing:



OK, that makes sense.

Thanks,
--
Ross Lagerwall

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

Re: [Xen-devel] [livepatch-build-tools part3 v2 3/3] create-diff-object: Strip all undefined entires of known size

[Ross Lagerwall]

On 8/8/19 1:51 PM, Pawel Wieczorkiewicz wrote:

The patched ELF object file contains all sections and symbols as
resulted from the compilation. However, certain symbols may not be
copied over to the resulting object file, due to being unchanged or
not included for other reasons.
In such situation the resulting object file has the entire sections
copied along (with all their entries unchanged), while some of the
corresponding symbols are not copied along at all.
This leads to having incorrect undefined (STN_UNDEF) entries in the
final hotpatch ELF file.

The newly added function livepatch_strip_undefined_elements() detects
and removes all undefined RELA entries as well as their corresponding
PROGBITS section entries.
Since the sections may contain elements of unknown size (sh.sh_entsize
== 0), perform the strip only on sections with well defined entry
sizes.

After replacing the stripped rela list, it is assumed that the next
invocation of the kpatch_rebuild_rela_section_data() will adjust all
section header parameters according to the current state.


The code in this patch seems to be very similar (i.e. somewhat 
copy-and-pasted) to kpatch_regenerate_special_section() which prunes the 
rela list and rebuilds the corresponding text section according to the 
predicate should_keep_rela_group(). The intent of the function also 
seems to be the same (only keep elements that are needed).


In what situations does the existing function not do the right thing?

Can should_keep_rela_group() be updated instead?

Thanks,
--
Ross Lagerwall

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

Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE

[tony.nguyen]

Hi Phillippe,

On 8/16/19 7:58 PM, Philippe Mathieu-Daudé wrote:
>On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote:
>> This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE.
>>
>> v7:
>[...]
>> - Re-declared many native endian devices as little or big endian. This is why
>>   v7 has +16 patches.
>
>Why are you doing that? What is the rational?

While collapsing the byte swaps, it was suggested in patch #11 of v5 that
consistent use of MemOp simplified endian comparisons. This lead to the
deprecation of enum device_endian by MemOp.

As MO_TE is conditional upon NEED_CPU_H, the s/DEVICE_NATIVE_ENDIAN/MO_TE/
required changing some device object files from common-obj-* to obj-*. In patch
#15 of v6 Paolo noted that most devices should not of been DEVICE_NATIVE_ENDIAN
and hinted at a clean up.

The +16 patches in v7 is the clean up effort.

>Anyhow if this not required by your series, you should split it out of
>it, and send it on your principal changes are merged.
>I'm worried because this these new patches involve many subsystems (thus
>maintainers) and reviewing them will now take a fair amount of time.

Yes, lets split these patches out. They are very much a tangent to the series
purpose.

>> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
>> targets from the set of target/hw/*/device.o.
>>
>> If the set of targets are all little or all big endian, re-declare
>> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
>> respectively.
>
>If only little endian targets use a device, that doesn't mean the device
>is designed in little endian...
>
>Then if a big endian target plan to use this device, it will require
>more work and you might have introduced regressions...
>
>I'm not sure this is a safe move.
>
>> This *naive* deduction may result in genuinely native endian devices
>> being incorrectly declared as little or big endian, but should not
>> introduce regressions for current targets.
>

Roger. Evidently too naive. TBH, most devices I've never heard of...

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 48d8d4d80bb299af5422312d92b044cb10a2e790
baseline version:
 ovmf f5892aa8d8bfbe8e6af5c9765faad8cfe877c334

Last test of basis   140144  2019-08-15 01:39:33 Z1 days
Testing same since   140162  2019-08-15 12:49:52 Z0 days2 attempts


People who touched revisions under test:
  Chasel Chiu 
  Eric Jin 
  Jian J Wang 
  Jin, Eric 
  Leif Lindholm 
  Michael D Kinney 
  Sean Brogan 
  Shenglei Zhang 
  Wang Fan 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   f5892aa8d8..48d8d4d80b  48d8d4d80bb299af5422312d92b044cb10a2e790 -> 
xen-tested-master

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

Re: [Xen-devel] [livepatch-build-tools part2 v2 6/6] create-diff-object: Do not include all .rodata sections

[Wieczorkiewicz, Pawel]

> On 16. Aug 2019, at 11:57, Ross Lagerwall  wrote:
> 
> On 8/8/19 1:39 PM, Pawel Wieczorkiewicz wrote:
>> 

…snip...

>>  #define inc_printf(fmt, ...) \
>>  log_debug("%*s" fmt, recurselevel, "", ##__VA_ARGS__);
> This patch looks good. There is a comment at the top of 
> should_include_str_section() which should probably be updated as well:
> 
> /*
> * String sections are always included even if unchanged.
> * The format is either:
> * .rodata..str1.[0-9]+ (new in GCC 6.1.0)
> * or .rodata.str1.[0-9]+ (older versions of GCC)
> * For the new format we could be smarter and only include the needed
> * strings sections.
> */
> 

Oh yes, right. Let me update the comment. Thanks!

> In fact, it is probably a good idea to rename the function to something like 
> "is_rodata_str_section()" since this more accurately describes what it does 
> now.

ACK, will do.

> 
> Thanks,
> --
> Ross Lagerwall


Best Regards,
Pawel Wieczorkiewicz





signature.asc
Description: Message signed with OpenPGP



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Lars Kurth]

On 16/08/2019, 13:09, "Paul Durrant"  wrote:

> -Original Message-
> From: Lars Kurth 
> Sent: 16 August 2019 13:05
> To: Anthony Perard ; Julien Grall 

> Cc: xen-devel@lists.xenproject.org; Felipe Huici 
; Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk 
; George
> Dunlap ; Andrew Cooper 
; Ian Jackson
> ; Tim (Xen.org) ; Florian Schmidt 
;
> Jan Beulich ; Simon Kuenzer ; 
Paul Durrant
> 
> Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the 
script on unikraft repos
> 
> Added Paul Durrant
> 
> On 16/08/2019, 12:17, "Anthony PERARD"  wrote:
> 
> On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> > Hi Lars,
> >
> > On 16/08/2019 11:42, Lars Kurth wrote:
> > > Unikraft repos follow the same syntax as xen.git with the
> > > following exceptions:
> > > * MAINTAINERS files are called MAINTAINERS.md
> > > * M: ... etc blocks are preceded by whitespaces for rendering as
> > >markup files
> >
> > There is an other difference. The "fallback" category is "UNIKRAFT 
GENERAL"
> > and not "THE REST".
> >
> > >
> > > This change will
> > > - load MAINTAINERS.md if MAINTAINERS is not present
> > > - deal with indented M: ... blocks
> >
> > One process question. Does it mean Unikraft folks will have to 
checkout Xen
> > in order to use {add, get}_maintainers.pl? If so, would it make 
sense to
> > have add_maintainers.pl and script_maintainers.pl in a separate 
repo that
> > can be added as submodule?
> 
> Shouldn't instead the Unikraft repo have it's one get_maintainers
> script? xen.git's script doesn't needs to have support for every 
single
> repo available on earth and Unikraft is a different project anyway.
> 
> Usually, projects with a MAINTAINERS file have there own 
get_maintainers
> script.
> 
> Well: Unikraft is part of the Xen Project.
> 
> When I started to clean up the contribution docs it became apparent that
> there is a lot of inconsistency. Ideally our contribution guide [0] would 
apply
> to pretty much *all* sub projects which use a mailing list based workflows
> 
> Consistency makes life for developers and also newcomers much easier. And 
the
> number of new devs who seem to trip over inconsistencies between projects 
are
> quite large (we had 3  cases in 3 weeks which I noticed).
> 
> If we start improving our CI infrastructure (which we are), it would be 
nice if other
> sub projects had the possibility to easily hook into it or replicate it. 
But that does require
> some consistency.
> 
> That's why I submitted [1] and [2]
> 
> Sub-projects with mail based workflows
> 1: Hypervisor
> 2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
> 3: Windows PV Drivers - which will require changes to their MAINTAINERS 
file
> 4: Unikraft
> 
> Supporting 1 - 3 should be straightforward because you would almost always
> have xen.git checked out. 4 is more different.

I'd say that folks building 3 are unlikely to have xen.git checked out.

Good to know

If there was tooling available that simplifies your workflow, would 
members of the Windows PV Drivers sub-project be willing to use them?

It maybe that for Windows PV Drivers the workflow is not at all command
line based and people tend to use an IDE instead.

Lars


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

[Xen-devel] [linux-4.19 test] 140173: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-examine 11 examine-serial/bootloader fail in 139883 pass in 
140173
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
139883

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   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-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail 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-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux893af1c79e42e53af0da22165b46eea135af0613
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  287 days
Failing since129412  2018-11-04 14:10:15 Z  284 days  200 attempts
Testing same since   139883  2019-08-09 23:10:54 Z6 days9 attempts


2437 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH livepatch-python 1/1] livepatch: Add python bindings for livepatch operations

[Wieczorkiewicz, Pawel]

> On 16. Aug 2019, at 14:37, Wei Liu  wrote:
> 
> On Thu, Aug 15, 2019 at 11:36:46AM +, Pawel Wieczorkiewicz wrote:
>> Extend the XC python bindings library to support also all common
>> livepatch operations and actions.
>> 
>> 

…snip...

>> 
>> Signed-off-by: Pawel Wieczorkiewicz 
>> Reviewed-by: Martin Mazein 
>> Reviewed-by: Andra-Irina Paraschiv 
>> Reviewed-by: Leonard Foerster 
>> Reviewed-by: Norbert Manthey 
> 
> I haven't looked in details, but I'm fine with these new functionalities
> in general. Let's see if Marek has any objections.

Thanks.

> 
> Which version of Python do you use to build these? The requirement here
> is the code should build with both Python 2.5 and Python 3.
> 

Ah, I see. Thanks for pointing this out. We’re planing to upstream the tool 
using those bindings as well.
But, it still requires some work. Let us add the python versions support for 
the tool.

> Wei.


Best Regards,
Pawel Wieczorkiewicz


signature.asc
Description: Message signed with OpenPGP



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


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

Re: [Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE

[Peter Maydell]

On Fri, 16 Aug 2019 at 12:37,  wrote:
>
> Hi Phillippe,
>
> On 8/16/19 7:58 PM, Philippe Mathieu-Daudé wrote:
> >On 8/16/19 8:28 AM, tony.ngu...@bt.com wrote:
> >> For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
> >> targets from the set of target/hw/*/device.o.
> >>
> >> If the set of targets are all little or all big endian, re-declare
> >> the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
> >> respectively.
> >
> >If only little endian targets use a device, that doesn't mean the device
> >is designed in little endian...
> >
> >Then if a big endian target plan to use this device, it will require
> >more work and you might have introduced regressions...
> >
> >I'm not sure this is a safe move.
> >
> >> This *naive* deduction may result in genuinely native endian devices
> >> being incorrectly declared as little or big endian, but should not
> >> introduce regressions for current targets.
> >
>
> Roger. Evidently too naive. TBH, most devices I've never heard of...

OTOH it's worth noting that it's quite likely that most of
the implementations of these DEVICE_NATIVE_ENDIAN devices
picked it in an equally naive way, by just copying some other
device's code...

thanks
-- PMM

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

Re: [Xen-devel] [PATCH livepatch-python 1/1] livepatch: Add python bindings for livepatch operations

[Wei Liu]

On Thu, Aug 15, 2019 at 11:36:46AM +, Pawel Wieczorkiewicz wrote:
> Extend the XC python bindings library to support also all common
> livepatch operations and actions.
> 
> Add the python bindings for the following operations:
> - status (pyxc_livepatch_status):
>   Requires a payload name as an input.
>   Returns a status dict containing a state string and a return code
>   integer.
> - action (pyxc_livepatch_action):
>   Requires a payload name and an action id as an input. Timeout and
>   flags are optional parameters.
>   Returns a return code integer.
> - upload (pyxc_livepatch_upload):
>   Requires a payload name and a module's filename as an input.
>   Returns a return code integer.
> - list (pyxc_livepatch_list):
>   Takes no parameters.
>   Returns a list of dicts containing each payload's:
>   * name as a string
>   * state as a string
>   * return code as an integer
>   * list of metadata key=value strings
> 
> Each functions throws an exception error based on the errno value
> received from its corresponding libxc function call.
> 
> Signed-off-by: Pawel Wieczorkiewicz 
> Reviewed-by: Martin Mazein 
> Reviewed-by: Andra-Irina Paraschiv 
> Reviewed-by: Leonard Foerster 
> Reviewed-by: Norbert Manthey 

I haven't looked in details, but I'm fine with these new functionalities
in general. Let's see if Marek has any objections.

Which version of Python do you use to build these? The requirement here
is the code should build with both Python 2.5 and Python 3.

Wei.

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

Re: [Xen-devel] [livepatch-build-tools part3 v2 2/3] create-diff-object: Extend patchability verification: STN_UNDEF

[Ross Lagerwall]

On 8/8/19 1:48 PM, Pawel Wieczorkiewicz wrote:

During verification check if all sections do not contain any entries
with undefined symbols (STN_UNDEF). This situation can happen when a
section is copied over from its original object to a patched object,
but various symbols related to the section are not copied along.
This scenario happens typically during stacked hotpatches creation
(between 2 different hotpatch modules).

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Martin Pohlack 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
Reviewed-by: Andra-Irina Paraschiv 

... snip

+static int kpatch_section_has_undef_symbols(struct kpatch_elf *kelf,
+   const struct section *sec)
+{
+   int offset, entry_size;
+   struct rela *rela;
+   size_t d_size;
+
+   entry_size = get_section_entry_size(sec, kelf);
+   if (entry_size == 0)
+   return false;
+
+   d_size = sec->base->data->d_size;
+   for ( offset = 0; offset < d_size; offset += entry_size ) {


The coding style doesn't use spaces inside the for loop parentheses.


+   list_for_each_entry(rela, >relas, list) {
+   if (rela->offset < offset ||
+   rela->offset >= offset + entry_size) {
+   continue;
+   }
+
+   if ((GELF_R_SYM(rela->rela.r_info) == STN_UNDEF) ||
+   (!rela->sym->include && rela->sym->status == SAME)) 
{
+   log_normal("section %s has an entry with a STN_UNDEF 
symbol: %s\n",
+  sec->name, rela->sym->name ?: 
"none");


Perhaps this log message is a bit misleading if only the second 
condition is true? Maybe something slightly more general like "has an 
entry with an undefined symbol".


Otherwise looks OK to me.

Thanks,
--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism

[Wieczorkiewicz, Pawel]

> On 16. Aug 2019, at 14:44, Wei Liu  wrote:
> 
> On Thu, Aug 15, 2019 at 11:27:50AM +, Pawel Wieczorkiewicz wrote:
>> Extend the livepatch list operation to fetch also payloads' metadata.
>> This is achieved by extending the sysctl list interface with 2 extra
>> guest handles:
>> * metadata - an array of arbitrary size strings
>> * metadata_len - an array of metadata strings' lengths (uin32_t each)

…snip...

>> Signed-off-by: Pawel Wieczorkiewicz 
>> Reviewed-by: Andra-Irina Paraschiv 
>> Reviewed-by: Martin Pohlack 
>> Reviewed-by: Norbert Manthey 
>> ---
>> tools/libxc/include/xenctrl.h | 22 +++
>> tools/libxc/xc_misc.c | 66 
>> +++
>> tools/misc/xen-livepatch.c| 43 ++--
>> xen/common/livepatch.c| 22 +++
>> xen/include/public/sysctl.h   | 19 +
> 
> Mostly look good. One comment below...
> 
>> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
>> index b86804b7a6..e4c8f4fe63 100644
>> --- a/xen/include/public/sysctl.h
>> +++ b/xen/include/public/sysctl.h
> 
> If it hasn't been done for this release already, changing sysctl interface 
> requires
> bumping the version number in this header.
> 

ACK. Will do (also for earlier patches…).

> Wei.

Best Regards,
Pawel Wieczorkiewicz


signature.asc
Description: Message signed with OpenPGP



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


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

Re: [Xen-devel] [PATCH 03/11] xen/arm: pass one less argument to dma_cache_maint

[Robin Murphy]

On 16/08/2019 14:00, Christoph Hellwig wrote:

Instead of taking apart the dma address in both callers do it inside
dma_cache_maint itself.

Signed-off-by: Christoph Hellwig 
---
  arch/arm/xen/mm.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 90574d89d0d4..d9da24fda2f7 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -43,13 +43,15 @@ static bool hypercall_cflush = false;
  
  /* functions called by SWIOTLB */
  
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,

-   size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+static void dma_cache_maint(dma_addr_t handle, size_t size,
+   enum dma_data_direction dir, enum dma_cache_op op)
  {
struct gnttab_cache_flush cflush;
unsigned long xen_pfn;
+   unsigned long offset = handle & ~PAGE_MASK;
size_t left = size;
  
+	offset &= PAGE_MASK;


Ahem... presumably that should be handle, not offset.

Robin.


xen_pfn = (handle >> XEN_PAGE_SHIFT) + offset / XEN_PAGE_SIZE;
offset %= XEN_PAGE_SIZE;
  
@@ -86,13 +88,13 @@ static void dma_cache_maint(dma_addr_t handle, unsigned long offset,

  static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
  {
-   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, 
DMA_UNMAP);
+   dma_cache_maint(handle, size, dir, DMA_UNMAP);
  }
  
  static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,

size_t size, enum dma_data_direction dir)
  {
-   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, 
DMA_MAP);
+   dma_cache_maint(handle, size, dir, DMA_MAP);
  }
  
  void __xen_dma_map_page(struct device *hwdev, struct page *page,




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

Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the script on unikraft repos

[Paul Durrant]

> -Original Message-
> From: Lars Kurth 
> Sent: 16 August 2019 13:05
> To: Anthony Perard ; Julien Grall 
> 
> Cc: xen-devel@lists.xenproject.org; Felipe Huici ; 
> Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk 
> ; George
> Dunlap ; Andrew Cooper ; 
> Ian Jackson
> ; Tim (Xen.org) ; Florian Schmidt 
> ;
> Jan Beulich ; Simon Kuenzer ; 
> Paul Durrant
> 
> Subject: Re: [Xen-devel] [PATCH] get_maintainers.pl: Enable running the 
> script on unikraft repos
> 
> Added Paul Durrant
> 
> On 16/08/2019, 12:17, "Anthony PERARD"  wrote:
> 
> On Fri, Aug 16, 2019 at 11:55:16AM +0100, Julien Grall wrote:
> > Hi Lars,
> >
> > On 16/08/2019 11:42, Lars Kurth wrote:
> > > Unikraft repos follow the same syntax as xen.git with the
> > > following exceptions:
> > > * MAINTAINERS files are called MAINTAINERS.md
> > > * M: ... etc blocks are preceded by whitespaces for rendering as
> > >markup files
> >
> > There is an other difference. The "fallback" category is "UNIKRAFT 
> GENERAL"
> > and not "THE REST".
> >
> > >
> > > This change will
> > > - load MAINTAINERS.md if MAINTAINERS is not present
> > > - deal with indented M: ... blocks
> >
> > One process question. Does it mean Unikraft folks will have to checkout 
> Xen
> > in order to use {add, get}_maintainers.pl? If so, would it make sense to
> > have add_maintainers.pl and script_maintainers.pl in a separate repo 
> that
> > can be added as submodule?
> 
> Shouldn't instead the Unikraft repo have it's one get_maintainers
> script? xen.git's script doesn't needs to have support for every single
> repo available on earth and Unikraft is a different project anyway.
> 
> Usually, projects with a MAINTAINERS file have there own get_maintainers
> script.
> 
> Well: Unikraft is part of the Xen Project.
> 
> When I started to clean up the contribution docs it became apparent that
> there is a lot of inconsistency. Ideally our contribution guide [0] would 
> apply
> to pretty much *all* sub projects which use a mailing list based workflows
> 
> Consistency makes life for developers and also newcomers much easier. And the
> number of new devs who seem to trip over inconsistencies between projects are
> quite large (we had 3  cases in 3 weeks which I noticed).
> 
> If we start improving our CI infrastructure (which we are), it would be nice 
> if other
> sub projects had the possibility to easily hook into it or replicate it. But 
> that does require
> some consistency.
> 
> That's why I submitted [1] and [2]
> 
> Sub-projects with mail based workflows
> 1: Hypervisor
> 2: Hypervisor related repos (livepatch-build-tools, mini-os, xtf, ...)
> 3: Windows PV Drivers - which will require changes to their MAINTAINERS file
> 4: Unikraft
> 
> Supporting 1 - 3 should be straightforward because you would almost always
> have xen.git checked out. 4 is more different.

I'd say that folks building 3 are unlikely to have xen.git checked out.

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

Re: [Xen-devel] [PATCH lp-metadata 3/3] livepatch: Add metadata runtime retrieval mechanism

[Wei Liu]

On Fri, Aug 16, 2019 at 12:54:12PM +, Wieczorkiewicz, Pawel wrote:
> 
> > On 16. Aug 2019, at 14:44, Wei Liu  wrote:
> > 
> > On Thu, Aug 15, 2019 at 11:27:50AM +, Pawel Wieczorkiewicz wrote:
> >> Extend the livepatch list operation to fetch also payloads' metadata.
> >> This is achieved by extending the sysctl list interface with 2 extra
> >> guest handles:
> >> * metadata - an array of arbitrary size strings
> >> * metadata_len - an array of metadata strings' lengths (uin32_t each)
> 
> …snip...
> 
> >> Signed-off-by: Pawel Wieczorkiewicz 
> >> Reviewed-by: Andra-Irina Paraschiv 
> >> Reviewed-by: Martin Pohlack 
> >> Reviewed-by: Norbert Manthey 
> >> ---
> >> tools/libxc/include/xenctrl.h | 22 +++
> >> tools/libxc/xc_misc.c | 66 
> >> +++
> >> tools/misc/xen-livepatch.c| 43 ++--
> >> xen/common/livepatch.c| 22 +++
> >> xen/include/public/sysctl.h   | 19 +
> > 
> > Mostly look good. One comment below...
> > 
> >> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> >> index b86804b7a6..e4c8f4fe63 100644
> >> --- a/xen/include/public/sysctl.h
> >> +++ b/xen/include/public/sysctl.h
> > 
> > If it hasn't been done for this release already, changing sysctl interface 
> > requires
> > bumping the version number in this header.
> > 
> 
> ACK. Will do (also for earlier patches…).
> 

We only need to do it once per release. :-)

Wei.

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

Re: [Xen-devel] [PATCH] libxlu: Handle += in config files

[Anthony PERARD]

On Fri, Aug 16, 2019 at 12:47:07PM +, Wei Liu wrote:
> On Tue, Aug 13, 2019 at 05:42:15PM +0100, Anthony PERARD wrote:
> > On Tue, Aug 13, 2019 at 04:47:23PM +0100, Andrew Cooper wrote:
> > > Error between user and terminal. :)
> > > 
> > > I'd sync'd xl and libxl.so, but not libxlu.so
> > 
> > I actually made the same mistake first time I tried.
> > 
> > > Ok, so that is working now.  I think 'cmdline+=" dom0=pvh
> > > dom0-iommu=none"' is slightly less tortured syntax, but I guess there is
> > > no way that this isn't going to be horrible.
> > > 
> > > As for the general mechanism, how usable is += for anything other than
> > > cmdline?  Most strings in config files can't usefully be extended in
> > > this matter - if they need changing, they need changing wholesale.
> > 
> > That's true, but one could imaging some maybe bad example like adding a
> > suffix to the name of the guest: "name+='-ovmf';".
> > Going through `man xl.cfg', maybe a good example other than cmdline
> > could be "cpus+=',^1'" but maybe a space is fine here, or one could use
> > a list instead.
> > Other potential uses could be for "PATH", but in this case it would be
> > better reset the setting rather that attempting to add a suffix to an
> > existing one.
> > 
> > I wonder if instead of doing += on all strings, we should instead have
> > `xl' whitelist the few options where += would make sense. (and at that
> > point, it would be easy to add a ' ' where is make sense, like
> > "cmdline"s. But then, how to tell users that it can't do "name+='-new'"?
> > because xlu would just print a warning, and xl would keep going with
> > name="".  Try "xl create memory+=42" ;-).
> 
> Not sure I follow. Can you limit this in xl?

With a patch to xl, yes ;-). What could be done is to add a new API in
libxlu. The original function get_string() could return an error if +=
was used on a specific setting. A new function get_appended_string()
(working title), could return return a string with the += computation
done. That way, xl can choose which setting are allowed to have += used
(and it could even use how to do it, i.e. add spaces between strings or
not).

> Isn't += handled in libxlu already?

It's not, this patch adds the capability into libxlu.

Cheers,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2] Allow get_maintainer.pl / add_maintainers.pl scripts to be called outside of xen.git

[Lars Kurth]

> On 16 Aug 2019, at 14:28, Julien Grall  wrote:
> 
> 
> 
> On 16/08/2019 13:17, Lars Kurth wrote:
>> On 16/08/2019, 11:01, "Julien Grall"  wrote:
>>  From my understanding, any use on mini-os.git & co will be legitimate. 
>> However,
>> we still print the WARNING in those cases.
>>  Usually WARNING means something needs attention. As most of the 
>> users will
>> likely copy/paste from the wiki, we are going to have report asking why 
>> the
>> WARNING is there.
>>  I think it would make sense to try to downgrade the message a bit 
>> when possible.
>> For instance, we could check if the section "THE REST" is present in the 
>> file
>> MAINTAINERS. If not, this is likely not a file we are able to support.
>> I thought about this and it is not as easy as it seems, because the 
>> script only parses
>> M: ...  lines
> 
> The script is able to parse the section name. See get_maintainer_role().
> 
> Although, I am not sure how early the function can get called.
> 
> But...

That may make it feasible to go down that route.
Incidentially both Linux as well as QEMU MAINTAINERs files use the same syntax
as us (with a few extra tags which we don't have)

Not sure whether this would be a problem

>> Maybe the best way to address this would be to include some identifier into 
>> the
>> MAINTAINERS file (after the header with all the definitions).
>> FORMAT: xen-project-maintainers 
>> (note that this is not currently picked up by the tool)
>> Or
>> V: xen-project-maintainers 
>> (note that this would be picked up by the tool)
> 
> Any of these solutions are also a potential alternative.

I will see what others think and take it from there

Lars


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

Re: [Xen-devel] [RFC] Code of Conduct

[George Dunlap]

On 8/15/19 6:23 PM, Rich Persaud wrote:
>> On Aug 9, 2019, at 13:48, Lars Kurth  wrote:
>>
>> Hi all,
> 
> Hi Lars,
> 
>>
>> Following the discussion we had at the Developer Summit (see 
>> https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc.
>>  for notes) I put together a draft for the Code of Conduct which can be 
>> found here as well as inlined below
>> https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing
>>  
>>
>> It is based on the LF Events CoC as we agreed on (the diff is attached). I 
>> took the scope and enforcement sections from 
>> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html and 
>> simplified it rather than inventing something new.
> 
> Is there precedent for applying a legal contract (Code of Conduct) that was 
> designed for physical space (conference event) to an online context?   Is 
> there an existing Code of Conduct that was legally designed for a similar, 
> online open-source community context, e.g. operating system or hypervisor or 
> other systems-level software dev?

This is sort of a strange question.

Generally speaking, there was a link Lars pointed to in an earlier
thread in preparation for this, making two suggestions about adopting a CoC:

1. Don't create your own CoC from scratch.  Learn from other people's
experiences, mistakes, and so on, rather than re-inventing the wheel.
This will hopefully reduce the chance of re-hashing mistakes other
communities have made.

2. Don't copy-and-paste a CoC unmodified from another project.  Consider
it, adapt it to your own community culture and situation.  This makes
sure that the CoC is not a tick-box exercise, but that people in your
community have thoughfully considered various issues and genuinely
decided to commit to them.

I think both of those bits of advice are good; and it appears to me that
this is exactly what Lars (with input from a number of others) has done.

There are two things that we want, in general:

1. To cast a vision for what ideal contributor behavior should be

2. To set a bar for minimum acceptable behavior, and a way for excluding
people whose behavior consistently falls below that bar.

One area in particular where Lars thought other CoCs were weak was in
trying to combine #1 and #2.  They need different responses.  #1 needs
encouragement and vision.  #2 needs teeth: We need to be able to apply
penalties and exclude people.

As a result, Lars has suggested (and many people have agreed), that we
separate the two functions.  This document is about #2, not #1.  We plan
to do #1 after #2 is completed.

>> # Expected Behavior
>> All Xen Project community members are expected to behave in accordance with 
>> professional standards, with both the Xen Project Code of Conduct as well as 
>> their 
>> respective employer’s policies governing appropriate workplace behavior, and 
>> applicable laws.
> 
> In the x86 community call where this was first discussed, I suggested that we 
> try to define desirable behavior, which we would like to incentivize and 
> promote.   In this current draft, we have a single sentence on positive 
> behavior, with inclusion-by-reference to:

We plan on doing this, but in another document.

> If incorporation-by-reference is not sufficient, e.g. if we will maintain a 
> blacklist of unacceptable behavior for collaborative, online open-source 
> development, do we also need a whitelist of acceptable behavior?  Within Xen 
> source code, we have been moving away from blacklists towards whitelists.

Unlike hypercalls, all human behavior cannot be enumerated; and if it
could, 100% certainty cannot be obtained about what a certain behavior
is, or even exactly what did or did not happen.  No matter what we write
down, at some point, you're just going to have to either trust the
people making the decisions.

>> # Unacceptable Behavior
>> Harassment will not be tolerated in the Xen Project Community in any form, 
>> including but not limited to harassment based on gender, gender identity and 
>> expression, sexual orientation, disability, physical appearance, body size, 
>> race, 
>> age, religion, ethnicity, nationality, level of experience, education, or 
>> socio-economic status or any other status protected by laws in jurisdictions 
>> in 
>> which community members are based. Harassment includes the use of abusive, 
>> offensive or degrading language, intimidation, stalking, harassing 
>> photography 
>> or recording, inappropriate physical contact, sexual imagery and unwelcome 
>> sexual advances, requests for sexual favors, publishing others' private 
>> information such as a physical or electronic address without explicit 
>> permission
> 
> Picking one item at random:  would a conference-originated blacklist 
> prohibition be appropriate for online open-source development?  E.g. if 
> someone's email address were included in a xen-devel 

[Xen-devel] [PATCH 02/11] xen/arm: use dev_is_dma_coherent

[Christoph Hellwig]

Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/include/asm/dma-mapping.h   |  6 --
 arch/arm/xen/mm.c| 12 ++--
 arch/arm64/include/asm/dma-mapping.h |  9 -
 3 files changed, 6 insertions(+), 21 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index dba9355e2484..bdd80ddbca34 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -91,12 +91,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev, 
void *addr)
 }
 #endif
 
-/* do not use this function in a driver */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
-   return dev->archdata.dma_coherent;
-}
-
 /**
  * arm_dma_alloc - allocate consistent memory for DMA
  * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d33b77e9add3..90574d89d0d4 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -99,7 +99,7 @@ void __xen_dma_map_page(struct device *hwdev, struct page 
*page,
 dma_addr_t dev_addr, unsigned long offset, size_t size,
 enum dma_data_direction dir, unsigned long attrs)
 {
-   if (is_device_dma_coherent(hwdev))
+   if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -112,7 +112,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t 
handle,
unsigned long attrs)
 
 {
-   if (is_device_dma_coherent(hwdev))
+   if (dev_is_dma_coherent(hwdev))
return;
if (attrs & DMA_ATTR_SKIP_CPU_SYNC)
return;
@@ -123,7 +123,7 @@ void __xen_dma_unmap_page(struct device *hwdev, dma_addr_t 
handle,
 void __xen_dma_sync_single_for_cpu(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-   if (is_device_dma_coherent(hwdev))
+   if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_dev_to_cpu(hwdev, handle, size, dir);
 }
@@ -131,7 +131,7 @@ void __xen_dma_sync_single_for_cpu(struct device *hwdev,
 void __xen_dma_sync_single_for_device(struct device *hwdev,
dma_addr_t handle, size_t size, enum dma_data_direction dir)
 {
-   if (is_device_dma_coherent(hwdev))
+   if (dev_is_dma_coherent(hwdev))
return;
__xen_dma_page_cpu_to_dev(hwdev, handle, size, dir);
 }
@@ -159,7 +159,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
 * memory and we are not able to flush the cache.
 */
return (!hypercall_cflush && (xen_pfn != bfn) &&
-   !is_device_dma_coherent(dev));
+   !dev_is_dma_coherent(dev));
 }
 
 int xen_create_contiguous_region(phys_addr_t pstart, unsigned int order,
diff --git a/arch/arm64/include/asm/dma-mapping.h 
b/arch/arm64/include/asm/dma-mapping.h
index bdcb0922a40c..67243255a858 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -18,14 +18,5 @@ static inline const struct dma_map_ops 
*get_arch_dma_ops(struct bus_type *bus)
return NULL;
 }
 
-/*
- * Do not use this function in a driver, it is only provided for
- * arch/arm/mm/xen.c, which is used by arm64 as well.
- */
-static inline bool is_device_dma_coherent(struct device *dev)
-{
-   return dev->dma_coherent;
-}
-
 #endif /* __KERNEL__ */
 #endif /* __ASM_DMA_MAPPING_H */
-- 
2.20.1


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

[Xen-devel] [PATCH 03/11] xen/arm: pass one less argument to dma_cache_maint

[Christoph Hellwig]

Instead of taking apart the dma address in both callers do it inside
dma_cache_maint itself.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/xen/mm.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 90574d89d0d4..d9da24fda2f7 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -43,13 +43,15 @@ static bool hypercall_cflush = false;
 
 /* functions called by SWIOTLB */
 
-static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
-   size_t size, enum dma_data_direction dir, enum dma_cache_op op)
+static void dma_cache_maint(dma_addr_t handle, size_t size,
+   enum dma_data_direction dir, enum dma_cache_op op)
 {
struct gnttab_cache_flush cflush;
unsigned long xen_pfn;
+   unsigned long offset = handle & ~PAGE_MASK;
size_t left = size;
 
+   offset &= PAGE_MASK;
xen_pfn = (handle >> XEN_PAGE_SHIFT) + offset / XEN_PAGE_SIZE;
offset %= XEN_PAGE_SIZE;
 
@@ -86,13 +88,13 @@ static void dma_cache_maint(dma_addr_t handle, unsigned 
long offset,
 static void __xen_dma_page_dev_to_cpu(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
 {
-   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, 
DMA_UNMAP);
+   dma_cache_maint(handle, size, dir, DMA_UNMAP);
 }
 
 static void __xen_dma_page_cpu_to_dev(struct device *hwdev, dma_addr_t handle,
size_t size, enum dma_data_direction dir)
 {
-   dma_cache_maint(handle & PAGE_MASK, handle & ~PAGE_MASK, size, dir, 
DMA_MAP);
+   dma_cache_maint(handle, size, dir, DMA_MAP);
 }
 
 void __xen_dma_map_page(struct device *hwdev, struct page *page,
-- 
2.20.1


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

[Xen-devel] [PATCH 10/11] swiotlb-xen: merge xen_unmap_single into xen_swiotlb_unmap_page

[Christoph Hellwig]

No need for a no-op wrapper.

Signed-off-by: Christoph Hellwig 
---
 drivers/xen/swiotlb-xen.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c3c383033ae4..b6b9c4c1b397 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -414,9 +414,8 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
  * After this call, reads by the cpu to the buffer are guaranteed to see
  * whatever the device wrote there.
  */
-static void xen_unmap_single(struct device *hwdev, dma_addr_t dev_addr,
-size_t size, enum dma_data_direction dir,
-unsigned long attrs)
+static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
+   size_t size, enum dma_data_direction dir, unsigned long attrs)
 {
phys_addr_t paddr = xen_bus_to_phys(dev_addr);
 
@@ -430,13 +429,6 @@ static void xen_unmap_single(struct device *hwdev, 
dma_addr_t dev_addr,
swiotlb_tbl_unmap_single(hwdev, paddr, size, dir, attrs);
 }
 
-static void xen_swiotlb_unmap_page(struct device *hwdev, dma_addr_t dev_addr,
-   size_t size, enum dma_data_direction dir,
-   unsigned long attrs)
-{
-   xen_unmap_single(hwdev, dev_addr, size, dir, attrs);
-}
-
 static void
 xen_swiotlb_sync_single_for_cpu(struct device *dev, dma_addr_t dma_addr,
size_t size, enum dma_data_direction dir)
@@ -477,7 +469,8 @@ xen_swiotlb_unmap_sg(struct device *hwdev, struct 
scatterlist *sgl, int nelems,
BUG_ON(dir == DMA_NONE);
 
for_each_sg(sgl, sg, nelems, i)
-   xen_unmap_single(hwdev, sg->dma_address, sg_dma_len(sg), dir, 
attrs);
+   xen_swiotlb_unmap_page(hwdev, sg->dma_address, sg_dma_len(sg),
+   dir, attrs);
 
 }
 
-- 
2.20.1


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

[Xen-devel] [PATCH 01/11] xen/arm: use dma-noncoherent.h calls for xen-swiotlb cache maintainance

[Christoph Hellwig]

Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
non-coherent devices.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/Kconfig   |  4 +
 arch/arm/include/asm/device.h  |  3 -
 arch/arm/include/asm/xen/page-coherent.h   | 93 --
 arch/arm/mm/Kconfig|  4 -
 arch/arm/mm/dma-mapping.c  |  8 +-
 arch/arm64/include/asm/xen/page-coherent.h | 75 -
 drivers/xen/swiotlb-xen.c  | 49 +---
 include/xen/arm/page-coherent.h| 71 +
 8 files changed, 78 insertions(+), 229 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 33b00579beff..24360211534a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -7,6 +7,8 @@ config ARM
select ARCH_HAS_BINFMT_FLAT
select ARCH_HAS_DEBUG_VIRTUAL if MMU
select ARCH_HAS_DEVMEM_IS_ALLOWED
+   select ARCH_HAS_DMA_COHERENT_TO_PFN if SWIOTLB
+   select ARCH_HAS_DMA_MMAP_PGPROT if SWIOTLB
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_KEEPINITRD
@@ -18,6 +20,8 @@ config ARM
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU
+   select ARCH_HAS_SYNC_DMA_FOR_DEVICE if SWIOTLB
+   select ARCH_HAS_SYNC_DMA_FOR_CPU if SWIOTLB
select ARCH_HAS_TEARDOWN_DMA_OPS if MMU
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index f6955b55c544..c675bc0d5aa8 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,9 +14,6 @@ struct dev_archdata {
 #endif
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
struct dma_iommu_mapping*mapping;
-#endif
-#ifdef CONFIG_XEN
-   const struct dma_map_ops *dev_dma_ops;
 #endif
unsigned int dma_coherent:1;
unsigned int dma_ops_setup:1;
diff --git a/arch/arm/include/asm/xen/page-coherent.h 
b/arch/arm/include/asm/xen/page-coherent.h
index 2c403e7c782d..27e984977402 100644
--- a/arch/arm/include/asm/xen/page-coherent.h
+++ b/arch/arm/include/asm/xen/page-coherent.h
@@ -1,95 +1,2 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_ARM_XEN_PAGE_COHERENT_H
-#define _ASM_ARM_XEN_PAGE_COHERENT_H
-
-#include 
-#include 
 #include 
-
-static inline const struct dma_map_ops *xen_get_dma_ops(struct device *dev)
-{
-   if (dev && dev->archdata.dev_dma_ops)
-   return dev->archdata.dev_dma_ops;
-   return get_arch_dma_ops(NULL);
-}
-
-static inline void *xen_alloc_coherent_pages(struct device *hwdev, size_t size,
-   dma_addr_t *dma_handle, gfp_t flags, unsigned long attrs)
-{
-   return xen_get_dma_ops(hwdev)->alloc(hwdev, size, dma_handle, flags, 
attrs);
-}
-
-static inline void xen_free_coherent_pages(struct device *hwdev, size_t size,
-   void *cpu_addr, dma_addr_t dma_handle, unsigned long attrs)
-{
-   xen_get_dma_ops(hwdev)->free(hwdev, size, cpu_addr, dma_handle, attrs);
-}
-
-static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
-dma_addr_t dev_addr, unsigned long offset, size_t size,
-enum dma_data_direction dir, unsigned long attrs)
-{
-   unsigned long page_pfn = page_to_xen_pfn(page);
-   unsigned long dev_pfn = XEN_PFN_DOWN(dev_addr);
-   unsigned long compound_pages =
-   (1unmap_page)
-   xen_get_dma_ops(hwdev)->unmap_page(hwdev, handle, size, 
dir, attrs);
-   } else
-   __xen_dma_unmap_page(hwdev, handle, size, dir, attrs);
-}
-
-static inline void xen_dma_sync_single_for_cpu(struct device *hwdev,
-   dma_addr_t handle, size_t size, enum dma_data_direction dir)
-{
-   unsigned long pfn = PFN_DOWN(handle);
-   if (pfn_valid(pfn)) {
-   if (xen_get_dma_ops(hwdev)->sync_single_for_cpu)
-   

[Xen-devel] [PATCH 04/11] xen/arm: remove xen_dma_ops

[Christoph Hellwig]

arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.

Signed-off-by: Christoph Hellwig 
---
 arch/arm/mm/dma-mapping.c| 3 ++-
 arch/arm/xen/mm.c| 4 
 arch/arm64/mm/dma-mapping.c  | 3 ++-
 include/xen/arm/hypervisor.h | 2 --
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 738097396445..2661cad36359 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dma.h"
 #include "mm.h"
@@ -2360,7 +2361,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
 
 #ifdef CONFIG_XEN
if (xen_initial_domain())
-   dev->dma_ops = xen_dma_ops;
+   dev->dma_ops = _swiotlb_dma_ops;
 #endif
dev->archdata.dma_ops_setup = true;
 }
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index d9da24fda2f7..388a45002bad 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -183,16 +183,12 @@ void xen_destroy_contiguous_region(phys_addr_t pstart, 
unsigned int order)
 }
 EXPORT_SYMBOL_GPL(xen_destroy_contiguous_region);
 
-const struct dma_map_ops *xen_dma_ops;
-EXPORT_SYMBOL(xen_dma_ops);
-
 int __init xen_mm_init(void)
 {
struct gnttab_cache_flush cflush;
if (!xen_initial_domain())
return 0;
xen_swiotlb_init(1, false);
-   xen_dma_ops = _swiotlb_dma_ops;
 
cflush.op = 0;
cflush.a.dev_bus_addr = 0;
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index bd2b039f43a6..4b244a037349 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -64,6 +65,6 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64 
size,
 
 #ifdef CONFIG_XEN
if (xen_initial_domain())
-   dev->dma_ops = xen_dma_ops;
+   dev->dma_ops = _swiotlb_dma_ops;
 #endif
 }
diff --git a/include/xen/arm/hypervisor.h b/include/xen/arm/hypervisor.h
index 2982571f7cc1..43ef24dd030e 100644
--- a/include/xen/arm/hypervisor.h
+++ b/include/xen/arm/hypervisor.h
@@ -19,8 +19,6 @@ static inline enum paravirt_lazy_mode 
paravirt_get_lazy_mode(void)
return PARAVIRT_LAZY_NONE;
 }
 
-extern const struct dma_map_ops *xen_dma_ops;
-
 #ifdef CONFIG_XEN
 void __init xen_early_init(void);
 #else
-- 
2.20.1


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

[Xen-devel] swiotlb-xen cleanups

[Christoph Hellwig]

Hi Xen maintainers and friends,

please take a look at this series that cleans up the parts of swiotlb-xen
that deal with non-coherent caches.

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

[Xen-devel] [linux-4.4 test] 140180: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail in 140072 REGR. 
vs. 139698

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 140072 pass in 140180
 test-armhf-armhf-xl-vhd 10 debian-di-install fail in 140072 pass in 140180
 test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10 fail pass in 140072

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx  7 xen-boot fail   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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot 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-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail 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
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux

[Xen-devel] [PATCH v6 07/10] use is_iommu_enabled() where appropriate...

[Paul Durrant]

...rather than testing the global iommu_enabled flag and ops pointer.

Now that there is a per-domain flag indicating whether the domain is
permitted to use the IOMMU (which determines whether the ops pointer will
be set), many tests of the global iommu_enabled flag and ops pointer can
be translated into tests of the per-domain flag. Some of the other tests of
purely the global iommu_enabled flag can also be translated into tests of
the per-domain flag.

NOTE: The comment in iommu_share_p2m_table() is also fixed; need_iommu()
  disappeared some time ago. Also, whilst the style of the 'if' in
  flask_iommu_resource_use_perm() is fixed, I have not translated any
  instances of u32 into uint32_t to keep consistency. IMO such a
  translation would be better done globally for the source module in
  a separate patch.
  The change in the initialization of the 'hd' variable in iommu_map()
  and iommu_unmap() is done to keep the PV shim build happy. Without
  this change it will fail to compile with errors of the form:

iommu.c:361:32: error: unused variable ‘hd’ [-Werror=unused-variable]
 const struct domain_iommu *hd = dom_iommu(d);
 ^~

Signed-off-by: Paul Durrant 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Volodymyr Babchuk 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 
Cc: Daniel De Graaf 

Previously part of series 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html

v5:
 - Fix logic in ARM p2m_init()
 - Make iommu_do_domctl() return -EOPNOTSUPP rather than -ENOSYS if the
   IOMMU is not enabled
 - Fix test in pci_enable_acs()
 - Fix test in flask_iommu_resource_use_perm()
---
 xen/arch/arm/p2m.c|  2 +-
 xen/arch/x86/dom0_build.c |  2 +-
 xen/arch/x86/domctl.c |  4 +--
 xen/arch/x86/hvm/hvm.c|  6 ++--
 xen/arch/x86/hvm/vioapic.c|  2 +-
 xen/arch/x86/hvm/vmx/vmcs.c   |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c|  2 +-
 xen/arch/x86/mm/p2m-ept.c |  4 +--
 xen/drivers/passthrough/amd/iommu_guest.c |  2 +-
 xen/drivers/passthrough/device_tree.c |  4 +--
 xen/drivers/passthrough/io.c  |  8 ++---
 xen/drivers/passthrough/iommu.c   | 39 ---
 xen/drivers/passthrough/pci.c | 16 +-
 xen/drivers/passthrough/vtd/iommu.c   |  2 +-
 xen/drivers/passthrough/vtd/x86/hvm.c |  2 +-
 xen/drivers/passthrough/x86/iommu.c   |  2 +-
 xen/xsm/flask/hooks.c | 18 +--
 17 files changed, 59 insertions(+), 58 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index e28ea1c85a..7f1442932a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1531,7 +1531,7 @@ int p2m_init(struct domain *d)
  * shared with the CPU, Xen has to make sure that the PT changes have
  * reached the memory
  */
-p2m->clean_pte = iommu_enabled &&
+p2m->clean_pte = is_iommu_enabled(d) &&
 !iommu_has_feature(d, IOMMU_FEAT_COHERENT_WALK);
 
 rc = p2m_alloc_table(d);
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index c69570920c..d381784edd 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -356,7 +356,7 @@ unsigned long __init dom0_compute_nr_pages(
 avail -= d->max_vcpus - 1;
 
 /* Reserve memory for iommu_dom0_init() (rough estimate). */
-if ( iommu_enabled )
+if ( is_iommu_enabled(d) )
 {
 unsigned int s;
 
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 2d45e5b8a8..be4b206068 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -715,7 +715,7 @@ long arch_do_domctl(
 break;
 
 ret = -ESRCH;
-if ( iommu_enabled )
+if ( is_iommu_enabled(d) )
 {
 pcidevs_lock();
 ret = pt_irq_create_bind(d, bind);
@@ -744,7 +744,7 @@ long arch_do_domctl(
 if ( ret )
 break;
 
-if ( iommu_enabled )
+if ( is_iommu_enabled(d) )
 {
 pcidevs_lock();
 ret = pt_irq_destroy_bind(d, bind);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 029eea3b85..172c860acc 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -465,7 +465,7 @@ void hvm_migrate_timers(struct vcpu *v)
 
 void hvm_migrate_pirq(struct hvm_pirq_dpci *pirq_dpci, const struct vcpu *v)
 {
-ASSERT(iommu_enabled &&
+ASSERT(is_iommu_enabled(v->domain) &&
(is_hardware_domain(v->domain) || hvm_domain_irq(v->domain)->dpci));
 
 if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MACH_MSI) &&
@@ -496,7 +496,7 @@ void hvm_migrate_pirqs(struct vcpu *v)
 {
 struct domain *d = v->domain;
 
-if ( !iommu_enabled || !hvm_domain_irq(d)->dpci )
+if 

[Xen-devel] [PATCH v6 08/10] remove late (on-demand) construction of IOMMU page tables

[Paul Durrant]

Now that there is a per-domain IOMMU enable flag, which should be enabled if
any device is going to be passed through, stop deferring page table
construction until the assignment is done. Also don't tear down the tables
again when the last device is de-assigned; defer that task until domain
destruction.

This allows the has_iommu_pt() helper and iommu_status enumeration to be
removed. Calls to has_iommu_pt() are simply replaced by calls to
is_iommu_enabled(). Remaining open-code tests of iommu_hap_pt_share can also
be replaced by calls to iommu_use_hap_pt().
The arch_iommu_populate_page_table() and iommu_construct() functions become
redundant, as does the 'strict mode' dom0 page_list mapping code in
iommu_hwdom_init(), and iommu_teardown() can be made static is its only
remaining caller, iommu_domain_destroy(), is within the same source
module.

All in all, about 220 lines of code are removed.

NOTE: This patch will cause a small amount of extra resource to be used
  to accommodate IOMMU page tables that may never be used, since the
  per-domain IOMMU flag enable flag is currently set to the value
  of the global iommu_enable flag. A subsequent patch will add an
  option to the toolstack to allow it to be turned off if there is
  no intention to assign passthrough hardware to the domain.

Signed-off-by: Paul Durrant 
Reviewed-by: Alexandru Isaila 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Volodymyr Babchuk 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: Tamas K Lengyel 
Cc: George Dunlap 
Cc: Razvan Cojocaru 
Cc: Petre Pircalabu 

Previously part of series 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html

v5:
 - Minor style fixes
---
 xen/arch/arm/p2m.c|   2 +-
 xen/arch/x86/dom0_build.c |   2 +-
 xen/arch/x86/hvm/mtrr.c   |   5 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/mm/paging.c  |   2 +-
 xen/arch/x86/x86_64/mm.c  |   2 +-
 xen/common/memory.c   |   4 +-
 xen/common/vm_event.c |   2 +-
 xen/drivers/passthrough/device_tree.c |  11 ---
 xen/drivers/passthrough/iommu.c   | 134 ++
 xen/drivers/passthrough/pci.c |  12 ---
 xen/drivers/passthrough/vtd/iommu.c   |  10 +-
 xen/drivers/passthrough/x86/iommu.c   |  95 --
 xen/include/asm-arm/iommu.h   |   2 +-
 xen/include/asm-x86/iommu.h   |   2 +-
 xen/include/xen/iommu.h   |  16 ---
 xen/include/xen/sched.h   |   2 -
 17 files changed, 42 insertions(+), 263 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 7f1442932a..692565757e 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1056,7 +1056,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
  !mfn_eq(lpae_get_mfn(*entry), lpae_get_mfn(orig_pte)) )
 p2m_free_entry(p2m, orig_pte, level);
 
-if ( has_iommu_pt(p2m->domain) &&
+if ( is_iommu_enabled(p2m->domain) &&
  (lpae_is_valid(orig_pte) || lpae_is_valid(*entry)) )
 {
 unsigned int flush_flags = 0;
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index d381784edd..7cfab2dc25 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -365,7 +365,7 @@ unsigned long __init dom0_compute_nr_pages(
 }
 
 need_paging = is_hvm_domain(d) &&
-(!iommu_hap_pt_share || !paging_mode_hap(d));
+(!iommu_use_hap_pt(d) || !paging_mode_hap(d));
 for ( ; ; need_paging = false )
 {
 nr_pages = get_memsize(_size, avail);
diff --git a/xen/arch/x86/hvm/mtrr.c b/xen/arch/x86/hvm/mtrr.c
index 7ccd85bcea..5ad15eafe0 100644
--- a/xen/arch/x86/hvm/mtrr.c
+++ b/xen/arch/x86/hvm/mtrr.c
@@ -783,7 +783,8 @@ HVM_REGISTER_SAVE_RESTORE(MTRR, hvm_save_mtrr_msr, 
hvm_load_mtrr_msr, 1,
 
 void memory_type_changed(struct domain *d)
 {
-if ( (has_iommu_pt(d) || cache_flush_permitted(d)) && d->vcpu && 
d->vcpu[0] )
+if ( (is_iommu_enabled(d) || cache_flush_permitted(d)) &&
+ d->vcpu && d->vcpu[0] )
 {
 p2m_memory_type_changed(d);
 flush_all(FLUSH_CACHE);
@@ -831,7 +832,7 @@ int epte_get_entry_emt(struct domain *d, unsigned long gfn, 
mfn_t mfn,
 return MTRR_TYPE_UNCACHABLE;
 }
 
-if ( !has_iommu_pt(d) && !cache_flush_permitted(d) )
+if ( !is_iommu_enabled(d) && !cache_flush_permitted(d) )
 {
 *ipat = 1;
 return MTRR_TYPE_WRBACK;
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index a5fe89e339..efb8821768 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1664,7 +1664,7 @@ int mem_sharing_domctl(struct domain *d, struct 
xen_domctl_mem_sharing_op *mec)
 case XEN_DOMCTL_MEM_SHARING_CONTROL:
 {
 rc = 0;
-if ( 

[Xen-devel] [PATCH v6 02/10] x86/hvm/domain: remove the 'hap_enabled' flag

[Paul Durrant]

The hap_enabled() macro can determine whether the feature is available
using the domain 'options'; there is no need for a separate flag.

NOTE: Furthermore, by extending sanitiziing of the domain 'options', the
  macro can be transformed into an inline function and re-located to
  xen/sched.h. This also makes hap_enabled() common, thus allowing
  removal of an ugly ifdef CONFIG_X86 from the common iommu code.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: George Dunlap 

v4:
 - Add missing perentheses and move hap_enabled()
 - Fix the shim build

v3:
 - Re-worked as suggested by Jan
 - Not adding Roger's R-b as the patch has changed substantially

v2:
 - Defer changes to shadow_domain_init() to patch #4
---
 xen/arch/x86/domain.c| 13 +++--
 xen/arch/x86/mm/paging.c |  4 ++--
 xen/common/domain.c  |  7 +++
 xen/drivers/passthrough/iommu.c  |  2 --
 xen/include/asm-x86/hvm/domain.h |  7 ---
 xen/include/asm-x86/paging.h |  2 +-
 xen/include/xen/sched.h  |  6 ++
 7 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 9a6eb89ddc..bc0db03387 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -460,6 +460,12 @@ int arch_sanitise_domain_config(struct 
xen_domctl_createdomain *config)
 return -EINVAL;
 }
 
+if ( (config->flags & XEN_DOMCTL_CDF_hap) && !hvm_hap_supported() )
+{
+dprintk(XENLOG_INFO, "HAP enabled but not supported\n");
+return -EINVAL;
+}
+
 return 0;
 }
 
@@ -564,12 +570,7 @@ int arch_domain_create(struct domain *d,
 HYPERVISOR_COMPAT_VIRT_START(d) =
 is_pv_domain(d) ? __HYPERVISOR_COMPAT_VIRT_START : ~0u;
 
-/* Need to determine if HAP is enabled before initialising paging */
-if ( is_hvm_domain(d) )
-d->arch.hvm.hap_enabled =
-hvm_hap_supported() && (config->flags & XEN_DOMCTL_CDF_hap);
-
-if ( (rc = paging_domain_init(d, config->flags)) != 0 )
+if ( (rc = paging_domain_init(d)) != 0 )
 goto fail;
 paging_initialised = true;
 
diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 011089368a..097a27f608 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -632,7 +632,7 @@ void paging_log_dirty_init(struct domain *d, const struct 
log_dirty_ops *ops)
 /*   CODE FOR PAGING SUPPORT*/
 //
 /* Domain paging struct initialization. */
-int paging_domain_init(struct domain *d, unsigned int domcr_flags)
+int paging_domain_init(struct domain *d)
 {
 int rc;
 
@@ -653,7 +653,7 @@ int paging_domain_init(struct domain *d, unsigned int 
domcr_flags)
 if ( hap_enabled(d) )
 hap_domain_init(d);
 else
-rc = shadow_domain_init(d, domcr_flags);
+rc = shadow_domain_init(d, d->options);
 
 return rc;
 }
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 744b572195..6109623730 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -313,6 +313,13 @@ static int sanitise_domain_config(struct 
xen_domctl_createdomain *config)
 return -EINVAL;
 }
 
+if ( !(config->flags & XEN_DOMCTL_CDF_hvm_guest) &&
+ (config->flags & XEN_DOMCTL_CDF_hap) )
+{
+dprintk(XENLOG_INFO, "HAP enabled for non-HVM guest\n");
+return -EINVAL;
+}
+
 return arch_sanitise_domain_config(config);
 }
 
diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index f8c3bf53bd..37eb0f7d01 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -573,9 +573,7 @@ int iommu_do_domctl(
 
 void iommu_share_p2m_table(struct domain* d)
 {
-#ifdef CONFIG_X86
 ASSERT(hap_enabled(d));
-#endif
 /*
  * iommu_use_hap_pt(d) cannot be used here because during domain
  * construction need_iommu(d) will always return false here.
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 6c7c4f5aa6..bcc5621797 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -156,7 +156,6 @@ struct hvm_domain {
 
 struct viridian_domain *viridian;
 
-bool_t hap_enabled;
 bool_t mem_sharing_enabled;
 bool_t qemu_mapcache_invalidate;
 bool_t is_s3_suspended;
@@ -195,12 +194,6 @@ struct hvm_domain {
 };
 };
 
-#ifdef CONFIG_HVM
-#define hap_enabled(d)  (is_hvm_domain(d) && (d)->arch.hvm.hap_enabled)
-#else
-#define hap_enabled(d)  ({(void)(d); false;})
-#endif
-
 #endif /* __ASM_X86_HVM_DOMAIN_H__ */
 
 /*
diff --git a/xen/include/asm-x86/paging.h b/xen/include/asm-x86/paging.h
index cf57ca708d..ab7887f23c 100644
--- 

[Xen-devel] [PATCH v6 00/10] use stashed domain create flags...

[Paul Durrant]

...and add per-domain IOMMU control

This is a combination of my previously separate series [1] and [2].

[1] https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02253.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html

Paul Durrant (10):
  make passthrough/pci.c:deassign_device() static
  x86/hvm/domain: remove the 'hap_enabled' flag
  x86/domain: remove the 'oos_off' flag
  domain: remove the 'is_xenstore' flag
  x86/domain: remove the 's3_integrity' flag
  domain: introduce XEN_DOMCTL_CDF_iommu flag
  use is_iommu_enabled() where appropriate...
  remove late (on-demand) construction of IOMMU page tables
  iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros
  introduce a 'passthrough' configuration option to xl.cfg...

 docs/man/xl.cfg.5.pod.in  |  52 +++
 tools/libxl/libxl.h   |   5 +
 tools/libxl/libxl_create.c|   9 ++
 tools/libxl/libxl_types.idl   |   7 +
 tools/xl/xl_parse.c   |  38 +
 xen/arch/arm/domain.c |  10 +-
 xen/arch/arm/p2m.c|   4 +-
 xen/arch/arm/setup.c  |   3 +
 xen/arch/x86/dom0_build.c |   4 +-
 xen/arch/x86/domain.c |  24 +--
 xen/arch/x86/domctl.c |   4 +-
 xen/arch/x86/hvm/hvm.c|   6 +-
 xen/arch/x86/hvm/mtrr.c   |   5 +-
 xen/arch/x86/hvm/vioapic.c|   2 +-
 xen/arch/x86/hvm/vmx/vmcs.c   |   2 +-
 xen/arch/x86/hvm/vmx/vmx.c|   2 +-
 xen/arch/x86/mm/mem_sharing.c |   2 +-
 xen/arch/x86/mm/p2m-ept.c |   4 +-
 xen/arch/x86/mm/paging.c  |   6 +-
 xen/arch/x86/mm/shadow/common.c   |   7 +-
 xen/arch/x86/mm/shadow/none.c |   2 +-
 xen/arch/x86/setup.c  |   5 +-
 xen/arch/x86/tboot.c  |   2 +-
 xen/arch/x86/x86_64/mm.c  |   2 +-
 xen/common/domain.c   |  40 -
 xen/common/domctl.c   |  10 +-
 xen/common/memory.c   |   4 +-
 xen/common/vm_event.c |   2 +-
 xen/drivers/passthrough/amd/iommu_guest.c |   2 +-
 xen/drivers/passthrough/device_tree.c |  18 +--
 xen/drivers/passthrough/io.c  |   8 +-
 xen/drivers/passthrough/iommu.c   | 182 +++---
 xen/drivers/passthrough/pci.c | 119 +++---
 xen/drivers/passthrough/vtd/iommu.c   |  12 +-
 xen/drivers/passthrough/vtd/x86/hvm.c |   2 +-
 xen/drivers/passthrough/x86/iommu.c   |  97 +---
 xen/include/asm-arm/iommu.h   |   3 -
 xen/include/asm-x86/domain.h  |   3 -
 xen/include/asm-x86/hvm/domain.h  |   7 -
 xen/include/asm-x86/iommu.h   |   4 -
 xen/include/asm-x86/paging.h  |   2 +-
 xen/include/asm-x86/shadow.h  |   2 +-
 xen/include/public/domctl.h   |  10 +-
 xen/include/xen/iommu.h   |  41 ++---
 xen/include/xen/sched.h   |  26 ++--
 xen/include/xsm/dummy.h   |   2 +-
 xen/xsm/flask/hooks.c |  18 +--
 47 files changed, 399 insertions(+), 422 deletions(-)
---
Cc: Andrew Cooper 
Cc: Anthony PERARD 
Cc: Brian Woods 
Cc: Daniel De Graaf 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Konrad Rzeszutek Wilk 
Cc: Petre Pircalabu 
Cc: Razvan Cojocaru 
Cc: "Roger Pau Monné" 
Cc: Stefano Stabellini 
Cc: Suravee Suthikulpanit 
Cc: Tamas K Lengyel 
Cc: Tim Deegan 
Cc: Volodymyr Babchuk 
Cc: Wei Liu 
-- 
2.20.1.2.gb21ebb671


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

[Xen-devel] [PATCH v6 03/10] x86/domain: remove the 'oos_off' flag

[Paul Durrant]

The flag is not needed since the domain 'options' can now be tested
directly.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
---
Cc: Tim Deegan 
Cc: George Dunlap 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 

v3:
 - Force 'oos_off' to be set for PV guests (to avoid call to
   is_hvm_domain() except in ASSERT)
 - Dropped Tim's A-b because of the change

v2:
 - Move some of the hunks from patch #3
 - Also update the definition of shadow_domain_init() in none.c
---
 xen/arch/x86/mm/paging.c|  2 +-
 xen/arch/x86/mm/shadow/common.c |  7 ---
 xen/arch/x86/mm/shadow/none.c   |  2 +-
 xen/common/domain.c | 16 
 xen/include/asm-x86/domain.h|  1 -
 xen/include/asm-x86/shadow.h|  2 +-
 6 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c
index 097a27f608..69aa228e46 100644
--- a/xen/arch/x86/mm/paging.c
+++ b/xen/arch/x86/mm/paging.c
@@ -653,7 +653,7 @@ int paging_domain_init(struct domain *d)
 if ( hap_enabled(d) )
 hap_domain_init(d);
 else
-rc = shadow_domain_init(d, d->options);
+rc = shadow_domain_init(d);
 
 return rc;
 }
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index fa18de0bb6..1187176993 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -46,7 +46,7 @@ static void sh_clean_dirty_bitmap(struct domain *);
 
 /* Set up the shadow-specific parts of a domain struct at start of day.
  * Called for every domain from arch_domain_create() */
-int shadow_domain_init(struct domain *d, unsigned int domcr_flags)
+int shadow_domain_init(struct domain *d)
 {
 static const struct log_dirty_ops sh_ops = {
 .enable  = sh_enable_log_dirty,
@@ -62,7 +62,6 @@ int shadow_domain_init(struct domain *d, unsigned int 
domcr_flags)
 
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 d->arch.paging.shadow.oos_active = 0;
-d->arch.paging.shadow.oos_off = domcr_flags & XEN_DOMCTL_CDF_oos_off;
 #endif
 d->arch.paging.shadow.pagetable_dying_op = 0;
 
@@ -2523,11 +2522,13 @@ static void sh_update_paging_modes(struct vcpu *v)
 #if (SHADOW_OPTIMIZATIONS & SHOPT_OUT_OF_SYNC)
 /* We need to check that all the vcpus have paging enabled to
  * unsync PTs. */
-if ( is_hvm_domain(d) && !d->arch.paging.shadow.oos_off )
+if ( !(d->options & XEN_DOMCTL_CDF_oos_off) )
 {
 int pe = 1;
 struct vcpu *vptr;
 
+ASSERT(is_hvm_domain(d));
+
 for_each_vcpu(d, vptr)
 {
 if ( !hvm_paging_enabled(vptr) )
diff --git a/xen/arch/x86/mm/shadow/none.c b/xen/arch/x86/mm/shadow/none.c
index a70888bd98..2fddf4274c 100644
--- a/xen/arch/x86/mm/shadow/none.c
+++ b/xen/arch/x86/mm/shadow/none.c
@@ -18,7 +18,7 @@ static void _clean_dirty_bitmap(struct domain *d)
 ASSERT(is_pv_domain(d));
 }
 
-int shadow_domain_init(struct domain *d, unsigned int domcr_flags)
+int shadow_domain_init(struct domain *d)
 {
 static const struct log_dirty_ops sh_none_ops = {
 .enable  = _enable_log_dirty,
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6109623730..95321482ef 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -313,11 +313,19 @@ static int sanitise_domain_config(struct 
xen_domctl_createdomain *config)
 return -EINVAL;
 }
 
-if ( !(config->flags & XEN_DOMCTL_CDF_hvm_guest) &&
- (config->flags & XEN_DOMCTL_CDF_hap) )
+if ( !(config->flags & XEN_DOMCTL_CDF_hvm_guest) )
 {
-dprintk(XENLOG_INFO, "HAP enabled for non-HVM guest\n");
-return -EINVAL;
+if ( config->flags & XEN_DOMCTL_CDF_hap )
+{
+dprintk(XENLOG_INFO, "HAP enabled for non-HVM guest\n");
+return -EINVAL;
+}
+
+/*
+ * It is only meaningful for XEN_DOMCTL_CDF_oos_off to be clear
+ * for HVM guests.
+ */
+config->flags |= XEN_DOMCTL_CDF_oos_off;
 }
 
 return arch_sanitise_domain_config(config);
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 933b85901f..5f9899469c 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -115,7 +115,6 @@ struct shadow_domain {
 
 /* OOS */
 bool_t oos_active;
-bool_t oos_off;
 
 /* Has this domain ever used HVMOP_pagetable_dying? */
 bool_t pagetable_dying_op;
diff --git a/xen/include/asm-x86/shadow.h b/xen/include/asm-x86/shadow.h
index f29f0f652b..8ebb89c027 100644
--- a/xen/include/asm-x86/shadow.h
+++ b/xen/include/asm-x86/shadow.h
@@ -49,7 +49,7 @@
 
 /* Set up the shadow-specific parts of a domain struct at start of day.
  * Called from paging_domain_init(). */
-int shadow_domain_init(struct domain *d, unsigned int domcr_flags);
+int shadow_domain_init(struct domain *d);
 
 /* Setup the shadow-specific parts of a vcpu struct. It is called by
  * paging_vcpu_init() in paging.c */
-- 
2.20.1.2.gb21ebb671

[Xen-devel] [PATCH v6 09/10] iommu: tidy up iommu_use_hap_pt() and need_iommu_pt_sync() macros

[Paul Durrant]

Thes macros really ought to live in the common xen/iommu.h header rather
then being distributed amongst architecture specific iommu headers and
xen/sched.h. This patch moves them there.

NOTE: Disabling 'sharept' in the command line iommu options should really
  be hard error on ARM (as opposed to just being ignored), so avoid
  parsing that option if CONFIG_ARM is set.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Volodymyr Babchuk 
Cc: "Roger Pau Monné" 

Previously part of 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html
---
 xen/drivers/passthrough/iommu.c |  2 ++
 xen/include/asm-arm/iommu.h |  3 ---
 xen/include/asm-x86/iommu.h |  4 
 xen/include/xen/iommu.h | 11 +++
 xen/include/xen/sched.h |  6 --
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
index dc7b75fab6..b24be5ffa6 100644
--- a/xen/drivers/passthrough/iommu.c
+++ b/xen/drivers/passthrough/iommu.c
@@ -102,8 +102,10 @@ static int __init parse_iommu_param(const char *s)
 iommu_hwdom_passthrough = val;
 else if ( (val = parse_boolean("dom0-strict", s, ss)) >= 0 )
 iommu_hwdom_strict = val;
+#ifndef CONFIG_ARM
 else if ( (val = parse_boolean("sharept", s, ss)) >= 0 )
 iommu_hap_pt_share = val;
+#endif
 else
 rc = -EINVAL;
 
diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 1577e83d2b..77a94b29eb 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -20,9 +20,6 @@ struct arch_iommu
 void *priv;
 };
 
-/* Always share P2M Table between the CPU and the IOMMU */
-#define iommu_use_hap_pt(d) is_iommu_enabled(d)
-
 const struct iommu_ops *iommu_get_ops(void);
 void iommu_set_ops(const struct iommu_ops *ops);
 
diff --git a/xen/include/asm-x86/iommu.h b/xen/include/asm-x86/iommu.h
index 6d024d5c0e..25d2aee9a9 100644
--- a/xen/include/asm-x86/iommu.h
+++ b/xen/include/asm-x86/iommu.h
@@ -79,10 +79,6 @@ struct iommu_init_ops {
 
 extern const struct iommu_init_ops *iommu_init_ops;
 
-/* Are we using the domain P2M table as its IOMMU pagetable? */
-#define iommu_use_hap_pt(d) \
-(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
-
 void iommu_update_ire_from_apic(unsigned int apic, unsigned int reg, unsigned 
int value);
 unsigned int iommu_read_apic_from_ire(unsigned int apic, unsigned int reg);
 int iommu_setup_hpet_msi(struct msi_desc *);
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 4b6871936c..5e7ca98170 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -268,6 +268,17 @@ struct domain_iommu {
 #define iommu_set_feature(d, f)   set_bit(f, dom_iommu(d)->features)
 #define iommu_clear_feature(d, f) clear_bit(f, dom_iommu(d)->features)
 
+/* Are we using the domain P2M table as its IOMMU pagetable? */
+#define iommu_use_hap_pt(d) \
+(hap_enabled(d) && is_iommu_enabled(d) && iommu_hap_pt_share)
+
+/* Does the IOMMU pagetable need to be kept synchronized with the P2M */
+#ifdef CONFIG_HAS_PASSTHROUGH
+#define need_iommu_pt_sync(d) (dom_iommu(d)->need_sync)
+#else
+#define need_iommu_pt_sync(d) false
+#endif
+
 int __must_check iommu_suspend(void);
 void iommu_resume(void);
 void iommu_crash_shutdown(void);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index b376768424..7e4c24f8d0 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -964,12 +964,6 @@ static inline bool is_hwdom_pinned_vcpu(const struct vcpu 
*v)
 cpumask_weight(v->cpu_hard_affinity) == 1);
 }
 
-#ifdef CONFIG_HAS_PASSTHROUGH
-#define need_iommu_pt_sync(d) (dom_iommu(d)->need_sync)
-#else
-#define need_iommu_pt_sync(d) false
-#endif
-
 static inline bool is_vcpu_online(const struct vcpu *v)
 {
 return !test_bit(_VPF_down, >pause_flags);
-- 
2.20.1.2.gb21ebb671


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

[Xen-devel] [PATCH v6 06/10] domain: introduce XEN_DOMCTL_CDF_iommu flag

[Paul Durrant]

This patch introduces a common domain creation flag to determine whether
the domain is permitted to make use of the IOMMU. Currently the flag is
always set (for both dom0 and domU) if the IOMMU is globally enabled
(i.e. iommu_enabled == 1). sanitise_domain_config() is modified to reject
the flag if !iommu_enabled.

A new helper function, is_iommu_enabled(), is added to test the flag and
iommu_domain_init() will return immediately if !is_iommu_enabled(). This is
slightly different to the previous behaviour based on !iommu_enabled where
the call to arch_iommu_domain_init() was made regardless, however it appears
that this call was only necessary to initialize the dt_devices list for ARM
such that iommu_release_dt_devices() can be called unconditionally by
domain_relinquish_resources(). Adding a simple check of is_iommu_enabled()
into iommu_release_dt_devices() keeps this unconditional call working.

No functional change should be observed with this patch applied.

Subsequent patches will allow the toolstack to control whether use of the
IOMMU is enabled for a domain.

NOTE: The introduction of the is_iommu_enabled() helper function might
  seem excessive but its use is expected to increase with subsequent
  patches. Also, having iommu_domain_init() bail before calling
  arch_iommu_domain_init() is not strictly necessary, but I think the
  consequent addition of the call to is_iommu_enabled() in
  iommu_release_dt_devices() makes the code clearer.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Anthony PERARD 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Volodymyr Babchuk 
Cc: "Roger Pau Monné" 

Previously part of series 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html

v6:
 - Remove the toolstack parts as there's no nice method of testing whether
   the IOMMU is enabled in an architecture-neutral way

v5:
 - Move is_iommu_enabled() check into iommu_domain_init()
 - Reject XEN_DOMCTL_CDF_iommu in sanitise_domain_config() if !iommu_enabled
 - Use evaluate_nospec() in defintion of is_iommu_enabled()
---
 xen/arch/arm/setup.c  | 3 +++
 xen/arch/x86/setup.c  | 3 +++
 xen/common/domain.c   | 9 -
 xen/common/domctl.c   | 8 
 xen/drivers/passthrough/device_tree.c | 3 +++
 xen/drivers/passthrough/iommu.c   | 6 +++---
 xen/include/public/domctl.h   | 4 
 xen/include/xen/sched.h   | 5 +
 8 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 2c5d1372c0..20021ee0ca 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -914,6 +914,9 @@ void __init start_xen(unsigned long boot_phys_offset,
 dom0_cfg.arch.tee_type = tee_get_type();
 dom0_cfg.max_vcpus = dom0_max_vcpus();
 
+if ( iommu_enabled )
+dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
 dom0 = domain_create(0, _cfg, true);
 if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
 panic("Error creating domain 0\n");
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index d0b35b0ce2..fa226a2bab 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1733,6 +1733,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 }
 dom0_cfg.max_vcpus = dom0_max_vcpus();
 
+if ( iommu_enabled )
+dom0_cfg.flags |= XEN_DOMCTL_CDF_iommu;
+
 /* Create initial domain 0. */
 dom0 = domain_create(get_initial_domain_id(), _cfg, !pv_shim);
 if ( IS_ERR(dom0) || (alloc_dom0_vcpu0(dom0) == NULL) )
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 76e6976617..e832a5c4aa 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -301,7 +301,8 @@ static int sanitise_domain_config(struct 
xen_domctl_createdomain *config)
XEN_DOMCTL_CDF_hap |
XEN_DOMCTL_CDF_s3_integrity |
XEN_DOMCTL_CDF_oos_off |
-   XEN_DOMCTL_CDF_xs_domain) )
+   XEN_DOMCTL_CDF_xs_domain |
+   XEN_DOMCTL_CDF_iommu) )
 {
 dprintk(XENLOG_INFO, "Unknown CDF flags %#x\n", config->flags);
 return -EINVAL;
@@ -328,6 +329,12 @@ static int sanitise_domain_config(struct 
xen_domctl_createdomain *config)
 config->flags |= XEN_DOMCTL_CDF_oos_off;
 }
 
+if ( (config->flags & XEN_DOMCTL_CDF_iommu) && !iommu_enabled )
+{
+dprintk(XENLOG_INFO, "IOMMU is not enabled\n");
+return -EINVAL;
+}
+
 return arch_sanitise_domain_config(config);
 }
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 6e6e9b9866..fddf20f1b5 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -515,6 +515,14 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 rover = dom;
  

[Xen-devel] [PATCH v6 04/10] domain: remove the 'is_xenstore' flag

[Paul Durrant]

This patch introduces a convenience macro, is_xenstore_domain(), which
tests the domain 'options' directly and then uses that in place of
the 'is_xenstore' flag.

Signed-off-by: Paul Durrant 
Reviewed-by: "Roger Pau Monné" 
Acked-by: George Dunlap 
---
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Daniel De Graaf 

v2:
 - Set 'disable_migrate' to true rather 1
---
 xen/common/domain.c | 9 +++--
 xen/common/domctl.c | 2 +-
 xen/include/xen/sched.h | 7 +--
 xen/include/xsm/dummy.h | 2 +-
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 95321482ef..76e6976617 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -363,7 +363,7 @@ struct domain *domain_create(domid_t domid,
 if ( hardware_domid < 0 || hardware_domid >= DOMID_FIRST_RESERVED )
 panic("The value of hardware_dom must be a valid domain ID\n");
 
-d->disable_migrate = 1;
+d->disable_migrate = true;
 old_hwdom = hardware_domain;
 hardware_domain = d;
 }
@@ -442,11 +442,8 @@ struct domain *domain_create(domid_t domid,
 watchdog_domain_init(d);
 init_status |= INIT_watchdog;
 
-if ( d->options & XEN_DOMCTL_CDF_xs_domain )
-{
-d->is_xenstore = 1;
-d->disable_migrate = 1;
-}
+if ( is_xenstore_domain(d) )
+d->disable_migrate = true;
 
 d->iomem_caps = rangeset_new(d, "I/O Memory", 
RANGESETF_prettyprint_hex);
 d->irq_caps   = rangeset_new(d, "Interrupts", 0);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index b48e408583..6e6e9b9866 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -186,7 +186,7 @@ void getdomaininfo(struct domain *d, struct 
xen_domctl_getdomaininfo *info)
 (d->is_shut_down? XEN_DOMINF_shutdown  : 0) |
 (d->controller_pause_count > 0  ? XEN_DOMINF_paused: 0) |
 (d->debugger_attached   ? XEN_DOMINF_debugged  : 0) |
-(d->is_xenstore ? XEN_DOMINF_xs_domain : 0) |
+(is_xenstore_domain(d)  ? XEN_DOMINF_xs_domain : 0) |
 (is_hvm_domain(d)   ? XEN_DOMINF_hvm_guest : 0) |
 d->shutdown_code << XEN_DOMINF_shutdownshift;
 
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 07a64947ed..df331a3bb0 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -375,8 +375,6 @@ struct domain
 bool is_privileged;
 /* Can this guest access the Xen console? */
 bool is_console;
-/* Is this a xenstore domain (not dom0)? */
-bool is_xenstore;
 /* Non-migratable and non-restoreable? */
 bool disable_migrate;
 /* Is this guest being debugged by dom0? */
@@ -979,6 +977,11 @@ static inline bool is_vcpu_online(const struct vcpu *v)
 return !test_bit(_VPF_down, >pause_flags);
 }
 
+static inline bool is_xenstore_domain(const struct domain *d)
+{
+return d->options & XEN_DOMCTL_CDF_xs_domain;
+}
+
 extern bool sched_smt_power_savings;
 
 extern enum cpufreq_controller {
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index ef52bb1764..b8e185e6fa 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -79,7 +79,7 @@ static always_inline int xsm_default_action(
 {
 return 0;
 case XSM_XS_PRIV:
-if ( src->is_xenstore )
+if ( is_xenstore_domain(src) )
 return 0;
 }
 /* fall through */
-- 
2.20.1.2.gb21ebb671


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

[Xen-devel] [PATCH v6 05/10] x86/domain: remove the 's3_integrity' flag

[Paul Durrant]

The flag is not needed since the domain 'options' can now be tested
directly.

Signed-off-by: Paul Durrant 
Reviewed-by: "Roger Pau Monné" 
Reviewed-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: Wei Liu 

v4:
 - s/TBOOT/CONFIG_TBOOT/g

v3:
 - Also sanitise the flag against CONFIG_TBOOT being set
---
 xen/arch/x86/domain.c| 9 +++--
 xen/arch/x86/setup.c | 2 +-
 xen/arch/x86/tboot.c | 2 +-
 xen/include/asm-x86/domain.h | 2 --
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index bc0db03387..f144d8fe9a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -466,6 +466,13 @@ int arch_sanitise_domain_config(struct 
xen_domctl_createdomain *config)
 return -EINVAL;
 }
 
+if ( (config->flags & XEN_DOMCTL_CDF_s3_integrity) &&
+ !IS_ENABLED(CONFIG_TBOOT) )
+{
+dprintk(XENLOG_INFO, "S3 integrity check not valid without 
CONFIG_TBOOT\n");
+return -EINVAL;
+}
+
 return 0;
 }
 
@@ -544,8 +551,6 @@ int arch_domain_create(struct domain *d,
d->domain_id);
 }
 
-d->arch.s3_integrity = config->flags & XEN_DOMCTL_CDF_s3_integrity;
-
 emflags = config->arch.emulation_flags;
 
 if ( is_hardware_domain(d) && is_pv_domain(d) )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 87fc7c90da..d0b35b0ce2 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -696,7 +696,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 .stop_bits = 1
 };
 struct xen_domctl_createdomain dom0_cfg = {
-.flags = XEN_DOMCTL_CDF_s3_integrity,
+.flags = IS_ENABLED(CONFIG_TBOOT) ? XEN_DOMCTL_CDF_s3_integrity : 0,
 .max_evtchn_port = -1,
 .max_grant_frames = opt_max_grant_frames,
 .max_maptrack_frames = opt_max_maptrack_frames,
diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index f3fdee4d39..3db8a8a8d8 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -212,7 +212,7 @@ static void tboot_gen_domain_integrity(const uint8_t 
key[TB_KEY_SIZE],
 vmac_set_key((uint8_t *)key, );
 for_each_domain( d )
 {
-if ( !d->arch.s3_integrity )
+if ( !(d->options & XEN_DOMCTL_CDF_s3_integrity) )
 continue;
 printk("MACing Domain %u\n", d->domain_id);
 
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 5f9899469c..5c038a1065 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -295,8 +295,6 @@ struct arch_domain
 uint32_t pci_cf8;
 uint8_t cmos_idx;
 
-bool_t s3_integrity;
-
 union {
 struct pv_domain pv;
 struct hvm_domain hvm;
-- 
2.20.1.2.gb21ebb671


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

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-xsm
testid xen-boot

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  41de59634046b19cd53a1983594a95135c656997
  Bug not present: 223cea6a4f0552b86fb25e3b8bbd00469816cd7a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/140207/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-xsm.xen-boot
 --summary-out=tmp/140207.bisection-summary --basis-template=133580 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-xsm xen-boot
Searching for failure / basis pass:
 140163 fail [host=fiano0] / 138849 ok.
Failure / basis pass flights: 140163 / 138849
(tree with no url: minios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 41de59634046b19cd53a1983594a95135c656997 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
f5892aa8d8bfbe8e6af5c9765faad8cfe877c334 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
dbf360567a7da50db4d2f9bde4649aba21aa8106 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
6c9639a72f0ca3a9430ef75f375877182281fdef
Basis pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#223cea6a4f0552b86fb25e3b8bbd00469816cd7a-41de59634046b19cd53a1983594a95135c656997
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#d031fc07eb83c9d13bff3ebac25da458d5a47917-f5892aa8d8bfbe8e6af5c9765faad8cfe877c334
 git://xenbits.xen.org/qemu-xen-traditional.\
 
git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-dbf360567a7da50db4d2f9bde4649aba21aa8106
 
git://xenbits.xen.org/osstest/seabios.git#30f1e41f04fb4c715d27f987f003cfc31c9ff4f3-30f1e41f04fb4c715d27f987f003cfc31c9ff4f3
 
git://xenbits.xen.org/xen.git#843cec0de800a5f925f8071a7f58f3fb1c6b6eb6-6c9639a72f0ca3a9430ef75f375877182281fdef
From 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
   2d63ba3e41db..b7e7c85dc7b0  master -> origin/master
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 3006 nodes in revision graph
Searching for test results:
 138780 [host=italia1]
 138813 [host=albana1]
 138849 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
 138897 pass 223cea6a4f0552b86fb25e3b8bbd00469816cd7a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d031fc07eb83c9d13bff3ebac25da458d5a47917 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
30f1e41f04fb4c715d27f987f003cfc31c9ff4f3 
843cec0de800a5f925f8071a7f58f3fb1c6b6eb6
 138878 fail irrelevant
 138899 pass irrelevant
 138900 pass irrelevant
 138901 pass irrelevant
 138902 fail irrelevant
 138879 pass irrelevant
 138962 fail irrelevant
 139003 fail irrelevant
 139068 fail irrelevant
 139134 fail irrelevant
 139237 fail irrelevant
 139223 fail irrelevant
 139257 fail irrelevant
 139324 fail irrelevant
 139306 fail irrelevant
 139286 fail irrelevant
 139338 fail irrelevant
 139361 fail irrelevant
 139383 fail irrelevant
 139408 fail irrelevant
 139478 fail irrelevant
 139532 fail irrelevant
 139584 fail irrelevant
 139555 fail irrelevant
 

Re: [Xen-devel] [PATCH 03/11] xen/arm: pass one less argument to dma_cache_maint

[Christoph Hellwig]

On Fri, Aug 16, 2019 at 02:37:58PM +0100, Robin Murphy wrote:
> On 16/08/2019 14:00, Christoph Hellwig wrote:
>> Instead of taking apart the dma address in both callers do it inside
>> dma_cache_maint itself.
>>
>> Signed-off-by: Christoph Hellwig 
>> ---
>>   arch/arm/xen/mm.c | 10 ++
>>   1 file changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
>> index 90574d89d0d4..d9da24fda2f7 100644
>> --- a/arch/arm/xen/mm.c
>> +++ b/arch/arm/xen/mm.c
>> @@ -43,13 +43,15 @@ static bool hypercall_cflush = false;
>> /* functions called by SWIOTLB */
>>   -static void dma_cache_maint(dma_addr_t handle, unsigned long offset,
>> -size_t size, enum dma_data_direction dir, enum dma_cache_op op)
>> +static void dma_cache_maint(dma_addr_t handle, size_t size,
>> +enum dma_data_direction dir, enum dma_cache_op op)
>>   {
>>  struct gnttab_cache_flush cflush;
>>  unsigned long xen_pfn;
>> +unsigned long offset = handle & ~PAGE_MASK;
>>  size_t left = size;
>>   +  offset &= PAGE_MASK;
>
> Ahem... presumably that should be handle, not offset.

Ooops, yes.

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

Re: [Xen-devel] [PATCH v6 08/10] remove late (on-demand) construction of IOMMU page tables

[Razvan Cojocaru]

On 8/16/19 8:19 PM, Paul Durrant wrote:
> Now that there is a per-domain IOMMU enable flag, which should be enabled if
> any device is going to be passed through, stop deferring page table
> construction until the assignment is done. Also don't tear down the tables
> again when the last device is de-assigned; defer that task until domain
> destruction.
> 
> This allows the has_iommu_pt() helper and iommu_status enumeration to be
> removed. Calls to has_iommu_pt() are simply replaced by calls to
> is_iommu_enabled(). Remaining open-code tests of iommu_hap_pt_share can also
> be replaced by calls to iommu_use_hap_pt().
> The arch_iommu_populate_page_table() and iommu_construct() functions become
> redundant, as does the 'strict mode' dom0 page_list mapping code in
> iommu_hwdom_init(), and iommu_teardown() can be made static is its only
> remaining caller, iommu_domain_destroy(), is within the same source
> module.
> 
> All in all, about 220 lines of code are removed.
> 
> NOTE: This patch will cause a small amount of extra resource to be used
>   to accommodate IOMMU page tables that may never be used, since the
>   per-domain IOMMU flag enable flag is currently set to the value
>   of the global iommu_enable flag. A subsequent patch will add an
>   option to the toolstack to allow it to be turned off if there is
>   no intention to assign passthrough hardware to the domain.

This has slipped under my radar, sorry.

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: Print the correct domain in initrd_load()

[Volodymyr Babchuk]

Julien Grall writes:

> initrd_load() can be called by other domain than dom0. To avoid
> confusion in the log, print the correct domain.
>
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

But why didn't you gathered all those patches into one patch series?
> ---
>  xen/arch/arm/domain_build.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 126374f603..33171081ea 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1818,8 +1818,8 @@ static void __init initrd_load(struct kernel_info 
> *kinfo)
>  paddr = mod->start;
>  len = mod->size;
>  
> -printk("Loading dom0 initrd from %"PRIpaddr" to 
> 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> -   paddr, load_addr, load_addr + len);
> +printk("Loading %pd initrd from %"PRIpaddr" to 
> 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> +   kinfo->d, paddr, load_addr, load_addr + len);
>  
>  /* Fix up linux,initrd-start and linux,initrd-end in /chosen */
>  node = fdt_path_offset(kinfo->fdt, "/chosen");


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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: Print the correct domain in initrd_load()

[Julien Grall]

On 16/08/2019 17:32, Volodymyr Babchuk wrote:


Julien Grall writes:


initrd_load() can be called by other domain than dom0. To avoid
confusion in the log, print the correct domain.

Signed-off-by: Julien Grall 

Reviewed-by: Volodymyr Babchuk 

But why didn't you gathered all those patches into one patch series?


Because I couldn't be bothered to write a cover letter for it and
they don't depend on each other...

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xen/arm: domain_build: Print the correct domain in dtb_load()

[Volodymyr Babchuk]

Julien Grall writes:

> dtb_load() can be called by other domain than dom0. To avoid confusion
> in the log, print the correct domain.
>
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

>
> ---
> Changes in v2:
> - Fix the second print in the function as well.
> ---
>  xen/arch/arm/domain_build.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 4e51e22927..126374f603 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1787,15 +1787,17 @@ static void __init dtb_load(struct kernel_info *kinfo)
>  {
>  unsigned long left;
>  
> -printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> -   kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
> +printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
> +   kinfo->d, kinfo->dtb_paddr,
> +   kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
>  
>  left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
> kinfo->fdt,
> fdt_totalsize(kinfo->fdt));
>  
>  if ( left != 0 )
> -panic("Unable to copy the DTB to dom0 memory (left = %lu bytes)\n", 
> left);
> +panic("Unable to copy the DTB to %pd memory (left = %lu bytes)\n",
> +  kinfo->d, left);
>  xfree(kinfo->fdt);
>  }


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

Re: [Xen-devel] [PATCH v2 3/4] xen/public: Document HYPERCALL_console_io()

[Julien Grall]

Hi,

On 08/08/2019 15:03, Jan Beulich wrote:

On 05.08.2019 15:29, Julien Grall wrote:

Currently, OS developpers will have to look at Xen code in order to know
the parameters of an hypercall and how it is meant to work.

This is not a trivial task as you may need to have a deep understanding
of Xen internal.

This patch attempts to document the behavior of HYPERCALL_console_io() to
help OS developer.

Signed-off-by: Julien Grall 


Acked-by: Jan Beulich 
with a couple of nits:


--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -486,7 +486,29 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
   /* ` } */
   
   /*

- * Commands to HYPERVISOR_console_io().
+ * ` int
+ * ` HYPERVISOR_console_io(unsigned int cmd,
+ * `   unsigned int count,
+ * `   char buffer[]);
+ *
+ * @cmd: Command (see below)
+ * @count: Size of the buffer to read/write
+ * @buffer: Pointer in the guest memory
+ *
+ * List of commands:
+ *
+ *  * CONSOLEIO_write: Write the buffer on Xen console.


s/ on / to / ?


I am not entirely sure. Looking online [1] "on" would make sense here.

But I am not a native english speaker. @George, @Ian, @Andrew, any opinions?




+ *  For the hardware domain, all the characters in the buffer will
+ *  be written. Characters will be printed to directly to the


The first "to" looks to be unwanted.


Yes, I have dropped it.




+ *  console.
+ *  For all the other domains, only the printable characters will be
+ *  written. Characters may be buffered until a newline (i.e '\n') is
+ *  found.
+ *  @return 0 on success, otherwise return an error code.
+ *  * CONSOLEIO_read: Attempts to read up @count characters from Xen console.


"... up to @count ..."


+ *  The maximum buffer size (i.e @count) supported is 2GB.


"i.e." or "ie" are the two common forms I'm aware of.


Yes, I must have made up that one. I will use the i.e. form.




+ *  @return the number of character read on success, otherwise return


"characters"


Fixed.

Thank you for the ack. I will wait for the on/to discussion to settle before 
committing.


Cheers,

[1] https://idioms.thefreedictionary.com/write+on

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: Remove redundant check in make_vpl011_uart_node()

[Volodymyr Babchuk]

Hi Julien,

Julien Grall writes:

> None of the code since the last check of res modify the value. So the
> check can be removed.
>
> Coverity-ID: 1476824
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

> ---
>  xen/arch/arm/domain_build.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index cf9ffbc360..173544d8c5 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1629,8 +1629,7 @@ static int __init make_vpl011_uart_node(const struct 
> domain *d, void *fdt)
>  dt_child_set_range(, GUEST_ROOT_ADDRESS_CELLS,
> GUEST_ROOT_SIZE_CELLS, GUEST_PL011_BASE,
> GUEST_PL011_SIZE);
> -if ( res )
> -return res;
> +
>  res = fdt_property(fdt, "reg", reg, sizeof(reg));
>  if ( res )
>  return res;


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

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

From: Rich Persaud 
Date: Friday, 16 August 2019 at 16:49
To: George Dunlap 
Cc: Lars Kurth , xen-devel 
, "minios-de...@lists.xenproject.org" 
, "mirageos-de...@lists.xenproject.org" 
, "win-pv-de...@lists.xenproject.org" 
, "committ...@xenproject.org" 

Subject: Re: [Xen-devel] [RFC] Code of Conduct

Snip

Hi George,

Thanks for the detailed response.  Lars noted that the proposed Xen CoC is 
nearly identical to Contributor Covenant, which has been adopted by many 
organizations, including teams at Intel and Google.  My comment, from 
https://lists.gt.net/xen/devel/561686#561686

Without getting into the merits of Contributor Covenant, there is value in 
reusing an "upstream CoC" that has been vetted by many organizations and is 
being continually tested in the real world.


Similar to the "macro supply chain" topic:  if Xen Project must make changes to 
the upstream CoC, these can be done as a logical patch (rather than an orphaned 
fork) so we can incorporate upstream improvements.  The rationale for each diff 
against the upstream CoC can be in a revision-controlled doc, so that future 
CoC maintainers understand the reasoning behind each diff, as communities and 
contributors evolve.

Your discussion above clearly covers differences between Contributor Covenant 
and Xen's CoC, and could be translated to text suitable for commit messages, 
with one commit per diff from an upstream CoC.

Rich

This is not really productive. I was looking for concrete feedback, but we 
ended up with a long discussion with no actionable items that can help resolve 
the discussion.

How about the following:

  *   Make a proposal based on the Contributor Covenant
  *   Try and address some of the key customizations which I have been trying 
to make (which George outlined nicely)

This shouldn’t take much longer than the time you, George and I spent on this 
email thread already. You can follow the methodology you propose

We can then compare the output and decide which one to go for

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

Re: [Xen-devel] [PATCH] xen/arm: domain_build: Print the correct domain in construct_domain()

[Volodymyr Babchuk]

Julien Grall writes:

> construct_domain() can be called by other domain than dom0. To avoid
> confusion in the log, print the correct domain.
>
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

> ---
>  xen/arch/arm/domain_build.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 33171081ea..cf9ffbc360 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1978,7 +1978,7 @@ static int __init construct_domain(struct domain *d, 
> struct kernel_info *kinfo)
>  cpu = cpumask_cycle(cpu, _online_map);
>  if ( vcpu_create(d, i, cpu) == NULL )
>  {
> -printk("Failed to allocate dom0 vcpu %d on pcpu %d\n", i, cpu);
> +printk("Failed to allocate %pd vcpu %d on pcpu %d\n", d, i, cpu);
>  break;
>  }


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

[Xen-devel] [PATCH v6 01/10] make passthrough/pci.c:deassign_device() static

[Paul Durrant]

This function is only ever called from within the same source module and
really has no business being declared xen/iommu.h. This patch relocates
the function ahead of the first called and makes it static.

Signed-off-by: Paul Durrant 
Acked-by: Jan Beulich 
---

Previously part of series 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html

v6:
 - Re-base due to re-positioning in series

v5:
 - minor style fixes
 - use %pd, rather than d%d
---
 xen/drivers/passthrough/pci.c | 99 ++-
 xen/include/xen/iommu.h   |  1 -
 2 files changed, 50 insertions(+), 50 deletions(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 7c196ba58b..89536cc067 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -889,6 +889,56 @@ static int pci_clean_dpci_irqs(struct domain *d)
 return 0;
 }
 
+/* caller should hold the pcidevs_lock */
+static int deassign_device(struct domain *d, uint16_t seg, uint8_t bus,
+   uint8_t devfn)
+{
+const struct domain_iommu *hd = dom_iommu(d);
+struct pci_dev *pdev;
+int ret = 0;
+
+if ( !iommu_enabled || !hd->platform_ops )
+return -EINVAL;
+
+ASSERT(pcidevs_locked());
+pdev = pci_get_pdev_by_domain(d, seg, bus, devfn);
+if ( !pdev )
+return -ENODEV;
+
+while ( pdev->phantom_stride )
+{
+devfn += pdev->phantom_stride;
+if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
+break;
+ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+pci_to_dev(pdev));
+if ( !ret )
+continue;
+
+printk(XENLOG_G_ERR "%pd: deassign %04x:%02x:%02x.%u failed (%d)\n",
+   d, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), ret);
+return ret;
+}
+
+devfn = pdev->devfn;
+ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
+pci_to_dev(pdev));
+if ( ret )
+{
+dprintk(XENLOG_G_ERR,
+"%pd: deassign device (%04x:%02x:%02x.%u) failed\n",
+d, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
+return ret;
+}
+
+pdev->fault.count = 0;
+
+if ( !has_arch_pdevs(d) && has_iommu_pt(d) )
+iommu_teardown(d);
+
+return ret;
+}
+
 int pci_release_devices(struct domain *d)
 {
 struct pci_dev *pdev;
@@ -1476,55 +1526,6 @@ static int assign_device(struct domain *d, u16 seg, u8 
bus, u8 devfn, u32 flag)
 return rc;
 }
 
-/* caller should hold the pcidevs_lock */
-int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn)
-{
-const struct domain_iommu *hd = dom_iommu(d);
-struct pci_dev *pdev = NULL;
-int ret = 0;
-
-if ( !iommu_enabled || !hd->platform_ops )
-return -EINVAL;
-
-ASSERT(pcidevs_locked());
-pdev = pci_get_pdev_by_domain(d, seg, bus, devfn);
-if ( !pdev )
-return -ENODEV;
-
-while ( pdev->phantom_stride )
-{
-devfn += pdev->phantom_stride;
-if ( PCI_SLOT(devfn) != PCI_SLOT(pdev->devfn) )
-break;
-ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
-pci_to_dev(pdev));
-if ( !ret )
-continue;
-
-printk(XENLOG_G_ERR "d%d: deassign %04x:%02x:%02x.%u failed (%d)\n",
-   d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn), ret);
-return ret;
-}
-
-devfn = pdev->devfn;
-ret = hd->platform_ops->reassign_device(d, hardware_domain, devfn,
-pci_to_dev(pdev));
-if ( ret )
-{
-dprintk(XENLOG_G_ERR,
-"d%d: deassign device (%04x:%02x:%02x.%u) failed\n",
-d->domain_id, seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn));
-return ret;
-}
-
-pdev->fault.count = 0;
-
-if ( !has_arch_pdevs(d) && has_iommu_pt(d) )
-iommu_teardown(d);
-
-return ret;
-}
-
 static int iommu_get_device_group(
 struct domain *d, u16 seg, u8 bus, u8 devfn,
 XEN_GUEST_HANDLE_64(uint32) buf, int max_sdevs)
diff --git a/xen/include/xen/iommu.h b/xen/include/xen/iommu.h
index 48f87480a7..314f28f323 100644
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -70,7 +70,6 @@ int iommu_hardware_setup(void);
 int iommu_domain_init(struct domain *d);
 void iommu_hwdom_init(struct domain *d);
 void iommu_domain_destroy(struct domain *d);
-int deassign_device(struct domain *d, u16 seg, u8 bus, u8 devfn);
 
 void arch_iommu_domain_destroy(struct domain *d);
 int arch_iommu_domain_init(struct domain *d);
-- 
2.20.1.2.gb21ebb671


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

[Xen-devel] [PATCH v6 10/10] introduce a 'passthrough' configuration option to xl.cfg...

[Paul Durrant]

...and hence the ability to disable IOMMU mappings, and control EPT
sharing.

This patch introduces a new 'libxl_passthrough' enumeration into
libxl_domain_create_info. The value will be set by xl either when it parses
a new 'passthrough' option in xl.cfg, or implicitly if there is passthrough
hardware specified for the domain.

If the value of the passthrough configuration option is 'disabled' then
the XEN_DOMCTL_CDF_iommu flag will be clear in the xen_domctl_createdomain
flags, thus allowing the toolstack to control whether the domain gets
IOMMU mappings or not (where previously they were globally set).

If the value of the passthrough configuration option is 'sync_pt' then
a new 'iommu_opts' field in xen_domctl_createdomain will be set with the
value XEN_DOMCTL_IOMMU_no_sharept. This will override the global default
set in iommu_hap_pt_share, thus allowing the toolstack to control whether
EPT sharing is used for the domain.

Signed-off-by: Paul Durrant 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Anthony PERARD 
Cc: Volodymyr Babchuk 
Cc: "Roger Pau Monné" 

Previously part of series 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg02267.html

v6:
 - Remove the libxl_physinfo() call since it's usefulness is limited to x86

v5:
 - Expand xen_domctl_createdomain flags field and hence bump interface
   version
 - Fix spelling mistakes in context line
---
 docs/man/xl.cfg.5.pod.in| 52 +
 tools/libxl/libxl.h |  5 
 tools/libxl/libxl_create.c  |  9 ++
 tools/libxl/libxl_types.idl |  7 +
 tools/xl/xl_parse.c | 38 
 xen/arch/arm/domain.c   | 10 ++-
 xen/arch/x86/domain.c   |  2 +-
 xen/common/domain.c |  7 +
 xen/drivers/passthrough/iommu.c | 13 -
 xen/include/public/domctl.h |  6 +++-
 xen/include/xen/iommu.h | 19 
 11 files changed, 158 insertions(+), 10 deletions(-)

diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index c99d40307e..fd35685e9e 100644
--- a/docs/man/xl.cfg.5.pod.in
+++ b/docs/man/xl.cfg.5.pod.in
@@ -605,6 +605,58 @@ option should only be used with a trusted device tree.
 Note that the partial device tree should avoid using the phandle 65000
 which is reserved by the toolstack.
 
+=item B
+
+Specify whether IOMMU mappings are enabled for the domain and hence whether
+it will be enabled for passthrough hardware. Valid values for this option
+are:
+
+=over 4
+
+=item B
+
+IOMMU mappings are disabled for the domain and so hardware may not be
+passed through.
+
+This option is the default if no passthrough hardware is specified
+in the domain's configuration.
+
+=item B
+
+This option means that IOMMU mappings will be synchronized with the
+domain's P2M table as follows:
+
+For a PV domain, all writable pages assigned to the domain are identity
+mapped by MFN in the IOMMU page table. Thus a device driver running in the
+domain may program passthrough hardware for DMA using MFN values
+(i.e. host/machine frame numbers) looked up in its P2M.
+
+For an HVM domain, all non-foreign RAM pages present in its P2M will be
+mapped by GFN in the IOMMU page table. Thus a device driver running in the
+domain may program passthrough hardware using GFN values (i.e. guest
+physical frame numbers) without any further translation.
+
+This option is the default if the domain is PV and passthrough hardware
+is specified in the configuration.
+
+This option is not available on Arm.
+
+=item B
+
+This option is unavailable for a PV domain. For an HVM domain, this option
+means that the IOMMU will be programmed to directly reference the domain's
+P2M table as its page table. From the point of view of a device driver
+running in the domain this is functionally equivalent to B but
+places less load on the hypervisor and so should generally be selected in
+preference. However, the availability of this option is hardware specific
+and thus, if it is specified for a domain running on hardware that does
+not allow it (e.g. AMD), B will be used instead.
+
+This option is the default if the domain is HVM and passthrough hardware
+is specified in the configuration.
+
+=back
+
 =back
 
 =head2 Devices
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 9bacfb97f0..5de7c07a41 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -394,6 +394,11 @@
  */
 #define LIBXL_HAVE_EXTENDED_VKB 1
 
+/*
+ * libxl_domain_create_info has libxl_passthrough enumeration.
+ */
+#define LIBXL_HAVE_CREATEINFO_PASSTHROUGH 1
+
 /*
  * libxl ABI compatibility
  *
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 03ce166f4f..f288e13dc1 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -564,6 +564,15 @@ int libxl__domain_make(libxl__gc *gc, 

[Xen-devel] More questions about Xen memory layout/usage, access to guest memory

[Johnson, Ethan]

Hi all,

I have some follow-up questions about Xen's usage and layout of memory, 
building on the ones I asked here a few weeks ago (which were quite 
helpfully answered: see 
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg01513.html 
for reference). For context on why I'm asking these questions, I'm using 
Xen as a research platform for enforcing novel memory protection schemes 
on hypervisors and guests.

1. Xen itself lives in the memory region from (on x86-64) 0x 8000 
  - 0x 8777  , regardless of whether it's in PV mode 
or HVM/PVH. Clearly, in PV mode a separate set of page tables (i.e. CR3 
root pointer) must be used for each guest. Is that also true of the host 
(non-extended, i.e. CR3 in VMX root mode) page tables when an HVM/PVH 
guest is running? Or is the dom0 page table left in place, assuming the 
dom0 is PV, when an HVM/PVH guest is running, since extended paging is 
now being used to provide the guest's view of memory? Does this change 
if the dom0 is PVH?

Or, to ask this from another angle: is there ever anything *but* Xen 
living in the host-virtual address space when an HVM/PVH guest is 
active? And is the answer to this different depending on whether the 
HVM/PVH guest is a domU vs. a PVH dom0?

2. Do the mappings in Xen's slice of the host-virtual address space 
differ at all between the host page tables corresponding to different 
guests? If the mappings are in fact the same, does Xen therefore share 
lower-level page table pages between the page tables corresponding to 
different guests? Is any of this different for PV vs. HVM/PVH?

3. Under what circumstances, and for what purposes, does Xen use its 
ability to access guest memory through its direct map of host-physical 
memory? Similarly, to what extent does the dom0 (or other such 
privileged domain) utilize "foreign memory maps" to reach into another 
guest's memory? I understand that this is necessary when creating a 
guest, for live migration, and for QEMU to emulate stuff for HVM guests; 
but for PVH, is it ever necessary for Xen or the dom0 to "forcibly" 
access a guest's memory?

(I ask because the research project I'm working on is seeking to protect 
guests from a compromised hypervisor and dom0, so I need to limit 
outside access to a guest's memory to explicitly shared pages that the 
guest will treat as untrusted - not storing any secrets there, vetting 
input as necessary, etc.)

4. What facilities/processes does Xen provide for PV(H) guests to 
explicitly/voluntarily share memory pages with Xen and other domains 
(dom0, etc.)? From what I can gather from the documentation, it sounds 
like "grant tables" are involved in this - is that how a PV-aware guest 
is expected to set up shared memory regions for communication with other 
domains (ring buffers, etc.)? Does a PV(H) guest need to voluntarily 
establish all external access to its pages, or is there ever a situation 
where it's the other way around - where Xen itself establishes/defines a 
region as shared and the guest is responsible for treating it accordingly?

Again, this mostly boils down to: under what circumstances, if ever, 
does Xen ever "force" access to any part of a guest's memory? 
(Particularly for PV(H). Clearly that must happen for HVM since, by 
definition, the guest is unaware there's a hypervisor controlling its 
world and emulating hardware behavior, and thus is in no position to 
cooperatively/voluntarily give the hypervisor and dom0 access to its 
memory.)

Thanks again in advance for any help anyone can offer!

Sincerely,
Ethan Johnson

-- 
Ethan J. Johnson
Computer Science PhD student, Systems group, University of Rochester
ejohn...@cs.rochester.edu
ethanjohn...@acm.org
PGP public key available from public directory or on request

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

Re: [Xen-devel] [RFC] Code of Conduct

[Rich Persaud]

On Aug 16, 2019, at 07:19, George Dunlap  wrote:
> 
> On 8/15/19 6:23 PM, Rich Persaud wrote:
>>> On Aug 9, 2019, at 13:48, Lars Kurth  wrote:
>>> 
>>> Hi all,
>> 
>> Hi Lars,
>> 
>>> 
>>> Following the discussion we had at the Developer Summit (see 
>>> https://wiki.xenproject.org/wiki/Design_Sessions_2019#Community_Issues_.2F_Improvements_-_Communication.2C_Code_of_Conduct.2C_etc.
>>>  for notes) I put together a draft for the Code of Conduct which can be 
>>> found here as well as inlined below
>>> https://docs.google.com/document/d/1NnWdU_VnC1N_ZzxQG6jU9fnY2GPVCcfPJT5KY61WXJM/edit?usp=sharing
>>>  
>>> 
>>> It is based on the LF Events CoC as we agreed on (the diff is attached). I 
>>> took the scope and enforcement sections from 
>>> https://www.contributor-covenant.org/version/1/4/code-of-conduct.html and 
>>> simplified it rather than inventing something new.
>> 
>> Is there precedent for applying a legal contract (Code of Conduct) that was 
>> designed for physical space (conference event) to an online context?   Is 
>> there an existing Code of Conduct that was legally designed for a similar, 
>> online open-source community context, e.g. operating system or hypervisor or 
>> other systems-level software dev?
> 
> This is sort of a strange question.
> 
> Generally speaking, there was a link Lars pointed to in an earlier
> thread in preparation for this, making two suggestions about adopting a CoC:
> 
> 1. Don't create your own CoC from scratch.  Learn from other people's
> experiences, mistakes, and so on, rather than re-inventing the wheel.
> This will hopefully reduce the chance of re-hashing mistakes other
> communities have made.
> 
> 2. Don't copy-and-paste a CoC unmodified from another project.  Consider
> it, adapt it to your own community culture and situation.  This makes
> sure that the CoC is not a tick-box exercise, but that people in your
> community have thoughfully considered various issues and genuinely
> decided to commit to them.
> 
> I think both of those bits of advice are good; and it appears to me that
> this is exactly what Lars (with input from a number of others) has done.
> 
> There are two things that we want, in general:
> 
> 1. To cast a vision for what ideal contributor behavior should be
> 
> 2. To set a bar for minimum acceptable behavior, and a way for excluding
> people whose behavior consistently falls below that bar.
> 
> One area in particular where Lars thought other CoCs were weak was in
> trying to combine #1 and #2.  They need different responses.  #1 needs
> encouragement and vision.  #2 needs teeth: We need to be able to apply
> penalties and exclude people.
> 
> As a result, Lars has suggested (and many people have agreed), that we
> separate the two functions.  This document is about #2, not #1.  We plan
> to do #1 after #2 is completed.
> 
>>> # Expected Behavior
>>> All Xen Project community members are expected to behave in accordance with 
>>> professional standards, with both the Xen Project Code of Conduct as well 
>>> as their 
>>> respective employer’s policies governing appropriate workplace behavior, 
>>> and 
>>> applicable laws.
>> 
>> In the x86 community call where this was first discussed, I suggested that 
>> we try to define desirable behavior, which we would like to incentivize and 
>> promote.   In this current draft, we have a single sentence on positive 
>> behavior, with inclusion-by-reference to:
> 
> We plan on doing this, but in another document.
> 
>> If incorporation-by-reference is not sufficient, e.g. if we will maintain a 
>> blacklist of unacceptable behavior for collaborative, online open-source 
>> development, do we also need a whitelist of acceptable behavior?  Within Xen 
>> source code, we have been moving away from blacklists towards whitelists.
> 
> Unlike hypercalls, all human behavior cannot be enumerated; and if it
> could, 100% certainty cannot be obtained about what a certain behavior
> is, or even exactly what did or did not happen.  No matter what we write
> down, at some point, you're just going to have to either trust the
> people making the decisions.
> 
>>> # Unacceptable Behavior
>>> Harassment will not be tolerated in the Xen Project Community in any form, 
>>> including but not limited to harassment based on gender, gender identity 
>>> and 
>>> expression, sexual orientation, disability, physical appearance, body size, 
>>> race, 
>>> age, religion, ethnicity, nationality, level of experience, education, or 
>>> socio-economic status or any other status protected by laws in 
>>> jurisdictions in 
>>> which community members are based. Harassment includes the use of abusive, 
>>> offensive or degrading language, intimidation, stalking, harassing 
>>> photography 
>>> or recording, inappropriate physical contact, sexual imagery and unwelcome 
>>> sexual advances, requests for sexual favors, publishing others' private 
>>> information such as a physical or electronic address without explicit 
>>> 

Re: [Xen-devel] [PATCH v6 7/8] xen/arm: don't iomem_permit_access for reserved-memory regions

[Stefano Stabellini]

On Fri, 16 Aug 2019, Julien Grall wrote:
> On 16/08/2019 00:36, Stefano Stabellini wrote:
> > Don't allow reserved-memory regions to be remapped into any unprivileged
> > guests, until reserved-memory regions are properly supported in Xen. For
> > now, do not call iomem_permit_access on them, because giving
> > iomem_permit_access to dom0 means that the toolstack will be able to
> > assign the region to a domU.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > 
> > Changes in v6:
> > - compare against "/reserved-memory/"
> > 
> > Changes in v5:
> > - fix check condition
> > - use strnicmp
> > - return error
> > - improve commit message
> > 
> > Changes in v4:
> > - compare the parent name with reserved-memory
> > - use dt_node_cmp
> > 
> > Changes in v3:
> > - new patch
> > ---
> >   xen/arch/arm/domain_build.c | 24 
> >   1 file changed, 16 insertions(+), 8 deletions(-)
> > 
> > diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> > index 4c8404155a..673ffa453f 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1155,15 +1155,23 @@ static int __init map_range_to_domain(const struct
> > dt_device_node *dev,
> >   bool need_mapping = !dt_device_for_passthrough(dev);
> >   int res;
> >   -res = iomem_permit_access(d, paddr_to_pfn(addr),
> > -  paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
> > -if ( res )
> > +/*
> > + * Don't give iomem permissions for reserved-memory ranges to domUs
> 
> In upstream Xen, this is only called for Dom0. So what are you referring to?
> 
> > + * until reserved-memory support is complete.
> 
> But as I pointed out before reserved-memory support is not going to happen via
> iomem. This is an abuse of the interface.
> 
> > + */
> 
> A better comment would be:
> 
> "reserved-memory regions are RAM carved out for special purpose. They are not
> MMIO and therefore a domain should not be able to manage them via the IOMEM
> interface".

Thank you for providing the comment. I'll use your version.


> > +if ( strnicmp(dt_node_full_name(dev), "/reserved-memory/",
> > + strlen("/reserved-memory/")) != 0 )
> >   {
> > -printk(XENLOG_ERR "Unable to permit to dom%d access to"
> > -   " 0x%"PRIx64" - 0x%"PRIx64"\n",
> > -   d->domain_id,
> > -   addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
> > -return res;
> > +res = iomem_permit_access(d, paddr_to_pfn(addr),
> > +paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
> > +if ( res )
> > +{
> > +printk(XENLOG_ERR "Unable to permit to dom%d access to"
> > +" 0x%"PRIx64" - 0x%"PRIx64"\n",
> > +d->domain_id,
> > +addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
> > +return res;
> > +}
> >   }
> > if ( need_mapping )
> > 
> 
> Cheers,
> 
> -- 
> Julien Grall
> 

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

[Xen-devel] [freebsd-master test] 140195: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 freebsd  f39a1bd1426e0e5a462522b7a1de56e8233591e7
baseline version:
 freebsd  4bc76934c5c155105ae508148fec86f5b3513f2a

Last test of basis   140108  2019-08-14 09:19:54 Z2 days
Testing same since   140195  2019-08-16 09:21:38 Z0 days1 attempts


People who touched revisions under test:
  0mp <0...@freebsd.org>
  ae 
  andrew 
  asomers 
  avg 
  cem 
  dougm 
  emaste 
  hselasky 
  imp 
  jeff 
  jhb 
  jhibbits 
  jkim 
  jmg 
  kevans 
  manu 
  mav 
  mckusick 
  mmacy 
  rmacklem 
  sjg 

jobs:
 build-amd64-freebsd-againpass
 build-amd64-freebsd  pass
 build-amd64-xen-freebsd  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/freebsd.git
   4bc76934c5c..f39a1bd1426  f39a1bd1426e0e5a462522b7a1de56e8233591e7 -> 
tested/master

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

Re: [Xen-devel] [PATCH v2 0/4] xen/console: Bug fixes and doc improvement

[Julien Grall]

Hi,

On 8/5/19 2:29 PM, Julien Grall wrote:

Hi all,

This series contains a bunch of bug fixes for the hypercall CONSOLEIO_write
and some documentation.

Cheers,

Julien Grall (4):
   xen/console: Don't treat NUL character as the end of the buffer
   xen/console: Rework HYPERCALL_console_io interface
   xen/public: Document HYPERCALL_console_io()
   xen/console: Simplify domU console handling in guest_console_write


I have merged the series. Thank you all for the review!

Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim  20 guest-start/debian.repeat fail REGR. vs. 139876

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139876
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 139876
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 139876
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139876
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  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-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-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-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-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
 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:
 xen  854a49a7486a02edae5b3e53617bace526e9c1b1
baseline version:
 xen  6c9639a72f0ca3a9430ef75f375877182281fdef

Last test of basis   139876  2019-08-09 18:46:56 Z7 days

[Xen-devel] [Qemu-devel] [PATCH v7 08/42] hw/vfio: Access MemoryRegion with MemOp

[tony.nguyen]

The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".

Convert interfaces by using no-op size_memop.

After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".

As size_memop is a no-op, this patch does not change any behaviour.

Signed-off-by: Tony Nguyen 
Reviewed-by: Richard Henderson 
Reviewed-by: Cornelia Huck 
---
 hw/vfio/pci-quirks.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index b35a640..fb3cc33 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -11,6 +11,7 @@
  */

 #include "qemu/osdep.h"
+#include "exec/memop.h"
 #include "qemu/units.h"
 #include "qemu/error-report.h"
 #include "qemu/main-loop.h"
@@ -1071,7 +1072,7 @@ static void vfio_rtl8168_quirk_address_write(void 
*opaque, hwaddr addr,

 /* Write to the proper guest MSI-X table instead */
 memory_region_dispatch_write(>pdev.msix_table_mmio,
- offset, val, size,
+ offset, val, size_memop(size),
  MEMTXATTRS_UNSPECIFIED);
 }
 return; /* Do not write guest MSI-X data to hardware */
@@ -1102,7 +1103,8 @@ static uint64_t vfio_rtl8168_quirk_data_read(void *opaque,
 if (rtl->enabled && (vdev->pdev.cap_present & QEMU_PCI_CAP_MSIX)) {
 hwaddr offset = rtl->addr & 0xfff;
 memory_region_dispatch_read(>pdev.msix_table_mmio, offset,
-, size, MEMTXATTRS_UNSPECIFIED);
+, size_memop(size),
+MEMTXATTRS_UNSPECIFIED);
 trace_vfio_quirk_rtl8168_msix_read(vdev->vbasedev.name, offset, data);
 }

--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 10/42] cputlb: Access MemoryRegion with MemOp

[tony.nguyen]

The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".

Convert interfaces by using no-op size_memop.

After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".

As size_memop is a no-op, this patch does not change any behaviour.

Signed-off-by: Tony Nguyen 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 accel/tcg/cputlb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 523be4c..6c83878 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -906,8 +906,8 @@ static uint64_t io_readx(CPUArchState *env, CPUIOTLBEntry 
*iotlbentry,
 qemu_mutex_lock_iothread();
 locked = true;
 }
-r = memory_region_dispatch_read(mr, mr_offset,
-, size, iotlbentry->attrs);
+r = memory_region_dispatch_read(mr, mr_offset, , size_memop(size),
+iotlbentry->attrs);
 if (r != MEMTX_OK) {
 hwaddr physaddr = mr_offset +
 section->offset_within_address_space -
@@ -947,8 +947,8 @@ static void io_writex(CPUArchState *env, CPUIOTLBEntry 
*iotlbentry,
 qemu_mutex_lock_iothread();
 locked = true;
 }
-r = memory_region_dispatch_write(mr, mr_offset,
- val, size, iotlbentry->attrs);
+r = memory_region_dispatch_write(mr, mr_offset, val, size_memop(size),
+ iotlbentry->attrs);
 if (r != MEMTX_OK) {
 hwaddr physaddr = mr_offset +
 section->offset_within_address_space -
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 09/42] exec: Access MemoryRegion with MemOp

[tony.nguyen]

The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".

Convert interfaces by using no-op size_memop.

After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".

As size_memop is a no-op, this patch does not change any behaviour.

Signed-off-by: Tony Nguyen 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
---
 exec.c|  6 --
 memory_ldst.inc.c | 18 +-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/exec.c b/exec.c
index 3e78de3..9f69197 100644
--- a/exec.c
+++ b/exec.c
@@ -3334,7 +3334,8 @@ static MemTxResult flatview_write_continue(FlatView *fv, 
hwaddr addr,
 /* XXX: could force current_cpu to NULL to avoid
potential bugs */
 val = ldn_p(buf, l);
-result |= memory_region_dispatch_write(mr, addr1, val, l, attrs);
+result |= memory_region_dispatch_write(mr, addr1, val,
+   size_memop(l), attrs);
 } else {
 /* RAM case */
 ptr = qemu_ram_ptr_length(mr->ram_block, addr1, , false);
@@ -3395,7 +3396,8 @@ MemTxResult flatview_read_continue(FlatView *fv, hwaddr 
addr,
 /* I/O case */
 release_lock |= prepare_mmio_access(mr);
 l = memory_access_size(mr, l, addr1);
-result |= memory_region_dispatch_read(mr, addr1, , l, attrs);
+result |= memory_region_dispatch_read(mr, addr1, ,
+  size_memop(l), attrs);
 stn_p(buf, l, val);
 } else {
 /* RAM case */
diff --git a/memory_ldst.inc.c b/memory_ldst.inc.c
index acf865b..1e8a2fc 100644
--- a/memory_ldst.inc.c
+++ b/memory_ldst.inc.c
@@ -38,7 +38,7 @@ static inline uint32_t glue(address_space_ldl_internal, 
SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , 4, attrs);
+r = memory_region_dispatch_read(mr, addr1, , size_memop(4), attrs);
 #if defined(TARGET_WORDS_BIGENDIAN)
 if (endian == DEVICE_LITTLE_ENDIAN) {
 val = bswap32(val);
@@ -114,7 +114,7 @@ static inline uint64_t glue(address_space_ldq_internal, 
SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , 8, attrs);
+r = memory_region_dispatch_read(mr, addr1, , size_memop(8), attrs);
 #if defined(TARGET_WORDS_BIGENDIAN)
 if (endian == DEVICE_LITTLE_ENDIAN) {
 val = bswap64(val);
@@ -188,7 +188,7 @@ uint32_t glue(address_space_ldub, SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , 1, attrs);
+r = memory_region_dispatch_read(mr, addr1, , size_memop(1), attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -224,7 +224,7 @@ static inline uint32_t glue(address_space_lduw_internal, 
SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , 2, attrs);
+r = memory_region_dispatch_read(mr, addr1, , size_memop(2), attrs);
 #if defined(TARGET_WORDS_BIGENDIAN)
 if (endian == DEVICE_LITTLE_ENDIAN) {
 val = bswap16(val);
@@ -300,7 +300,7 @@ void glue(address_space_stl_notdirty, SUFFIX)(ARG1_DECL,
 if (l < 4 || !memory_access_is_direct(mr, true)) {
 release_lock |= prepare_mmio_access(mr);

-r = memory_region_dispatch_write(mr, addr1, val, 4, attrs);
+r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
 } else {
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
 stl_p(ptr, val);
@@ -346,7 +346,7 @@ static inline void glue(address_space_stl_internal, 
SUFFIX)(ARG1_DECL,
 val = bswap32(val);
 }
 #endif
-r = memory_region_dispatch_write(mr, addr1, val, 4, attrs);
+r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -408,7 +408,7 @@ void glue(address_space_stb, SUFFIX)(ARG1_DECL,
 mr = TRANSLATE(addr, , , true, attrs);
 if (!memory_access_is_direct(mr, true)) {
 release_lock |= prepare_mmio_access(mr);
-r = memory_region_dispatch_write(mr, addr1, val, 1, attrs);
+r = memory_region_dispatch_write(mr, addr1, val, size_memop(1), attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -451,7 +451,7 @@ static inline void glue(address_space_stw_internal, 
SUFFIX)(ARG1_DECL,
 val = bswap16(val);
 }
 #endif
-

[Xen-devel] [Qemu-devel] [PATCH v7 07/42] hw/virtio: Access MemoryRegion with MemOp

[tony.nguyen]

The memory_region_dispatch_{read|write} operand "unsigned size" is
being converted into a "MemOp op".

Convert interfaces by using no-op size_memop.

After all interfaces are converted, size_memop will be implemented
and the memory_region_dispatch_{read|write} operand "unsigned size"
will be converted into a "MemOp op".

As size_memop is a no-op, this patch does not change any behaviour.

Signed-off-by: Tony Nguyen 
Reviewed-by: Richard Henderson 
Reviewed-by: Cornelia Huck 
---
 hw/virtio/virtio-pci.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index f6d2223..25875c8 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -17,6 +17,7 @@

 #include "qemu/osdep.h"

+#include "exec/memop.h"
 #include "standard-headers/linux/virtio_pci.h"
 #include "hw/virtio/virtio.h"
 #include "hw/pci/pci.h"
@@ -550,7 +551,8 @@ void virtio_address_space_write(VirtIOPCIProxy *proxy, 
hwaddr addr,
 /* As length is under guest control, handle illegal values. */
 return;
 }
-memory_region_dispatch_write(mr, addr, val, len, MEMTXATTRS_UNSPECIFIED);
+memory_region_dispatch_write(mr, addr, val, size_memop(len),
+ MEMTXATTRS_UNSPECIFIED);
 }

 static void
@@ -573,7 +575,8 @@ virtio_address_space_read(VirtIOPCIProxy *proxy, hwaddr 
addr,
 /* Make sure caller aligned buf properly */
 assert(!(((uintptr_t)buf) & (len - 1)));

-memory_region_dispatch_read(mr, addr, , len, MEMTXATTRS_UNSPECIFIED);
+memory_region_dispatch_read(mr, addr, , size_memop(len),
+MEMTXATTRS_UNSPECIFIED);
 switch (len) {
 case 1:
 pci_set_byte(buf, val);
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 24/42] hw/isa: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/isa/vt82c686.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 12c460590..adf65d3 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -108,7 +108,7 @@ static uint64_t superio_ioport_readb(void *opaque, hwaddr 
addr, unsigned size)
 static const MemoryRegionOps superio_ops = {
 .read = superio_ioport_readb,
 .write = superio_ioport_writeb,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 1,
 .max_access_size = 1,
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 26/42] hw/net: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/net/allwinner_emac.c | 2 +-
 hw/net/imx_fec.c| 2 +-
 hw/net/lan9118.c| 4 ++--
 hw/net/lance.c  | 2 +-
 hw/net/smc91c111.c  | 2 +-
 hw/net/stellaris_enet.c | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/net/allwinner_emac.c b/hw/net/allwinner_emac.c
index eecda52..97e22e7 100644
--- a/hw/net/allwinner_emac.c
+++ b/hw/net/allwinner_emac.c
@@ -418,7 +418,7 @@ static void aw_emac_set_link(NetClientState *nc)
 static const MemoryRegionOps aw_emac_mem_ops = {
 .read = aw_emac_read,
 .write = aw_emac_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
 .min_access_size = 4,
 .max_access_size = 4,
diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index 404154e..76d42c8 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -1278,7 +1278,7 @@ static const MemoryRegionOps imx_eth_ops = {
 .write = imx_eth_write,
 .valid.min_access_size = 4,
 .valid.max_access_size = 4,
-.endianness= DEVICE_NATIVE_ENDIAN,
+.endianness= DEVICE_LITTLE_ENDIAN,
 };

 static void imx_eth_cleanup(NetClientState *nc)
diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
index f6120be..bb1bbb3 100644
--- a/hw/net/lan9118.c
+++ b/hw/net/lan9118.c
@@ -1304,13 +1304,13 @@ static uint64_t lan9118_16bit_mode_read(void *opaque, 
hwaddr offset,
 static const MemoryRegionOps lan9118_mem_ops = {
 .read = lan9118_readl,
 .write = lan9118_writel,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const MemoryRegionOps lan9118_16bit_mem_ops = {
 .read = lan9118_16bit_mode_read,
 .write = lan9118_16bit_mode_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static NetClientInfo net_lan9118_info = {
diff --git a/hw/net/lance.c b/hw/net/lance.c
index 2978c01..d95f170 100644
--- a/hw/net/lance.c
+++ b/hw/net/lance.c
@@ -74,7 +74,7 @@ static uint64_t lance_mem_read(void *opaque, hwaddr addr,
 static const MemoryRegionOps lance_mem_ops = {
 .read = lance_mem_read,
 .write = lance_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 .valid = {
 .min_access_size = 2,
 .max_access_size = 2,
diff --git a/hw/net/smc91c111.c b/hw/net/smc91c111.c
index 4a612ee..49e4bf5 100644
--- a/hw/net/smc91c111.c
+++ b/hw/net/smc91c111.c
@@ -757,7 +757,7 @@ static const MemoryRegionOps smc91c111_mem_ops = {
 .write = smc91c111_writefn,
 .valid.min_access_size = 1,
 .valid.max_access_size = 4,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static NetClientInfo net_smc91c111_info = {
diff --git a/hw/net/stellaris_enet.c b/hw/net/stellaris_enet.c
index 2f645bf..15ec227 100644
--- a/hw/net/stellaris_enet.c
+++ b/hw/net/stellaris_enet.c
@@ -456,7 +456,7 @@ static void stellaris_enet_write(void *opaque, hwaddr 
offset,
 static const MemoryRegionOps stellaris_enet_ops = {
 .read = stellaris_enet_read,
 .write = stellaris_enet_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void stellaris_enet_reset(DeviceState *dev)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 27/42] hw/pci-host: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/pci-host/q35.c   | 2 +-
 hw/pci-host/versatile.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 0a010be..fd20f72 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -288,7 +288,7 @@ static void tseg_blackhole_write(void *opaque, hwaddr addr, 
uint64_t val,
 static const MemoryRegionOps tseg_blackhole_ops = {
 .read = tseg_blackhole_read,
 .write = tseg_blackhole_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid.min_access_size = 1,
 .valid.max_access_size = 4,
 .impl.min_access_size = 4,
diff --git a/hw/pci-host/versatile.c b/hw/pci-host/versatile.c
index 791b321..e7017f3 100644
--- a/hw/pci-host/versatile.c
+++ b/hw/pci-host/versatile.c
@@ -240,7 +240,7 @@ static uint64_t pci_vpb_reg_read(void *opaque, hwaddr addr,
 static const MemoryRegionOps pci_vpb_reg_ops = {
 .read = pci_vpb_reg_read,
 .write = pci_vpb_reg_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
 .min_access_size = 4,
 .max_access_size = 4,
@@ -306,7 +306,7 @@ static uint64_t pci_vpb_config_read(void *opaque, hwaddr 
addr,
 static const MemoryRegionOps pci_vpb_config_ops = {
 .read = pci_vpb_config_read,
 .write = pci_vpb_config_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static int pci_vpb_map_irq(PCIDevice *d, int irq_num)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 25/42] hw/misc: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/misc/a9scu.c| 2 +-
 hw/misc/applesmc.c | 6 +++---
 hw/misc/arm11scu.c | 2 +-
 hw/misc/arm_l2x0.c | 2 +-
 hw/misc/puv3_pm.c  | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/misc/a9scu.c b/hw/misc/a9scu.c
index 4307f00..3de8cd3 100644
--- a/hw/misc/a9scu.c
+++ b/hw/misc/a9scu.c
@@ -94,7 +94,7 @@ static void a9_scu_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps a9_scu_ops = {
 .read = a9_scu_read,
 .write = a9_scu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void a9_scu_reset(DeviceState *dev)
diff --git a/hw/misc/applesmc.c b/hw/misc/applesmc.c
index 2d7eb3c..6c91f29 100644
--- a/hw/misc/applesmc.c
+++ b/hw/misc/applesmc.c
@@ -285,7 +285,7 @@ static void qdev_applesmc_isa_reset(DeviceState *dev)
 static const MemoryRegionOps applesmc_data_io_ops = {
 .write = applesmc_io_data_write,
 .read = applesmc_io_data_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 1,
 .max_access_size = 1,
@@ -295,7 +295,7 @@ static const MemoryRegionOps applesmc_data_io_ops = {
 static const MemoryRegionOps applesmc_cmd_io_ops = {
 .write = applesmc_io_cmd_write,
 .read = applesmc_io_cmd_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 1,
 .max_access_size = 1,
@@ -305,7 +305,7 @@ static const MemoryRegionOps applesmc_cmd_io_ops = {
 static const MemoryRegionOps applesmc_err_io_ops = {
 .write = applesmc_io_err_write,
 .read = applesmc_io_err_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 1,
 .max_access_size = 1,
diff --git a/hw/misc/arm11scu.c b/hw/misc/arm11scu.c
index 84275df..59fd7c0 100644
--- a/hw/misc/arm11scu.c
+++ b/hw/misc/arm11scu.c
@@ -57,7 +57,7 @@ static void mpcore_scu_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps mpcore_scu_ops = {
 .read = mpcore_scu_read,
 .write = mpcore_scu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void arm11_scu_realize(DeviceState *dev, Error **errp)
diff --git a/hw/misc/arm_l2x0.c b/hw/misc/arm_l2x0.c
index b88f40a..72ecf46 100644
--- a/hw/misc/arm_l2x0.c
+++ b/hw/misc/arm_l2x0.c
@@ -157,7 +157,7 @@ static void l2x0_priv_reset(DeviceState *dev)
 static const MemoryRegionOps l2x0_mem_ops = {
 .read = l2x0_priv_read,
 .write = l2x0_priv_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
  };

 static void l2x0_priv_init(Object *obj)
diff --git a/hw/misc/puv3_pm.c b/hw/misc/puv3_pm.c
index b538b4a..cd82b69 100644
--- a/hw/misc/puv3_pm.c
+++ b/hw/misc/puv3_pm.c
@@ -118,7 +118,7 @@ static const MemoryRegionOps puv3_pm_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void puv3_pm_realize(DeviceState *dev, Error **errp)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 28/42] hw/sd: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/sd/pl181.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/sd/pl181.c b/hw/sd/pl181.c
index 81b406d..f2027aa 100644
--- a/hw/sd/pl181.c
+++ b/hw/sd/pl181.c
@@ -449,7 +449,7 @@ static void pl181_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps pl181_ops = {
 .read = pl181_read,
 .write = pl181_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl181_reset(DeviceState *d)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 29/42] hw/ssi: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/ssi/mss-spi.c   | 2 +-
 hw/ssi/pl022.c | 2 +-
 hw/ssi/stm32f2xx_spi.c | 2 +-
 hw/ssi/xilinx_spips.c  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/ssi/mss-spi.c b/hw/ssi/mss-spi.c
index 4c9da5d..71fd138 100644
--- a/hw/ssi/mss-spi.c
+++ b/hw/ssi/mss-spi.c
@@ -359,7 +359,7 @@ static void spi_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps spi_ops = {
 .read = spi_read,
 .write = spi_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
 .min_access_size = 1,
 .max_access_size = 4
diff --git a/hw/ssi/pl022.c b/hw/ssi/pl022.c
index fec73ca..10d1995 100644
--- a/hw/ssi/pl022.c
+++ b/hw/ssi/pl022.c
@@ -226,7 +226,7 @@ static void pl022_reset(DeviceState *dev)
 static const MemoryRegionOps pl022_ops = {
 .read = pl022_read,
 .write = pl022_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static int pl022_post_load(void *opaque, int version_id)
diff --git a/hw/ssi/stm32f2xx_spi.c b/hw/ssi/stm32f2xx_spi.c
index 4249101..e1e5ab5 100644
--- a/hw/ssi/stm32f2xx_spi.c
+++ b/hw/ssi/stm32f2xx_spi.c
@@ -166,7 +166,7 @@ static void stm32f2xx_spi_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps stm32f2xx_spi_ops = {
 .read = stm32f2xx_spi_read,
 .write = stm32f2xx_spi_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const VMStateDescription vmstate_stm32f2xx_spi = {
diff --git a/hw/ssi/xilinx_spips.c b/hw/ssi/xilinx_spips.c
index b29e0a4..8cadc4e 100644
--- a/hw/ssi/xilinx_spips.c
+++ b/hw/ssi/xilinx_spips.c
@@ -1238,7 +1238,7 @@ static MemTxResult lqspi_write(void *opaque, hwaddr 
offset, uint64_t value,
 static const MemoryRegionOps lqspi_ops = {
 .read_with_attrs = lqspi_read,
 .write_with_attrs = lqspi_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 4,
 .max_access_size = 4,
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 30/42] hw/timer: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/timer/a9gtimer.c | 4 ++--
 hw/timer/arm_mptimer.c  | 4 ++--
 hw/timer/arm_timer.c| 4 ++--
 hw/timer/armv7m_systick.c   | 2 +-
 hw/timer/aspeed_rtc.c   | 2 +-
 hw/timer/cadence_ttc.c  | 2 +-
 hw/timer/grlib_gptimer.c| 2 +-
 hw/timer/hpet.c | 2 +-
 hw/timer/imx_epit.c | 2 +-
 hw/timer/imx_gpt.c  | 2 +-
 hw/timer/lm32_timer.c   | 2 +-
 hw/timer/milkymist-sysctl.c | 2 +-
 hw/timer/mss-timer.c| 2 +-
 hw/timer/pl031.c| 2 +-
 hw/timer/stm32f2xx_timer.c  | 2 +-
 hw/timer/sun4v-rtc.c| 2 +-
 16 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/hw/timer/a9gtimer.c b/hw/timer/a9gtimer.c
index 09e2a7b..8bb5f6e 100644
--- a/hw/timer/a9gtimer.c
+++ b/hw/timer/a9gtimer.c
@@ -254,7 +254,7 @@ static const MemoryRegionOps a9_gtimer_this_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const MemoryRegionOps a9_gtimer_ops = {
@@ -264,7 +264,7 @@ static const MemoryRegionOps a9_gtimer_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void a9_gtimer_reset(DeviceState *dev)
diff --git a/hw/timer/arm_mptimer.c b/hw/timer/arm_mptimer.c
index 93044aa..9397218 100644
--- a/hw/timer/arm_mptimer.c
+++ b/hw/timer/arm_mptimer.c
@@ -190,7 +190,7 @@ static const MemoryRegionOps arm_thistimer_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const MemoryRegionOps timerblock_ops = {
@@ -200,7 +200,7 @@ static const MemoryRegionOps timerblock_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void timerblock_reset(TimerBlock *tb)
diff --git a/hw/timer/arm_timer.c b/hw/timer/arm_timer.c
index f0a7534..22ce3ff 100644
--- a/hw/timer/arm_timer.c
+++ b/hw/timer/arm_timer.c
@@ -265,7 +265,7 @@ static void sp804_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps sp804_ops = {
 .read = sp804_read,
 .write = sp804_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const VMStateDescription vmstate_sp804 = {
@@ -346,7 +346,7 @@ static void icp_pit_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps icp_pit_ops = {
 .read = icp_pit_read,
 .write = icp_pit_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void icp_pit_init(Object *obj)
diff --git a/hw/timer/armv7m_systick.c b/hw/timer/armv7m_systick.c
index 9464074..3c34fd0 100644
--- a/hw/timer/armv7m_systick.c
+++ b/hw/timer/armv7m_systick.c
@@ -191,7 +191,7 @@ static MemTxResult systick_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps systick_ops = {
 .read_with_attrs = systick_read,
 .write_with_attrs = systick_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid.min_access_size = 4,
 .valid.max_access_size = 4,
 };
diff --git a/hw/timer/aspeed_rtc.c b/hw/timer/aspeed_rtc.c
index 19f061c..c528e47 100644
--- a/hw/timer/aspeed_rtc.c
+++ b/hw/timer/aspeed_rtc.c
@@ -130,7 +130,7 @@ static void aspeed_rtc_reset(DeviceState *d)
 static const MemoryRegionOps aspeed_rtc_ops = {
 .read = aspeed_rtc_read,
 .write = aspeed_rtc_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const VMStateDescription vmstate_aspeed_rtc = {
diff --git a/hw/timer/cadence_ttc.c b/hw/timer/cadence_ttc.c
index 115d935..d422efe 100644
--- a/hw/timer/cadence_ttc.c
+++ b/hw/timer/cadence_ttc.c
@@ -389,7 +389,7 @@ static void cadence_ttc_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps cadence_ttc_ops = {
 .read = cadence_ttc_read,
 .write = cadence_ttc_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void cadence_timer_reset(CadenceTimerState *s)
diff --git a/hw/timer/grlib_gptimer.c b/hw/timer/grlib_gptimer.c
index e45a490..dc3b028 100644
--- a/hw/timer/grlib_gptimer.c
+++ 

[Xen-devel] [Qemu-devel] [PATCH v7 22/42] hw/input: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/input/pl050.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/input/pl050.c b/hw/input/pl050.c
index b79bf16..4c0fe0b 100644
--- a/hw/input/pl050.c
+++ b/hw/input/pl050.c
@@ -137,7 +137,7 @@ static void pl050_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps pl050_ops = {
 .read = pl050_read,
 .write = pl050_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl050_realize(DeviceState *dev, Error **errp)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 00/42] Invert Endian bit in SPARCv9 MMU TTE

[tony.nguyen]

This patchset implements the IE (Invert Endian) bit in SPARCv9 MMU TTE.

It is an attempt of the instructions outlined by Richard Henderson to Mark
Cave-Ayland.

Tested with OpenBSD on sun4u. Solaris 10 is my actual goal, but unfortunately a
separate keyboard issue remains in the way.

On 01/11/17 19:15, Mark Cave-Ayland wrote:

>On 15/08/17 19:10, Richard Henderson wrote:
>
>> [CC Peter re MemTxAttrs below]
>>
>> On 08/15/2017 09:38 AM, Mark Cave-Ayland wrote:
>>> Working through an incorrect endian issue on qemu-system-sparc64, it has
>>> become apparent that at least one OS makes use of the IE (Invert Endian)
>>> bit in the SPARCv9 MMU TTE to map PCI memory space without the
>>> programmer having to manually endian-swap accesses.
>>>
>>> In other words, to quote the UltraSPARC specification: "if this bit is
>>> set, accesses to the associated page are processed with inverse
>>> endianness from what is specified by the instruction (big-for-little and
>>> little-for-big)".

A good explanation by Mark why the IE bit is required.

>>>
>>> Looking through various bits of code, I'm trying to get a feel for the
>>> best way to implement this in an efficient manner. From what I can see
>>> this could be solved using an additional MMU index, however I'm not
>>> overly familiar with the memory and softmmu subsystems.
>>
>> No, it can't be solved with an MMU index.
>>
>>> Can anyone point me in the right direction as to what would be the best
>>> way to implement this feature within QEMU?
>>
>> It's definitely tricky.
>>
>> We definitely need some TLB_FLAGS_MASK bit set so that we're forced through
>> the
>> memory slow path.  There is no other way to bypass the endianness that we've
>> already encoded from the target instruction.
>>
>> Given the tlb_set_page_with_attrs interface, I would think that we need a new
>> bit in MemTxAttrs, so that the target/sparc tlb_fill (and subroutines) can
>> pass
>> along the TTE bit for the given page.
>>
>> We have an existing problem in softmmu_template.h,
>>
>> /* ??? Note that the io helpers always read data in the target
>>byte ordering.  We should push the LE/BE request down into io.  */
>> res = glue(io_read, SUFFIX)(env, mmu_idx, index, addr, retaddr);
>> res = TGT_BE(res);
>>
>> We do not want to add a third(!) byte swap along the i/o path.  We need to
>> collapse the two that we have already before considering this one.
>>
>> This probably takes the form of:
>>
>> (1) Replacing the "int size" argument with "TCGMemOp memop" for
>>   a) io_{read,write}x in accel/tcg/cputlb.c,
>>   b) memory_region_dispatch_{read,write} in memory.c,
>>   c) adjust_endianness in memory.c.
>> This carries size+sign+endianness down to the next level.
>>
>> (2) In memory.c, adjust_endianness,
>>
>>  if (memory_region_wrong_endianness(mr)) {
>> -switch (size) {
>> +memop ^= MO_BSWAP;
>> +}
>> +if (memop & MO_BSWAP) {
>>
>> For extra credit, re-arrange memory_region_wrong_endianness
>> to something more explicit -- "wrong" isn't helpful.
>
>Finally I've had a bit of spare time to experiment with this approach,
>and from what I can see there are currently 2 issues:
>
>
>1) Using TCGMemOp in memory.c means it is no longer accelerator agnostic
>
>For the moment I've defined a separate MemOp in memory.h and provided a
>mapping function in io_{read,write}x to map from TCGMemOp to MemOp and
>then pass that into memory_region_dispatch_{read,write}.
>
>Other than not referencing TCGMemOp in the memory API, another reason
>for doing this was that I wasn't convinced that all the MO_ attributes
>were valid outside of TCG. I do, of course, strongly defer to other
>people's knowledge in this area though.
>
>
>2) The above changes to adjust_endianness() fail when
>memory_region_dispatch_{read,write} are called recursively
>
>Whilst booting qemu-system-sparc64 I see that
>memory_region_dispatch_{read,write} get called recursively - once via
>io_{read,write}x and then again via flatview_read_continue() in exec.c.
>
>The net effect of this is that we perform the bswap correctly at the
>tail of the recursion, but then as we travel back up the stack we hit
>memory_region_dispatch_{read,write} once again causing a second bswap
>which means the value is returned with the incorrect endian again.
>
>
>My understanding from your softmmu_template.h comment above is that the
>memory API should do the endian swapping internally allowing the removal
>of the final TGT_BE/TGT_LE applied to the result, or did I get this wrong?
>
>> (3) In tlb_set_page_with_attrs, notice attrs.byte_swap and set
>> a new TLB_FORCE_SLOW bit within TLB_FLAGS_MASK.
>>
>> (4) In io_{read,write}x, if iotlbentry->attrs.byte_swap is set,
>> then memop ^= MO_BSWAP.

Thanks all for the feedback. Learnt a lot =)

v2:
- Moved size+sign+endianness attributes from TCGMemOp into MemOp.
  In v1 TCGMemOp was re-purposed entirely into MemOp.
- Replaced MemOp MO_{8|16|32|64} with 

[Xen-devel] [Qemu-devel] [PATCH v7 11/42] memory: Access MemoryRegion with MemOp

[tony.nguyen]

Convert memory_region_dispatch_{read|write} operand "unsigned size"
into a "MemOp op".

Signed-off-by: Tony Nguyen 
Reviewed-by: Richard Henderson 
---
 include/exec/memop.h  | 20 ++--
 include/exec/memory.h |  9 +
 memory.c  |  7 +--
 3 files changed, 24 insertions(+), 12 deletions(-)

diff --git a/include/exec/memop.h b/include/exec/memop.h
index dfd76a1..0a610b7 100644
--- a/include/exec/memop.h
+++ b/include/exec/memop.h
@@ -12,6 +12,8 @@
 #ifndef MEMOP_H
 #define MEMOP_H

+#include "qemu/host-utils.h"
+
 typedef enum MemOp {
 MO_8 = 0,
 MO_16= 1,
@@ -107,14 +109,20 @@ typedef enum MemOp {
 MO_SSIZE = MO_SIZE | MO_SIGN,
 } MemOp;

+/* MemOp to size in bytes.  */
+static inline unsigned memop_size(MemOp op)
+{
+return 1 << (op & MO_SIZE);
+}
+
 /* Size in bytes to MemOp.  */
-static inline unsigned size_memop(unsigned size)
+static inline MemOp size_memop(unsigned size)
 {
-/*
- * FIXME: No-op to aid conversion of memory_region_dispatch_{read|write}
- * "unsigned size" operand into a "MemOp op".
- */
-return size;
+#ifdef CONFIG_DEBUG_TCG
+/* Power of 2 up to 8.  */
+assert((size & (size - 1)) == 0 && size >= 1 && size <= 8);
+#endif
+return ctz32(size);
 }

 #endif
diff --git a/include/exec/memory.h b/include/exec/memory.h
index bb0961d..975b86a 100644
--- a/include/exec/memory.h
+++ b/include/exec/memory.h
@@ -19,6 +19,7 @@
 #include "exec/cpu-common.h"
 #include "exec/hwaddr.h"
 #include "exec/memattrs.h"
+#include "exec/memop.h"
 #include "exec/ramlist.h"
 #include "qemu/queue.h"
 #include "qemu/int128.h"
@@ -1731,13 +1732,13 @@ void mtree_info(bool flatview, bool dispatch_tree, bool 
owner);
  * @mr: #MemoryRegion to access
  * @addr: address within that region
  * @pval: pointer to uint64_t which the data is written to
- * @size: size of the access in bytes
+ * @op: size, sign, and endianness of the memory operation
  * @attrs: memory transaction attributes to use for the access
  */
 MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
 hwaddr addr,
 uint64_t *pval,
-unsigned size,
+MemOp op,
 MemTxAttrs attrs);
 /**
  * memory_region_dispatch_write: perform a write directly to the specified
@@ -1746,13 +1747,13 @@ MemTxResult memory_region_dispatch_read(MemoryRegion 
*mr,
  * @mr: #MemoryRegion to access
  * @addr: address within that region
  * @data: data to write
- * @size: size of the access in bytes
+ * @op: size, sign, and endianness of the memory operation
  * @attrs: memory transaction attributes to use for the access
  */
 MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
  hwaddr addr,
  uint64_t data,
- unsigned size,
+ MemOp op,
  MemTxAttrs attrs);

 /**
diff --git a/memory.c b/memory.c
index 5d8c9a9..89ea4fb 100644
--- a/memory.c
+++ b/memory.c
@@ -1439,9 +1439,10 @@ static MemTxResult 
memory_region_dispatch_read1(MemoryRegion *mr,
 MemTxResult memory_region_dispatch_read(MemoryRegion *mr,
 hwaddr addr,
 uint64_t *pval,
-unsigned size,
+MemOp op,
 MemTxAttrs attrs)
 {
+unsigned size = memop_size(op);
 MemTxResult r;

 if (!memory_region_access_valid(mr, addr, size, false, attrs)) {
@@ -1483,9 +1484,11 @@ static bool 
memory_region_dispatch_write_eventfds(MemoryRegion *mr,
 MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
  hwaddr addr,
  uint64_t data,
- unsigned size,
+ MemOp op,
  MemTxAttrs attrs)
 {
+unsigned size = memop_size(op);
+
 if (!memory_region_access_valid(mr, addr, size, true, attrs)) {
 unassigned_mem_write(mr, addr, data, size);
 return MEMTX_DECODE_ERROR;
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 13/42] target/mips: Hard code size with MO_{8|16|32|64}

[tony.nguyen]

Temporarily no-op size_memop was introduced to aid the conversion of
memory_region_dispatch_{read|write} operand "unsigned size" into
"MemOp op".

Now size_memop is implemented, again hard coded size but with
MO_{8|16|32|64}. This is more expressive and avoids size_memop calls.

Signed-off-by: Tony Nguyen 
Reviewed-by: Richard Henderson 
---
 target/mips/op_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/mips/op_helper.c b/target/mips/op_helper.c
index 1c72a00..e79f99d 100644
--- a/target/mips/op_helper.c
+++ b/target/mips/op_helper.c
@@ -4741,11 +4741,11 @@ void helper_cache(CPUMIPSState *env, target_ulong addr, 
uint32_t op)
 if (op == 9) {
 /* Index Store Tag */
 memory_region_dispatch_write(env->itc_tag, index, env->CP0_TagLo,
- size_memop(8), MEMTXATTRS_UNSPECIFIED);
+ MO_64, MEMTXATTRS_UNSPECIFIED);
 } else if (op == 5) {
 /* Index Load Tag */
 memory_region_dispatch_read(env->itc_tag, index, >CP0_TagLo,
-size_memop(8), MEMTXATTRS_UNSPECIFIED);
+MO_64, MEMTXATTRS_UNSPECIFIED);
 }
 #endif
 }
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 12/42] hw/s390x: Hard code size with MO_{8|16|32|64}

[tony.nguyen]

Temporarily no-op size_memop was introduced to aid the conversion of
memory_region_dispatch_{read|write} operand "unsigned size" into
"MemOp op".

Now size_memop is implemented, again hard coded size but with
MO_{8|16|32|64}. This is more expressive and avoids size_memop calls.

Signed-off-by: Tony Nguyen 
Reviewed-by: Richard Henderson 
Reviewed-by: Cornelia Huck 
---
 hw/s390x/s390-pci-inst.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
index 0c958fc..0e92a37 100644
--- a/hw/s390x/s390-pci-inst.c
+++ b/hw/s390x/s390-pci-inst.c
@@ -782,8 +782,7 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
r3, uint64_t gaddr,
 for (i = 0; i < len / 8; i++) {
 result = memory_region_dispatch_write(mr, offset + i * 8,
   ldq_p(buffer + i * 8),
-  size_memop(8),
-  MEMTXATTRS_UNSPECIFIED);
+  MO_64, MEMTXATTRS_UNSPECIFIED);
 if (result != MEMTX_OK) {
 s390_program_interrupt(env, PGM_OPERAND, 6, ra);
 return 0;
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 15/42] hw/audio: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/audio/cs4231.c  | 2 +-
 hw/audio/marvell_88w8618.c | 2 +-
 hw/audio/milkymist-ac97.c  | 2 +-
 hw/audio/pl041.c   | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/audio/cs4231.c b/hw/audio/cs4231.c
index 8372299..8946648 100644
--- a/hw/audio/cs4231.c
+++ b/hw/audio/cs4231.c
@@ -132,7 +132,7 @@ static void cs_mem_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps cs_mem_ops = {
 .read = cs_mem_read,
 .write = cs_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 };

 static const VMStateDescription vmstate_cs4231 = {
diff --git a/hw/audio/marvell_88w8618.c b/hw/audio/marvell_88w8618.c
index ff1a0d0..a79e0b1 100644
--- a/hw/audio/marvell_88w8618.c
+++ b/hw/audio/marvell_88w8618.c
@@ -240,7 +240,7 @@ static void mv88w8618_audio_reset(DeviceState *d)
 static const MemoryRegionOps mv88w8618_audio_ops = {
 .read = mv88w8618_audio_read,
 .write = mv88w8618_audio_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void mv88w8618_audio_init(Object *obj)
diff --git a/hw/audio/milkymist-ac97.c b/hw/audio/milkymist-ac97.c
index bf6a5a6..56feca2 100644
--- a/hw/audio/milkymist-ac97.c
+++ b/hw/audio/milkymist-ac97.c
@@ -176,7 +176,7 @@ static const MemoryRegionOps ac97_mmio_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 };

 static void ac97_in_cb(void *opaque, int avail_b)
diff --git a/hw/audio/pl041.c b/hw/audio/pl041.c
index 59c6ce1..b59a4f8 100644
--- a/hw/audio/pl041.c
+++ b/hw/audio/pl041.c
@@ -519,7 +519,7 @@ static void pl041_device_reset(DeviceState *d)
 static const MemoryRegionOps pl041_ops = {
 .read = pl041_read,
 .write = pl041_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl041_init(Object *obj)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 14/42] exec: Hard code size with MO_{8|16|32|64}

[tony.nguyen]

Temporarily no-op size_memop was introduced to aid the conversion of
memory_region_dispatch_{read|write} operand "unsigned size" into
"MemOp op".

Now size_memop is implemented, again hard coded size but with
MO_{8|16|32|64}. This is more expressive and avoids size_memop calls.

Signed-off-by: Tony Nguyen 
Reviewed-by: Richard Henderson 
---
 memory_ldst.inc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/memory_ldst.inc.c b/memory_ldst.inc.c
index 1e8a2fc..de658c4 100644
--- a/memory_ldst.inc.c
+++ b/memory_ldst.inc.c
@@ -38,7 +38,7 @@ static inline uint32_t glue(address_space_ldl_internal, 
SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , size_memop(4), attrs);
+r = memory_region_dispatch_read(mr, addr1, , MO_32, attrs);
 #if defined(TARGET_WORDS_BIGENDIAN)
 if (endian == DEVICE_LITTLE_ENDIAN) {
 val = bswap32(val);
@@ -114,7 +114,7 @@ static inline uint64_t glue(address_space_ldq_internal, 
SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , size_memop(8), attrs);
+r = memory_region_dispatch_read(mr, addr1, , MO_64, attrs);
 #if defined(TARGET_WORDS_BIGENDIAN)
 if (endian == DEVICE_LITTLE_ENDIAN) {
 val = bswap64(val);
@@ -188,7 +188,7 @@ uint32_t glue(address_space_ldub, SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , size_memop(1), attrs);
+r = memory_region_dispatch_read(mr, addr1, , MO_8, attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -224,7 +224,7 @@ static inline uint32_t glue(address_space_lduw_internal, 
SUFFIX)(ARG1_DECL,
 release_lock |= prepare_mmio_access(mr);

 /* I/O case */
-r = memory_region_dispatch_read(mr, addr1, , size_memop(2), attrs);
+r = memory_region_dispatch_read(mr, addr1, , MO_16, attrs);
 #if defined(TARGET_WORDS_BIGENDIAN)
 if (endian == DEVICE_LITTLE_ENDIAN) {
 val = bswap16(val);
@@ -300,7 +300,7 @@ void glue(address_space_stl_notdirty, SUFFIX)(ARG1_DECL,
 if (l < 4 || !memory_access_is_direct(mr, true)) {
 release_lock |= prepare_mmio_access(mr);

-r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_32, attrs);
 } else {
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
 stl_p(ptr, val);
@@ -346,7 +346,7 @@ static inline void glue(address_space_stl_internal, 
SUFFIX)(ARG1_DECL,
 val = bswap32(val);
 }
 #endif
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(4), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_32, attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -408,7 +408,7 @@ void glue(address_space_stb, SUFFIX)(ARG1_DECL,
 mr = TRANSLATE(addr, , , true, attrs);
 if (!memory_access_is_direct(mr, true)) {
 release_lock |= prepare_mmio_access(mr);
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(1), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_8, attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -451,7 +451,7 @@ static inline void glue(address_space_stw_internal, 
SUFFIX)(ARG1_DECL,
 val = bswap16(val);
 }
 #endif
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(2), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_16, attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
@@ -524,7 +524,7 @@ static void glue(address_space_stq_internal, 
SUFFIX)(ARG1_DECL,
 val = bswap64(val);
 }
 #endif
-r = memory_region_dispatch_write(mr, addr1, val, size_memop(8), attrs);
+r = memory_region_dispatch_write(mr, addr1, val, MO_64, attrs);
 } else {
 /* RAM case */
 ptr = qemu_map_ram_ptr(mr->ram_block, addr1);
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 19/42] hw/dma: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/dma/bcm2835_dma.c | 4 ++--
 hw/dma/etraxfs_dma.c | 2 +-
 hw/dma/pl080.c   | 2 +-
 hw/dma/pl330.c   | 2 +-
 hw/dma/puv3_dma.c| 2 +-
 hw/dma/sparc32_dma.c | 2 +-
 6 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/hw/dma/bcm2835_dma.c b/hw/dma/bcm2835_dma.c
index a39e8f4..907d25c 100644
--- a/hw/dma/bcm2835_dma.c
+++ b/hw/dma/bcm2835_dma.c
@@ -288,7 +288,7 @@ static void bcm2835_dma15_write(void *opaque, hwaddr 
offset, uint64_t value,
 static const MemoryRegionOps bcm2835_dma0_ops = {
 .read = bcm2835_dma0_read,
 .write = bcm2835_dma0_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid.min_access_size = 4,
 .valid.max_access_size = 4,
 };
@@ -296,7 +296,7 @@ static const MemoryRegionOps bcm2835_dma0_ops = {
 static const MemoryRegionOps bcm2835_dma15_ops = {
 .read = bcm2835_dma15_read,
 .write = bcm2835_dma15_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid.min_access_size = 4,
 .valid.max_access_size = 4,
 };
diff --git a/hw/dma/etraxfs_dma.c b/hw/dma/etraxfs_dma.c
index 85783eb..df3ba09 100644
--- a/hw/dma/etraxfs_dma.c
+++ b/hw/dma/etraxfs_dma.c
@@ -697,7 +697,7 @@ dma_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps dma_ops = {
  .read = dma_read,
  .write = dma_write,
- .endianness = DEVICE_NATIVE_ENDIAN,
+ .endianness = DEVICE_LITTLE_ENDIAN,
  .valid = {
  .min_access_size = 1,
  .max_access_size = 4
diff --git a/hw/dma/pl080.c b/hw/dma/pl080.c
index 7e57624..644eadb 100644
--- a/hw/dma/pl080.c
+++ b/hw/dma/pl080.c
@@ -346,7 +346,7 @@ static void pl080_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps pl080_ops = {
 .read = pl080_read,
 .write = pl080_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl080_reset(DeviceState *dev)
diff --git a/hw/dma/pl330.c b/hw/dma/pl330.c
index a56a3e7..4c51f2d 100644
--- a/hw/dma/pl330.c
+++ b/hw/dma/pl330.c
@@ -1493,7 +1493,7 @@ static uint64_t pl330_iomem_read(void *opaque, hwaddr 
offset,
 static const MemoryRegionOps pl330_ops = {
 .read = pl330_iomem_read,
 .write = pl330_iomem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 4,
 .max_access_size = 4,
diff --git a/hw/dma/puv3_dma.c b/hw/dma/puv3_dma.c
index 122f87a..7002373 100644
--- a/hw/dma/puv3_dma.c
+++ b/hw/dma/puv3_dma.c
@@ -75,7 +75,7 @@ static const MemoryRegionOps puv3_dma_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void puv3_dma_realize(DeviceState *dev, Error **errp)
diff --git a/hw/dma/sparc32_dma.c b/hw/dma/sparc32_dma.c
index 88765d0..6b32372 100644
--- a/hw/dma/sparc32_dma.c
+++ b/hw/dma/sparc32_dma.c
@@ -224,7 +224,7 @@ static void dma_mem_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps dma_mem_ops = {
 .read = dma_mem_read,
 .write = dma_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 .valid = {
 .min_access_size = 4,
 .max_access_size = 4,
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 17/42] hw/char: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/char/cadence_uart.c   | 2 +-
 hw/char/escc.c   | 2 +-
 hw/char/etraxfs_ser.c| 2 +-
 hw/char/grlib_apbuart.c  | 2 +-
 hw/char/imx_serial.c | 2 +-
 hw/char/lm32_uart.c  | 2 +-
 hw/char/milkymist-uart.c | 2 +-
 hw/char/pl011.c  | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c
index fa25fe2..6c7b904 100644
--- a/hw/char/cadence_uart.c
+++ b/hw/char/cadence_uart.c
@@ -457,7 +457,7 @@ static uint64_t uart_read(void *opaque, hwaddr offset,
 static const MemoryRegionOps uart_ops = {
 .read = uart_read,
 .write = uart_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void cadence_uart_reset(DeviceState *dev)
diff --git a/hw/char/escc.c b/hw/char/escc.c
index 8ddbb4b..36182d9 100644
--- a/hw/char/escc.c
+++ b/hw/char/escc.c
@@ -574,7 +574,7 @@ static uint64_t escc_mem_read(void *opaque, hwaddr addr,
 static const MemoryRegionOps escc_mem_ops = {
 .read = escc_mem_read,
 .write = escc_mem_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 .valid = {
 .min_access_size = 1,
 .max_access_size = 1,
diff --git a/hw/char/etraxfs_ser.c b/hw/char/etraxfs_ser.c
index 9745bca..cda687b 100644
--- a/hw/char/etraxfs_ser.c
+++ b/hw/char/etraxfs_ser.c
@@ -155,7 +155,7 @@ ser_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps ser_ops = {
 .read = ser_read,
 .write = ser_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
 .min_access_size = 4,
 .max_access_size = 4
diff --git a/hw/char/grlib_apbuart.c b/hw/char/grlib_apbuart.c
index c2bb3ac..119fc84 100644
--- a/hw/char/grlib_apbuart.c
+++ b/hw/char/grlib_apbuart.c
@@ -237,7 +237,7 @@ static void grlib_apbuart_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps grlib_apbuart_ops = {
 .write  = grlib_apbuart_write,
 .read   = grlib_apbuart_read,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 };

 static void grlib_apbuart_realize(DeviceState *dev, Error **errp)
diff --git a/hw/char/imx_serial.c b/hw/char/imx_serial.c
index 0655a95..7c66551 100644
--- a/hw/char/imx_serial.c
+++ b/hw/char/imx_serial.c
@@ -332,7 +332,7 @@ static void imx_event(void *opaque, int event)
 static const struct MemoryRegionOps imx_serial_ops = {
 .read = imx_serial_read,
 .write = imx_serial_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void imx_serial_realize(DeviceState *dev, Error **errp)
diff --git a/hw/char/lm32_uart.c b/hw/char/lm32_uart.c
index d047a44..2fe5f60 100644
--- a/hw/char/lm32_uart.c
+++ b/hw/char/lm32_uart.c
@@ -205,7 +205,7 @@ static void uart_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps uart_ops = {
 .read = uart_read,
 .write = uart_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 .valid = {
 .min_access_size = 4,
 .max_access_size = 4,
diff --git a/hw/char/milkymist-uart.c b/hw/char/milkymist-uart.c
index 8a78fcc..bdb8282 100644
--- a/hw/char/milkymist-uart.c
+++ b/hw/char/milkymist-uart.c
@@ -156,7 +156,7 @@ static const MemoryRegionOps uart_mmio_ops = {
 .min_access_size = 4,
 .max_access_size = 4,
 },
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 };

 static void uart_rx(void *opaque, const uint8_t *buf, int size)
diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index c1ae2f3..5fb95d2 100644
--- a/hw/char/pl011.c
+++ b/hw/char/pl011.c
@@ -287,7 +287,7 @@ static void pl011_event(void *opaque, int event)
 static const MemoryRegionOps pl011_ops = {
 .read = pl011_read,
 .write = pl011_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const VMStateDescription vmstate_pl011 = {
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 20/42] hw/gpio: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/gpio/pl061.c  | 2 +-
 hw/gpio/zaurus.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/gpio/pl061.c b/hw/gpio/pl061.c
index 02c01fd..da6ff6a 100644
--- a/hw/gpio/pl061.c
+++ b/hw/gpio/pl061.c
@@ -339,7 +339,7 @@ static void pl061_set_irq(void * opaque, int irq, int level)
 static const MemoryRegionOps pl061_ops = {
 .read = pl061_read,
 .write = pl061_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl061_luminary_init(Object *obj)
diff --git a/hw/gpio/zaurus.c b/hw/gpio/zaurus.c
index f2f1f67..599d862 100644
--- a/hw/gpio/zaurus.c
+++ b/hw/gpio/zaurus.c
@@ -156,7 +156,7 @@ static void scoop_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps scoop_ops = {
 .read = scoop_read,
 .write = scoop_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void scoop_gpio_set(void *opaque, int line, int level)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 21/42] hw/i2c: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/i2c/imx_i2c.c   | 2 +-
 hw/i2c/mpc_i2c.c   | 2 +-
 hw/i2c/versatile_i2c.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/i2c/imx_i2c.c b/hw/i2c/imx_i2c.c
index ce7a94c..de1107b 100644
--- a/hw/i2c/imx_i2c.c
+++ b/hw/i2c/imx_i2c.c
@@ -276,7 +276,7 @@ static const MemoryRegionOps imx_i2c_ops = {
 .write = imx_i2c_write,
 .valid.min_access_size = 1,
 .valid.max_access_size = 2,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const VMStateDescription imx_i2c_vmstate = {
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
index e9a1127..181228d 100644
--- a/hw/i2c/mpc_i2c.c
+++ b/hw/i2c/mpc_i2c.c
@@ -304,7 +304,7 @@ static const MemoryRegionOps i2c_ops = {
 .read =  mpc_i2c_read,
 .write =  mpc_i2c_write,
 .valid.max_access_size = 1,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_BIG_ENDIAN,
 };

 static const VMStateDescription mpc_i2c_vmstate = {
diff --git a/hw/i2c/versatile_i2c.c b/hw/i2c/versatile_i2c.c
index 1ac2a6f..c92d3b1 100644
--- a/hw/i2c/versatile_i2c.c
+++ b/hw/i2c/versatile_i2c.c
@@ -77,7 +77,7 @@ static void versatile_i2c_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps versatile_i2c_ops = {
 .read = versatile_i2c_read,
 .write = versatile_i2c_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void versatile_i2c_init(Object *obj)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 23/42] hw/intc: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/intc/arm_gic.c | 12 ++--
 hw/intc/arm_gicv3.c   |  4 ++--
 hw/intc/etraxfs_pic.c |  2 +-
 hw/intc/imx_avic.c|  2 +-
 hw/intc/imx_gpcv2.c   |  2 +-
 hw/intc/pl190.c   |  2 +-
 hw/intc/puv3_intc.c   |  2 +-
 7 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c
index 77427a4..283a63a 100644
--- a/hw/intc/arm_gic.c
+++ b/hw/intc/arm_gic.c
@@ -1999,38 +1999,38 @@ static const MemoryRegionOps gic_ops[2] = {
 {
 .read_with_attrs = gic_dist_read,
 .write_with_attrs = gic_dist_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 },
 {
 .read_with_attrs = gic_thiscpu_read,
 .write_with_attrs = gic_thiscpu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 }
 };

 static const MemoryRegionOps gic_cpu_ops = {
 .read_with_attrs = gic_do_cpu_read,
 .write_with_attrs = gic_do_cpu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static const MemoryRegionOps gic_virt_ops[2] = {
 {
 .read_with_attrs = gic_thiscpu_hyp_read,
 .write_with_attrs = gic_thiscpu_hyp_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 },
 {
 .read_with_attrs = gic_thisvcpu_read,
 .write_with_attrs = gic_thisvcpu_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 }
 };

 static const MemoryRegionOps gic_viface_ops = {
 .read_with_attrs = gic_do_hyp_read,
 .write_with_attrs = gic_do_hyp_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void arm_gic_realize(DeviceState *dev, Error **errp)
diff --git a/hw/intc/arm_gicv3.c b/hw/intc/arm_gicv3.c
index 66eaa97..9b4d5ba 100644
--- a/hw/intc/arm_gicv3.c
+++ b/hw/intc/arm_gicv3.c
@@ -352,12 +352,12 @@ static const MemoryRegionOps gic_ops[] = {
 {
 .read_with_attrs = gicv3_dist_read,
 .write_with_attrs = gicv3_dist_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 },
 {
 .read_with_attrs = gicv3_redist_read,
 .write_with_attrs = gicv3_redist_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 }
 };

diff --git a/hw/intc/etraxfs_pic.c b/hw/intc/etraxfs_pic.c
index 20e1391..d4a27d1 100644
--- a/hw/intc/etraxfs_pic.c
+++ b/hw/intc/etraxfs_pic.c
@@ -111,7 +111,7 @@ static void pic_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps pic_ops = {
 .read = pic_read,
 .write = pic_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .valid = {
 .min_access_size = 4,
 .max_access_size = 4
diff --git a/hw/intc/imx_avic.c b/hw/intc/imx_avic.c
index 83a4101..4bef842 100644
--- a/hw/intc/imx_avic.c
+++ b/hw/intc/imx_avic.c
@@ -308,7 +308,7 @@ static void imx_avic_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps imx_avic_ops = {
 .read = imx_avic_read,
 .write = imx_avic_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void imx_avic_reset(DeviceState *dev)
diff --git a/hw/intc/imx_gpcv2.c b/hw/intc/imx_gpcv2.c
index a8b..f37e6b5 100644
--- a/hw/intc/imx_gpcv2.c
+++ b/hw/intc/imx_gpcv2.c
@@ -64,7 +64,7 @@ static void imx_gpcv2_write(void *opaque, hwaddr offset,
 static const struct MemoryRegionOps imx_gpcv2_ops = {
 .read = imx_gpcv2_read,
 .write = imx_gpcv2_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 /*
  * Our device would not work correctly if the guest was doing
diff --git a/hw/intc/pl190.c b/hw/intc/pl190.c
index b4f31ef..e6eab1e 100644
--- a/hw/intc/pl190.c
+++ b/hw/intc/pl190.c
@@ -220,7 +220,7 @@ static void pl190_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps pl190_ops = {
 .read = pl190_read,
 .write = pl190_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl190_reset(DeviceState *d)
diff --git a/hw/intc/puv3_intc.c b/hw/intc/puv3_intc.c
index e2f6d98..97999cc 100644
--- 

[Xen-devel] [Qemu-devel] [PATCH v7 16/42] hw/block: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/block/onenand.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/block/onenand.c b/hw/block/onenand.c
index b3644f7..66152e7 100644
--- a/hw/block/onenand.c
+++ b/hw/block/onenand.c
@@ -769,7 +769,7 @@ static void onenand_write(void *opaque, hwaddr addr,
 static const MemoryRegionOps onenand_ops = {
 .read = onenand_read,
 .write = onenand_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void onenand_realize(DeviceState *dev, Error **errp)
--
1.8.3.1

?

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

[Xen-devel] [Qemu-devel] [PATCH v7 18/42] hw/display: Declare device little or big endian

[tony.nguyen]

For each device declared with DEVICE_NATIVE_ENDIAN, find the set of
targets from the set of target/hw/*/device.o.

If the set of targets are all little or all big endian, re-declare
the device endianness as DEVICE_LITTLE_ENDIAN or DEVICE_BIG_ENDIAN
respectively.

This *naive* deduction may result in genuinely native endian devices
being incorrectly declared as little or big endian, but should not
introduce regressions for current targets.

These devices should be re-declared as DEVICE_NATIVE_ENDIAN if 1) it
has a new target with an opposite endian or 2) someone informed knows
better =)

Signed-off-by: Tony Nguyen 
---
 hw/display/pl110.c| 2 +-
 hw/display/tc6393xb.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/display/pl110.c b/hw/display/pl110.c
index 2bdfc3c..d0c6317 100644
--- a/hw/display/pl110.c
+++ b/hw/display/pl110.c
@@ -471,7 +471,7 @@ static void pl110_write(void *opaque, hwaddr offset,
 static const MemoryRegionOps pl110_ops = {
 .read = pl110_read,
 .write = pl110_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 };

 static void pl110_mux_ctrl_set(void *opaque, int line, int level)
diff --git a/hw/display/tc6393xb.c b/hw/display/tc6393xb.c
index 0b7c59c..6bc3360 100644
--- a/hw/display/tc6393xb.c
+++ b/hw/display/tc6393xb.c
@@ -547,7 +547,7 @@ TC6393xbState *tc6393xb_init(MemoryRegion *sysmem, uint32_t 
base, qemu_irq irq)
 static const MemoryRegionOps tc6393xb_ops = {
 .read = tc6393xb_readb,
 .write = tc6393xb_writeb,
-.endianness = DEVICE_NATIVE_ENDIAN,
+.endianness = DEVICE_LITTLE_ENDIAN,
 .impl = {
 .min_access_size = 1,
 .max_access_size = 1,
--
1.8.3.1

?

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