[Xen-devel] [linux-4.14 test] 140193: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 139910
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 139910
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 139910
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 139910
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 139910
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 139910
 test-amd64-i386-xl-shadow   20 guest-start/debian.repeat fail REGR. vs. 139910
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 16 guest-localmigrate/x10 
fail REGR. vs. 139910

Tests which did not succeed, but are not blocking:
 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  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 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  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-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-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail 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-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-install   

[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

Re: [Xen-devel] [PATCH v6 2/8] xen/arm: make process_memory_node a device_tree_node_func

[Stefano Stabellini]

On Fri, 16 Aug 2019, Julien Grall wrote:
> Hi,
> 
> On 16/08/2019 00:36, Stefano Stabellini wrote:
> > Change the signature of process_memory_node to match
> > device_tree_node_func. Thanks to this change, the next patch will be
> > able to use device_tree_for_each_node to call process_memory_node on all
> > the children of a provided node.
> > 
> > Return error if there is no reg property or if nr_banks is reached. Let
> > the caller deal with the error.
> 
> This sentence does not match the change below. Only 2 of the new error paths
> are described here.
> 
> > 
> > Add a printk when device tree parsing fails.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v6:
> > - fix out of space check
> > - bring back printk when address_cells or size_cells are not properly set
> > - return -EINVAL in that case (different from reg missing)
> > - add printk when parsing fails
> > - return -ENOENT when memory size is 0
> > 
> > Changes in v5:
> > - return -ENOENT if address_cells or size_cells are not properly set
> > 
> > Changes in v4:
> > - return error if there is no reg propery, remove printk
> > - return error if nr_banks is reached
> > 
> > Changes in v3:
> > - improve commit message
> > - check return value of process_memory_node
> > 
> > Changes in v2:
> > - new
> > ---
> >   xen/arch/arm/bootfdt.c | 29 ++---
> >   1 file changed, 18 insertions(+), 11 deletions(-)
> > 
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index f1614ef7fc..9dc2c1352d 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -130,9 +130,10 @@ int __init device_tree_for_each_node(const void *fdt,
> > int node,
> >   return 0;
> >   }
> >   -static void __init process_memory_node(const void *fdt, int node,
> > -   const char *name,
> > -   u32 address_cells, u32 size_cells)
> > +static int __init process_memory_node(const void *fdt, int node,
> > +  const char *name, int depth,
> > +  u32 address_cells, u32 size_cells,
> > +  void *data)
> >   {
> >   const struct fdt_property *prop;
> >   int i;
> > @@ -145,15 +146,12 @@ static void __init process_memory_node(const void
> > *fdt, int node,
> >   {
> >   printk("fdt: node `%s': invalid #address-cells or #size-cells",
> >  name);
> > -return;
> > +return -EINVAL;
> >   }
> > prop = fdt_get_property(fdt, node, "reg", NULL);
> >   if ( !prop )
> > -{
> > -printk("fdt: node `%s': missing `reg' property\n", name);
> > -return;
> > -}
> > +return -ENOENT;
> > cell = (const __be32 *)prop->data;
> >   banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
> > @@ -162,11 +160,15 @@ static void __init process_memory_node(const void
> > *fdt, int node,
> >   {
> >   device_tree_get_reg(, address_cells, size_cells, ,
> > );
> >   if ( !size )
> > -continue;
> > +return -ENOENT;
> 
> I don't think we can treat the same way the lack of "regs" properties and a
> size of 0.
> 
> The former is expected as binding allow you to do it for reserved-memory. The
> latter is the user not writing the property correctly. So ignoring the latter
> will result to Xen potentially missing some reserved-regions (not great!).
> 
> So, similar to #address-cells/#size-cells discussion, we should return an
> error we are able to distinguish. Probably -EINVAL.

I think you are right, and honestly I was thinking about it while I
updated this patch. If I use -EINVAL, it would be the same return error
as the "invalid #address-cells or #size-cells". I just wanted to
double-check that it is OK for you.

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

Re: [Xen-devel] [PATCH v6 1/8] xen/arm: pass node to device_tree_for_each_node

[Stefano Stabellini]

On Fri, 16 Aug 2019, Julien Grall wrote:
> Hi,
> 
> On 16/08/2019 00:36, Stefano Stabellini wrote:
> > Add a new parameter to device_tree_for_each_node: node, the node to
> > start the search from. Passing 0 triggers the old behavior.
> 
> Here you say 0 triggers the old behavior but...
> 
> > 
> > Set min_depth to depth of the current node + 1 to avoid scanning
> > siblings of the initial node passed as an argument.
> > 
> > Don't call func() on the parent node passed as an argument. Clarify the
> > change in the comment on top of the function.
> 
> ... here you mention that the first node will be skipped. So the behavior is
> now different and should be explained in the commit message why this is fine
> to skip the root node.

Yes I'll update


> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> > Changes in v6:
> > - fix code style
> > - don't call func() on the first node
> > 
> > Changes in v5:
> > - go back to v3
> > - code style improvement in acpi/boot.c
> > - improve comments and commit message
> > - increase min_depth to avoid parsing siblings
> > - replace for with do/while loop and increase min_depth to avoid
> >scanning siblings of the initial node
> > - pass only node, calculate depth
> > 
> > Changes in v3:
> > - improve commit message
> > - improve in-code comments
> > - improve code style
> > 
> > Changes in v2:
> > - new
> > ---
> >   xen/arch/arm/acpi/boot.c  |  8 +---
> >   xen/arch/arm/bootfdt.c| 34 --
> >   xen/include/xen/device_tree.h |  6 +++---
> >   3 files changed, 28 insertions(+), 20 deletions(-)
> > 
> > diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> > index 9b29769a10..bf9c78b02c 100644
> > --- a/xen/arch/arm/acpi/boot.c
> > +++ b/xen/arch/arm/acpi/boot.c
> > @@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
> >* - the device tree is not empty (it has more than just a /chosen
> > node)
> >*   and ACPI has not been force enabled (acpi=force)
> >*/
> > -if ( param_acpi_off || ( !param_acpi_force
> > - &&
> > device_tree_for_each_node(device_tree_flattened,
> > -   dt_scan_depth1_nodes,
> > NULL)))
> > +if ( param_acpi_off)
> > +goto disable;
> > +if ( !param_acpi_force &&
> > + device_tree_for_each_node(device_tree_flattened, 0,
> > +   dt_scan_depth1_nodes, NULL) )
> >   goto disable;
> > /*
> > diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> > index 891b4b66ff..f1614ef7fc 100644
> > --- a/xen/arch/arm/bootfdt.c
> > +++ b/xen/arch/arm/bootfdt.c
> > @@ -75,9 +75,10 @@ static u32 __init device_tree_get_u32(const void *fdt,
> > int node,
> >   }
> > /**
> > - * device_tree_for_each_node - iterate over all device tree nodes
> > + * device_tree_for_each_node - iterate over all device tree sub-nodes
> >* @fdt: flat device tree.
> > - * @func: function to call for each node.
> > + * @node: parent node to start the search from
> > + * @func: function to call for each sub-node.
> >* @data: data to pass to @func.
> >*
> >* Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
> > @@ -85,20 +86,18 @@ static u32 __init device_tree_get_u32(const void *fdt,
> > int node,
> >* Returns 0 if all nodes were iterated over successfully.  If @func
> >* returns a value different from 0, that value is returned immediately.
> >*/
> > -int __init device_tree_for_each_node(const void *fdt,
> > +int __init device_tree_for_each_node(const void *fdt, int node,
> >device_tree_node_func func,
> >void *data)
> >   {
> > -int node;
> > -int depth;
> > +int depth = fdt_node_depth(fdt, node);
> 
> Sorry I didn't spot this in the previous version. As I pointed out on v4 (and
> you actually agreed!), you don't need the absolute depth...
> 
> You only need the relative depth. So this is a waste of processing as you have
> to go through the FDT to calculate the depth.
> 
> This is not entirely critical so I would be willing to consider a patch on top
> of this series.

I tried when I sent this version of the series, but I couldn't quite do
it that way. I wanted to get rid of the depth parameter to
device_tree_for_each_node, and we need to know the depth of the first
node passed as an argument to compare it with the depth of the next node
and figure out if it is at the same level or one level deeper.

How do you see this being implemented?





> > +int min_depth = depth + 1;
> > +int first_node = node;
> 
> NIT: Anything that can't change should really be const to catch any mistake.

OK

> 
> >   u32 address_cells[DEVICE_TREE_MAX_DEPTH];
> >   u32 size_cells[DEVICE_TREE_MAX_DEPTH];
> >   int ret;
> >   -for ( node = 0, depth = 0;
> > -  node >=0 && depth >= 0;
> > -  node 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f7efd9c792738f579e3c7062d8d3e90b21d8a771
baseline version:
 xen  854a49a7486a02edae5b3e53617bace526e9c1b1

Last test of basis   140124  2019-08-14 15:10:14 Z2 days
Testing same since   140214  2019-08-16 22:00:55 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Julien Grall 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   854a49a748..f7efd9c792  f7efd9c792738f579e3c7062d8d3e90b21d8a771 -> smoke

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

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

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

[Julien Grall]

Hi,

On 8/16/19 2:00 PM, Christoph Hellwig wrote:

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


I am not sure I agree with this rename. The implementation of the 
helpers are very Arm specific as this is assuming Dom0 is 1:1 mapped.


This was necessary due to the lack of IOMMU on Arm platforms back then.
But this is now a pain to get rid of it on newer platform...

Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 133580
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580
 test-amd64-amd64-xl-pvshim   12 guest-start  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
133580
 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580
 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 133580
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-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 

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

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

[Julien Grall]

On 8/16/19 6:42 PM, Julien Grall wrote:

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?


Speaking with my partner today (who is native english), "to" is actually 
the correct version here. So I will use "to" here.


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

[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

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

[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, 

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

[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 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 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] [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 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 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 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] [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

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

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] [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] [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] [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] [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] [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] [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] [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 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]

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] [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

[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 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] [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 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 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 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 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

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

[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 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 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] [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: 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

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] [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 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] [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] 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

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] [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

[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] [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] [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] [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] 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

[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] [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

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 

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] [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

[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] More QEMU gcc-9.1 build issues

[Anthony PERARD]

On Fri, Aug 09, 2019 at 02:32:47PM +0200, Dario Faggioli wrote:
> Hey Anthony,
> 
> There's more of those issues related to building our QEMU with recent
> (the one in openSUSE Tumbleweed) GCC:
> 
> gcc version 9.1.1 20190723 [gcc-9-branch revision 273734] (SUSE Linux)

[...]

> I fixed it by manually importing the following upstream commit:
> 
> 94932c95c10 "qxl: avoid unaligned pointer reads/writes"

Done. And I've merged every single commit available upstream! I hope
that's enough :-D.

Joke aside, QEMU v4.1 was released today, so I merged it. I was waiting
for that instead of cherry-picking the single commit you've pointed.

Cheers,

-- 
Anthony PERARD

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

Re: [Xen-devel] [qemu-s390x] [Qemu-devel] [PATCH v7 33/42] exec: Replace device_endian with MemOp

[Thomas Huth]

On 8/16/19 9:37 AM, tony.ngu...@bt.com wrote:
> Simplify endianness comparisons with consistent use of the more
> expressive MemOp.
> 
> Suggested-by: Richard Henderson 
> Signed-off-by: Tony Nguyen 
> Reviewed-by: Richard Henderson 
> Acked-by: David Gibson 

This patch is *huge*, more than 800kB. It keeps being stuck in the the
filter of the qemu-s390x list each time you send it. Please:

1) Try to break it up in more digestible pieces, e.g. change only one
subsystem at a time (this is also better reviewable by people who are
interested in one area)

2) Do not send HTML emails to the mailing list.

 Thanks,
  Thomas

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

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

[Philippe Mathieu-Daudé]

On 8/16/19 9:35 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.
> 
> 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,

OK.

>      .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,

Eh hard to say, PCI is not clear about endianess...

>  };
>  
>  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

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

[Philippe Mathieu-Daudé]

On 8/16/19 9:34 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.
> 
> 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,

Uh, I doubt that.

>  };
>  
>  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,

Being ioport, this one might be OK.

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

I don't think so,

>  };
>  
>  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,

neither here, but Peter will confirm.

>   };
>  
>  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,

This one I can't tell.

>  };
>  
>  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

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

[Philippe Mathieu-Daudé]

On 8/16/19 9:34 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.
> 
> 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,

Being ioport, one is probably OK.

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

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

[Julien Grall]

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 = <  
  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.


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

[Philippe Mathieu-Daudé]

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

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.

Regards,

Phil.

___
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

[Ross Lagerwall]

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

Older versions of GCC did not split .rodata.str sections by function.
Because of that, the entire section was always included.
The livepatch-build-tools commit [1] fixed patch creation and kept
including all .rodata.str sections, in order to maintain existing
behavior for GCC 6.1+.
This means all .rodata.str sections are always included by default,
regardless of whether they are needed or not.

During stacked hotpatch builds it leads to unnecessary accumulation of
the .rodata.str sections as each and every consecutive hotpatch module
contains all the .rodata.str sections of previous modules.

To prevent this situation, mark the .rodata.str sections for inclusion
only if they are referenced by any of the current hotpatch symbols (or
a corresponding RELA section).

Extend patchability verification to detect all non-standard, non-rela,
non-debug and non-special sections that are not referenced by any of
the symbols or RELA sections.

[1] 2af6f1aa6233 Fix patch creation with GCC 6.1+

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
v2:
* Made the commit message more precise and accurate (based on
   Ross' comments to the v1 patch)
* Kept lines limited to 80 chars
---
  create-diff-object.c | 30 --
  1 file changed, 28 insertions(+), 2 deletions(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index 8365af0..4252175 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1350,8 +1350,7 @@ static void kpatch_include_standard_elements(struct 
kpatch_elf *kelf)
  
  	list_for_each_entry(sec, >sections, list) {

/* include these sections even if they haven't changed */
-   if (is_standard_section(sec) ||
-   should_include_str_section(sec->name)) {
+   if (is_standard_section(sec)) {
sec->include = 1;
if (sec->secsym)
sec->secsym->include = 1;
@@ -1362,6 +1361,20 @@ static void kpatch_include_standard_elements(struct 
kpatch_elf *kelf)
list_entry(kelf->symbols.next, struct symbol, list)->include = 1;
  }
  
+static void kpatch_include_standard_string_elements(struct kpatch_elf *kelf)

+{
+   struct section *sec;
+
+   list_for_each_entry(sec, >sections, list) {
+   if (should_include_str_section(sec->name) &&
+   is_referenced_section(sec, kelf)) {
+   sec->include = 1;
+   if (sec->secsym)
+   sec->secsym->include = 1;
+   }
+   }
+}
+
  #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.
 */

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.


Thanks,
--
Ross Lagerwall

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

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

[Julien Grall]

Hi,

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".



+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

Re: [Xen-devel] [livepatch-build-tools part2 v2 2/6] common: Add is_referenced_section() helper function

[Ross Lagerwall]

On 8/7/19 12:49 PM, Pawel Wieczorkiewicz wrote:

This function checks if given section has an included corresponding
RELA section and/or any of the symbols table symbols references the
section. Section associated symbols are ignored here as there is
always such a symbol for every section.

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


Reviewed-by: 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 part2 v2 5/6] create-diff-object: Add new entries to special sections array array

[Ross Lagerwall]

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

Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section has undefined group_size.

Allow to specify different .livepatch.hooks* section entry size using
shell environment variable HOOK_STRUCT_SIZE.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
v2:
* Applied suggestions from Ross and neccessary changes enforced by
   previous patch of the series:
   - fixed indentation
   - used log_debug() instead of printf()
   - added aux. function undefined_group_size() returning 0 for a
 undefined group_size
   - added .altinstr_replacement to the special_sections array and
 fixed its group_size to undefined (0).
---
  create-diff-object.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/create-diff-object.c b/create-diff-object.c
index c6183c3..8365af0 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -995,6 +995,24 @@ static int altinstructions_group_size(struct kpatch_elf 
*kelf, int offset)
return size;
  }
  
+static int livepatch_hooks_group_size(struct kpatch_elf *kelf, int offset)

+{
+   static int size = 0;
+   char *str;
+   if (!size) {
+   str = getenv("HOOK_STRUCT_SIZE");
+   size = str ? atoi(str) : 8;
+   }
+
+   log_debug("livepatch_hooks_size=%d\n", size);
+   return size;
+}
+
+static int undefined_group_size(struct kpatch_elf *kelf, int offset)
+{
+   return 0;
+}
+
  /*
   * 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.


Regards,
--
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 part2 v2 3/6] create-diff-object: Add is_special_section() helper function function

[Ross Lagerwall]

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

This function determines, based on the given section name, if the
sections belongs to the special sections category.

Add more special sections to special_sections[] along with a new
undefined_group_size() helper function returning 0 (undefined).
New special sections are: .altinstr_replacement.


Is this paragraph describing patch 5/6?



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


Reviewed-by: Ross Lagerwall 

(With the above paragraph and the duplicate word in the subject removed, 
which I can do during commit.)


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 140148
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 140148
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 140148
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 140148
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 140148
 test-amd64-i386-xl-pvshim12 guest-start  fail   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-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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  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-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-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-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:
 qemuu9e06029aea3b2eca1d5261352e695edc1e7d7b8b
baseline version:
 qemuuf28ed74fd116491e31329044d140fde4aa23b2a0

Last test of basis   140148  2019-08-15 03:48:04 Z1 days
Testing same since   140170  2019-08-15 18:37:06 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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

Re: [Xen-devel] [PATCH v6 4/8] xen/arm: fix indentation in early_print_info

[Julien Grall]

Hi,

On 16/08/2019 00:36, Stefano Stabellini wrote:

No functional changes.

Signed-off-by: Stefano Stabellini 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 2/8] xen/arm: make process_memory_node a device_tree_node_func

[Julien Grall]

Hi,

On 16/08/2019 00:36, Stefano Stabellini wrote:

Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.

Return error if there is no reg property or if nr_banks is reached. Let
the caller deal with the error.


This sentence does not match the change below. Only 2 of the new error paths are 
described here.




Add a printk when device tree parsing fails.

Signed-off-by: Stefano Stabellini 
---
Changes in v6:
- fix out of space check
- bring back printk when address_cells or size_cells are not properly set
- return -EINVAL in that case (different from reg missing)
- add printk when parsing fails
- return -ENOENT when memory size is 0

Changes in v5:
- return -ENOENT if address_cells or size_cells are not properly set

Changes in v4:
- return error if there is no reg propery, remove printk
- return error if nr_banks is reached

Changes in v3:
- improve commit message
- check return value of process_memory_node

Changes in v2:
- new
---
  xen/arch/arm/bootfdt.c | 29 ++---
  1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index f1614ef7fc..9dc2c1352d 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -130,9 +130,10 @@ int __init device_tree_for_each_node(const void *fdt, int 
node,
  return 0;
  }
  
-static void __init process_memory_node(const void *fdt, int node,

-   const char *name,
-   u32 address_cells, u32 size_cells)
+static int __init process_memory_node(const void *fdt, int node,
+  const char *name, int depth,
+  u32 address_cells, u32 size_cells,
+  void *data)
  {
  const struct fdt_property *prop;
  int i;
@@ -145,15 +146,12 @@ static void __init process_memory_node(const void *fdt, 
int node,
  {
  printk("fdt: node `%s': invalid #address-cells or #size-cells",
 name);
-return;
+return -EINVAL;
  }
  
  prop = fdt_get_property(fdt, node, "reg", NULL);

  if ( !prop )
-{
-printk("fdt: node `%s': missing `reg' property\n", name);
-return;
-}
+return -ENOENT;
  
  cell = (const __be32 *)prop->data;

  banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
@@ -162,11 +160,15 @@ static void __init process_memory_node(const void *fdt, 
int node,
  {
  device_tree_get_reg(, address_cells, size_cells, , );
  if ( !size )
-continue;
+return -ENOENT;


I don't think we can treat the same way the lack of "regs" properties and a size 
of 0.


The former is expected as binding allow you to do it for reserved-memory. The 
latter is the user not writing the property correctly. So ignoring the latter 
will result to Xen potentially missing some reserved-regions (not great!).


So, similar to #address-cells/#size-cells discussion, we should return an error 
we are able to distinguish. Probably -EINVAL.


Cheers,

--
Julien Grall

___
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 4/6] livepatch-build: detect special section group sizes

[Ross Lagerwall]

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

Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.

This is a livepatch backport of kpatch upstream commit [1]:
kpatch-build: detect special section group sizes 170449847136a48b19fc

Xen only deals with alt_instr, bug_frame and exception_table_entry
structures, so sizes of these structures are obtained from xen-syms.

This change is needed since with recent Xen the alt_instr structure
has changed size from 12 to 14 bytes.

[1] 
https://github.com/jpoimboe/kpatch/commit/170449847136a48b19fcceb19c1d4d257d386b56

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Martin Mazein 
---
v2:
* Applied suggestions from Ross:
   - moved the livepatch-build hunk after build_full() call and
 re-using newly built xen-syms
   - dropped the redundant bug_frames_3_group_size()

Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v6 1/8] xen/arm: pass node to device_tree_for_each_node

[Julien Grall]

Hi,

On 16/08/2019 00:36, Stefano Stabellini wrote:

Add a new parameter to device_tree_for_each_node: node, the node to
start the search from. Passing 0 triggers the old behavior.


Here you say 0 triggers the old behavior but...



Set min_depth to depth of the current node + 1 to avoid scanning
siblings of the initial node passed as an argument.

Don't call func() on the parent node passed as an argument. Clarify the
change in the comment on top of the function.


... here you mention that the first node will be skipped. So the behavior is now 
different and should be explained in the commit message why this is fine to skip 
the root node.




Signed-off-by: Stefano Stabellini 
---
Changes in v6:
- fix code style
- don't call func() on the first node

Changes in v5:
- go back to v3
- code style improvement in acpi/boot.c
- improve comments and commit message
- increase min_depth to avoid parsing siblings
- replace for with do/while loop and increase min_depth to avoid
   scanning siblings of the initial node
- pass only node, calculate depth

Changes in v3:
- improve commit message
- improve in-code comments
- improve code style

Changes in v2:
- new
---
  xen/arch/arm/acpi/boot.c  |  8 +---
  xen/arch/arm/bootfdt.c| 34 --
  xen/include/xen/device_tree.h |  6 +++---
  3 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
index 9b29769a10..bf9c78b02c 100644
--- a/xen/arch/arm/acpi/boot.c
+++ b/xen/arch/arm/acpi/boot.c
@@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
   * - the device tree is not empty (it has more than just a /chosen node)
   *   and ACPI has not been force enabled (acpi=force)
   */
-if ( param_acpi_off || ( !param_acpi_force
- && 
device_tree_for_each_node(device_tree_flattened,
-   dt_scan_depth1_nodes, 
NULL)))
+if ( param_acpi_off)
+goto disable;
+if ( !param_acpi_force &&
+ device_tree_for_each_node(device_tree_flattened, 0,
+   dt_scan_depth1_nodes, NULL) )
  goto disable;
  
  /*

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 891b4b66ff..f1614ef7fc 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -75,9 +75,10 @@ static u32 __init device_tree_get_u32(const void *fdt, int 
node,
  }
  
  /**

- * device_tree_for_each_node - iterate over all device tree nodes
+ * device_tree_for_each_node - iterate over all device tree sub-nodes
   * @fdt: flat device tree.
- * @func: function to call for each node.
+ * @node: parent node to start the search from
+ * @func: function to call for each sub-node.
   * @data: data to pass to @func.
   *
   * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored.
@@ -85,20 +86,18 @@ static u32 __init device_tree_get_u32(const void *fdt, int 
node,
   * Returns 0 if all nodes were iterated over successfully.  If @func
   * returns a value different from 0, that value is returned immediately.
   */
-int __init device_tree_for_each_node(const void *fdt,
+int __init device_tree_for_each_node(const void *fdt, int node,
   device_tree_node_func func,
   void *data)
  {
-int node;
-int depth;
+int depth = fdt_node_depth(fdt, node);


Sorry I didn't spot this in the previous version. As I pointed out on v4 (and 
you actually agreed!), you don't need the absolute depth...


You only need the relative depth. So this is a waste of processing as you have 
to go through the FDT to calculate the depth.


This is not entirely critical so I would be willing to consider a patch on top 
of this series.



+int min_depth = depth + 1;
+int first_node = node;


NIT: Anything that can't change should really be const to catch any mistake.


  u32 address_cells[DEVICE_TREE_MAX_DEPTH];
  u32 size_cells[DEVICE_TREE_MAX_DEPTH];
  int ret;
  
-for ( node = 0, depth = 0;

-  node >=0 && depth >= 0;
-  node = fdt_next_node(fdt, node, ) )
-{
+do {
  const char *name = fdt_get_name(fdt, node, NULL);
  u32 as, ss;
  
@@ -117,10 +116,17 @@ int __init device_tree_for_each_node(const void *fdt,

  size_cells[depth] = device_tree_get_u32(fdt, node,
  "#size-cells", ss);
  
-ret = func(fdt, node, name, depth, as, ss, data);

-if ( ret != 0 )
-return ret;
-}
+/* skip the first node */
+if ( node != first_node )
+{
+ret = func(fdt, node, name, depth, as, ss, data);
+if ( ret != 0 )
+return ret;
+}
+
+node = fdt_next_node(fdt, node, );
+} while ( node >= 0 && depth >= min_depth );
+
  return 0;
  }
  
@@ -357,7 +363,7 @@ size_t __init 

Re: [Xen-devel] [livepatch-build-tools part2 v2 1/6] common: Add is_standard_section() helper function

[Ross Lagerwall]

On 8/7/19 12:32 PM, Pawel Wieczorkiewicz wrote:

Detect standard (always to be included) sections via their section
header type. The standard sections: ".shstrtab", ".symtab", ".strtab"
are either of type SHT_SYMTAB or SHT_STRTAB.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
v2:
* Keep lines to 80 chars
---

Reviewed-by: Ross Lagerwall 

Thanks

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