Re: [Xen-devel] [PATCH v10 10/25] x86: refactor psr: L3 CAT: set value: assemble features value array.

[Yi Sun]

On 17-04-11 09:11:20, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53,  wrote:
> > @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket,
> >  /* Set value functions */
> >  static unsigned int get_cos_num(const struct psr_socket_info *info)
> >  {
> > -return 0;
> > +unsigned int num = 0, i;
> > +
> > +/* Get all features total amount. */
> > +for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
> > +{
> > +const struct feat_node *feat = info->features[i];
> > +if ( !feat )
> 
> Blank line between ... (and I likely won't repeat this any further)
> 
Got it, will fix all of them.

> > +continue;
> > +
> > +feat = info->features[i];
> 
> ???
> 
Sorry, missed it.

> > @@ -611,7 +679,40 @@ static int insert_val_to_array(uint32_t val[],
> > enum cbm_type type,
> > uint32_t new_val)
> >  {
> > -return -EINVAL;
> > +const struct feat_node *feat;
> > +unsigned int i;
> > +
> > +ASSERT(feat_type < PSR_SOCKET_MAX_FEAT);
> > +
> > +/* Insert new value into array according to feature's position in 
> > array. */
> > +for ( i = 0; i < feat_type; i++ )
> > +{
> > +feat = info->features[i];
> > +if ( !feat )
> > +continue;
> > +
> > +if ( array_len <= feat->props->cos_num )
> > +return -ENOSPC;
> > +
> > +array_len -= feat->props->cos_num;
> > +
> > +val += feat->props->cos_num;
> > +}
> > +
> > +feat = info->features[feat_type];
> > +if ( !feat )
> > +return -ENOENT;
> > +
> > +if ( array_len < feat->props->cos_num )
> > +return -ENOSPC;
> > +
> > +if ( !psr_check_cbm(feat->props->cbm_len, new_val) )
> > +return -EINVAL;
> > +
> > +/* Value setting position is same as feature array. */
> > +val[0] = new_val;
> 
> How come this is array index 0 unconditionally, when cos_num
> may be greater than 1?
> 
This patch is to implement L3 CAT so I do not introduce 'type[]' yet. The
mechanism will be introduced in CDP patch.

> Jan

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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Yi Sun]

On 17-04-11 09:01:53, Jan Beulich wrote:
> >>> On 01.04.17 at 15:53,  wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket)
> >  {
> >  unsigned int i;
> >  struct psr_socket_info *info = socket_info + socket;
> > +struct domain *d;
> >  
> >  if ( !info )
> >  return;
> >  
> > +/* Restore domain cos id to 0 when socket is offline. */
> > +for_each_domain ( d )
> > +{
> > +unsigned int cos = d->arch.psr_cos_ids[socket];
> > +if ( cos == 0 )
> 
> Blank line between declaration(s) and statement(s) please.
> 
Ok, will modify other places where have same issue.

> > +continue;
> > +
> > +spin_lock(>ref_lock);
> > +ASSERT(!cos || info->cos_ref[cos]);
> 
> You've checked cos to be non-zero already above.
> 
Yep. Thanks!

> > +info->cos_ref[cos]--;
> > +spin_unlock(>ref_lock);
> > +
> > +d->arch.psr_cos_ids[socket] = 0;
> > +}
> 
> Overall, while you say in the revision log that this was a suggestion of
> mine, I don't recall any such (and I've just checked the v9 thread of
> this patch without finding anything), and hence it's not really clear to
> me why this is needed. After all you should be freeing info anyway

We discussed this in v9 05 patch. I paste it below for your convenience to
check.
[Sun Yi]:
  > So, you think the MSRs values may not be valid after such process and 
  > reloading (write MSRs to default value) is needed. If so, I would like 
  > to do more operations in 'free_feature()':
  > 1. Iterate all domains working on the offline socket to change
  >'d->arch.psr_cos_ids[socket]' to COS 0, i.e restore it back to init
  >status.
  > 2. Restore 'socket_info[socket].cos_ref[]' to all 0.
  > 
  > These can make the socket's info be totally restored back to init status.

[Jan]
  Yes, that's what I think is needed.

> (albeit I can't see this happening, which would look to be a bug in
> patch 5), so getting the refcounts adjusted seems pointless in any
> event. Whether d->arch.psr_cos_ids[socket] needs clearing I'm not

We only free resources in 'socket_info[socekt]' but do not free itself.
Below is how we allocate 'socket_info'. So, the 'socket_info[socekt]'
is not a pointer that can be directly freed.
  socket_info = xzalloc_array(struct psr_socket_info, nr_sockets);

That is the reason to reduce the 'info->cos_ref[cos]'.

> certain - this may indeed by unavoidable, to match up with
> psr_alloc_cos() using xzalloc.
> 
> Furthermore I'm not at all convinced this is appropriate to do in the
> context of a CPU_UP_CANCELED / CPU_DEAD notification: If you
> have a few thousand VMs, the loop above may take a while.
> 
Hmm, that may be a potential issue. I have two proposals below. Could you
please help to check which one you prefer? Or provide another solution?

1. Start a tasklet in free_socket_resources() to restore 'psr_cos_ids[socket]'
   of all domains. The action is protected by 'ref_lock' to avoid confliction
   in 'psr_set_val'. We can reduce 'info->cos_ref[cos]' in tasklet or memset
   the array to 0 in free_socket_resources().

2. Move 'psr_cos_ids[]' from 'domain' to 'psr_socket_info' and change index
   from 'socket' to 'domain_id'. So we keep all domains' COS IDs per socket
   and can memset the array to 0 when socket is offline. But here is an issue
   that we do not know how many members this array should have. I cannot find
   a macro something like 'DOMAIN_MAX_NUMBER'. So, I prefer to use reallocation
   in 'psr_alloc_cos' if the newly created domain's id is bigger than current
   array number.

> > @@ -574,15 +590,210 @@ int psr_get_val(struct domain *d, unsigned int 
> > socket,
> >  return 0;
> >  }
> >  
> > -int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> > -   uint64_t cbm, enum cbm_type type)
> > +/* Set value functions */
> > +static unsigned int get_cos_num(const struct psr_socket_info *info)
> >  {
> >  return 0;
> >  }
> >  
> > +static int gather_val_array(uint32_t val[],
> > +unsigned int array_len,
> > +const struct psr_socket_info *info,
> > +unsigned int old_cos)
> > +{
> > +return -EINVAL;
> > +}
> > +
> > +static int insert_val_to_array(uint32_t val[],
> 
> As indicated before, I'm pretty convinced "into" would be more
> natural than "to".
> 
Got it. Thanks!

> > +   unsigned int array_len,
> > +   const struct psr_socket_info *info,
> > +   enum psr_feat_type feat_type,
> > +   enum cbm_type type,
> > +   uint32_t new_val)
> > +{
> > +return -EINVAL;
> > +}
> > +
> > +static int find_cos(const uint32_t val[], unsigned int array_len,
> > +enum 

[Xen-devel] [xtf test] 107372: all pass - PUSHED

[osstest service owner]

flight 107372 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107372/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  e399b894f042d3f50d07a8619f7d7e7de410351d
baseline version:
 xtf  7a69524b288907b6d29581ddc1152b1324e13f73

Last test of basis   107352  2017-04-10 16:13:57 Z1 days
Testing same since   107372  2017-04-11 18:14:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

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

[Xen-devel] valgrind support for xen4.7+

[Glenn Enright]

Hi there

Has anyone seen or been working on patches for valgrind for recent 
versions of xen?


I was trying 3.13 from SVN against xen 4.7.2 and see that support for 
that version is not present. Per 
https://blog.xenproject.org/2013/01/18/using-valgrind-to-debug-xen-toolstacks/


A starter patch is below, but its probably wrong or incomplete. It does 
let me run


If valgrind is not the way any more, can anyone suggest any alternatives 
on testing for memory leaks?


Regards, Glenn
http://rimuhosting.com

Index: coregrind/m_syswrap/syswrap-xen.c
===
--- coregrind/m_syswrap/syswrap-xen.c   (revision 16301)
+++ coregrind/m_syswrap/syswrap-xen.c   (working copy)
@@ -584,6 +584,7 @@
case 0x0009:
case 0x000a:
case 0x000b:
+   case 0x000d:
   break;
default:
   bad_intf_version(tid, layout, arrghs, status, flags,
@@ -626,6 +627,7 @@
 break;
   case 0x000a:
   case 0x000b:
+  case 0x000d:
 PRE_XEN_SYSCTL_READ(getdomaininfolist_000a, first_domain);
 PRE_XEN_SYSCTL_READ(getdomaininfolist_000a, max_domains);
 PRE_XEN_SYSCTL_READ(getdomaininfolist_000a, buffer);

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

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/enlighten.c

between commit:

  687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 
code")

from the tip tree and commit:

  ca7b75377014 ("x86/xen: split off enlighten_pvh.c")

from the xen-tip tree.

The latter moved the code changed by the former to another file, so I
have applied the following merge fix patch.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell 
Date: Wed, 12 Apr 2017 14:27:23 +1000
Subject: [PATCH] x86/xen: merge fix for arch/x86/xen/enlighten.c code movement

Signed-off-by: Stephen Rothwell 
---
 arch/x86/xen/enlighten_pvh.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 331d7696af45..a4272c8620ce 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -38,34 +39,32 @@ static void __init init_pvh_bootparams(void)
 
memset(_bootparams, 0, sizeof(pvh_bootparams));
 
-   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
+   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
+   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
if (rc) {
xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
BUG();
}
 
-   if (memmap.nr_entries < E820MAX - 1) {
-   pvh_bootparams.e820_map[memmap.nr_entries].addr =
+   if (memmap.nr_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
+   pvh_bootparams.e820_table[memmap.nr_entries].addr =
ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[memmap.nr_entries].size =
+   pvh_bootparams.e820_table[memmap.nr_entries].size =
ISA_END_ADDRESS - ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[memmap.nr_entries].type =
-   E820_RESERVED;
+   pvh_bootparams.e820_table[memmap.nr_entries].type =
+   E820_TYPE_RESERVED;
memmap.nr_entries++;
} else
xen_raw_printk("Warning: Can fit ISA range into e820\n");
 
-   sanitize_e820_map(pvh_bootparams.e820_map,
- ARRAY_SIZE(pvh_bootparams.e820_map),
- _entries);
-
pvh_bootparams.e820_entries = memmap.nr_entries;
for (i = 0; i < pvh_bootparams.e820_entries; i++)
-   e820_add_region(pvh_bootparams.e820_map[i].addr,
-   pvh_bootparams.e820_map[i].size,
-   pvh_bootparams.e820_map[i].type);
+   e820__range_add(pvh_bootparams.e820_table[i].addr,
+   pvh_bootparams.e820_table[i].size,
+   pvh_bootparams.e820_table[i].type);
+
+   e820__update_table(e820_table);
 
pvh_bootparams.hdr.cmd_line_ptr =
pvh_start_info.cmdline_paddr;
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

[Chao Gao]

On Wed, Apr 12, 2017 at 02:45:36AM +, Xuquan (Quan Xu) wrote:
>On April 07, 2017 11:24 AM, Chao Gao wrote:
>>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>>operation is operated during one event delivery and incur to inconsistent
>>views of vIOAPIC. For example, if a periodic timer interrupt is from PIT, when
>>set the corresponding bit in vIRR, the corresponding RTE is accessed in
>>pt_update_irq(). When this function returns, it accesses the RTE again to get
>>the vector it set in vIRR.  Between the two accesses, the content of RTE may
>>have been changed by another CPU for no protection method in use. This case
>>can incur the assertion failure in vmx_intr_assist().  Also after a periodic
>>timer interrupt is injected successfully, pt_irq_posted() will decrease the
>>count (pending_intr_nr). But if the corresponding RTE has been changed,
>>pt_irq_posted() will not decrease the count, resulting one more timer
>>interrupt.
>>
>>More discussion and history can be found in
>>1.https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg00906.ht
>>ml
>>2.https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.ht
>>ml
>>
>>+/*
>>+ * Avoid the vIOAPIC RTE being changed by another vCPU.
>
>This comment seems inconsistent with the patch description, which said ' by 
>another CPU ', instead of 'by another vCPU'..
>

[Sorry. I ignored this in the previous email.]
Yes. Should be 'by another vCPU'.

Thanks
Chao

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

Re: [Xen-devel] [Qemu-devel] [PATCH v4 09/13] qobject: Use simpler QDict/QList scalar insertion macros

[Philippe Mathieu-Daudé]

On 04/11/2017 03:50 PM, Eric Blake wrote:

We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them.  To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.

Patch created mechanically via:
  spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h --dir . --in-place
and needed only one touch-up in monitor.c to avoid a long line.

Signed-off-by: Eric Blake 


Reviewed-by: Philippe Mathieu-Daudé 


---
v4: no change
v3: new patch
---
 block.c   | 45 +++--
 blockdev.c| 30 +-
 hw/block/xen_disk.c   |  2 +-
 hw/usb/xen-usb.c  | 12 ++--
 monitor.c | 23 +++
 qapi/qmp-event.c  |  2 +-
 qemu-img.c|  6 +++---
 qemu-io.c |  2 +-
 qemu-nbd.c|  2 +-
 qobject/qdict.c   |  2 +-
 target/s390x/cpu_models.c |  4 ++--
 util/qemu-option.c|  2 +-
 12 files changed, 60 insertions(+), 72 deletions(-)

diff --git a/block.c b/block.c
index 9024518..c8a6bce 100644
--- a/block.c
+++ b/block.c
@@ -937,16 +937,14 @@ static void update_flags_from_options(int *flags, 
QemuOpts *opts)
 static void update_options_from_flags(QDict *options, int flags)
 {
 if (!qdict_haskey(options, BDRV_OPT_CACHE_DIRECT)) {
-qdict_put(options, BDRV_OPT_CACHE_DIRECT,
-  qbool_from_bool(flags & BDRV_O_NOCACHE));
+qdict_put_bool(options, BDRV_OPT_CACHE_DIRECT, flags & BDRV_O_NOCACHE);
 }
 if (!qdict_haskey(options, BDRV_OPT_CACHE_NO_FLUSH)) {
-qdict_put(options, BDRV_OPT_CACHE_NO_FLUSH,
-  qbool_from_bool(flags & BDRV_O_NO_FLUSH));
+qdict_put_bool(options, BDRV_OPT_CACHE_NO_FLUSH,
+   flags & BDRV_O_NO_FLUSH);
 }
 if (!qdict_haskey(options, BDRV_OPT_READ_ONLY)) {
-qdict_put(options, BDRV_OPT_READ_ONLY,
-  qbool_from_bool(!(flags & BDRV_O_RDWR)));
+qdict_put_bool(options, BDRV_OPT_READ_ONLY, !(flags & BDRV_O_RDWR));
 }
 }

@@ -1362,7 +1360,7 @@ static int bdrv_fill_options(QDict **options, const char 
*filename,
 /* Fetch the file name from the options QDict if necessary */
 if (protocol && filename) {
 if (!qdict_haskey(*options, "filename")) {
-qdict_put(*options, "filename", qstring_from_str(filename));
+qdict_put_str(*options, "filename", filename);
 parse_filename = true;
 } else {
 error_setg(errp, "Can't specify 'file' and 'filename' options at "
@@ -1383,7 +1381,7 @@ static int bdrv_fill_options(QDict **options, const char 
*filename,
 }

 drvname = drv->format_name;
-qdict_put(*options, "driver", qstring_from_str(drvname));
+qdict_put_str(*options, "driver", drvname);
 } else {
 error_setg(errp, "Must specify either driver or file");
 return -EINVAL;
@@ -2038,7 +2036,7 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict 
*parent_options,
 }

 if (bs->backing_format[0] != '\0' && !qdict_haskey(options, "driver")) {
-qdict_put(options, "driver", qstring_from_str(bs->backing_format));
+qdict_put_str(options, "driver", bs->backing_format);
 }

 backing_hd = bdrv_open_inherit(*backing_filename ? backing_filename : NULL,
@@ -2193,12 +2191,9 @@ static BlockDriverState 
*bdrv_append_temp_snapshot(BlockDriverState *bs,
 }

 /* Prepare options QDict for the temporary file */
-qdict_put(snapshot_options, "file.driver",
-  qstring_from_str("file"));
-qdict_put(snapshot_options, "file.filename",
-  qstring_from_str(tmp_filename));
-qdict_put(snapshot_options, "driver",
-  qstring_from_str("qcow2"));
+qdict_put_str(snapshot_options, "file.driver", "file");
+qdict_put_str(snapshot_options, "file.filename", tmp_filename);
+qdict_put_str(snapshot_options, "driver", "qcow2");

 bs_snapshot = bdrv_open(NULL, NULL, snapshot_options, flags, errp);
 snapshot_options = NULL;
@@ -2373,8 +2368,7 @@ static BlockDriverState *bdrv_open_inherit(const char 
*filename,
 goto fail;
 }

-qdict_put(options, "file",
-  qstring_from_str(bdrv_get_node_name(file_bs)));
+qdict_put_str(options, "file", bdrv_get_node_name(file_bs));
 }
 }

@@ -2396,8 +2390,8 @@ static BlockDriverState *bdrv_open_inherit(const char 
*filename,
  * sure to update both bs->options (which has the full effective
  * options for bs) and options (which has file.* already removed).
  */
-qdict_put(bs->options, "driver", qstring_from_str(drv->format_name));
-qdict_put(options, "driver", 

[Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the xen-tip tree got a conflict in:

  arch/x86/xen/mmu.c

between commit:

  66441bd3cfdc ("x86/boot/e820: Move asm/e820.h to asm/e820/api.h")

from the tip tree and commit:

  5159dc315db8 ("x86/xen: split off mmu_pv.c")

from the xen-tip tree.

The code changed in the former was moved to a new file by the latter,
so I applied the following merge fix patch.

This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

From: Stephen Rothwell 
Date: Wed, 12 Apr 2017 14:17:58 +1000
Subject: [PATCH] x86/xen: merge fix up for arch/x86/xen/mmu.c code movement

Signed-off-by: Stephen Rothwell 
---
 arch/x86/xen/mmu_pv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 284d189f40dd..c98bfb9f0248 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -58,7 +58,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linuxc08e611b7d0169b513e3b4515ffd51ac7f37f22c
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  642 days
Failing since 59348  2015-07-10 04:24:05 Z  641 days  383 attempts
Testing same since   107367  2017-04-11 09:21:21 Z0 days1 attempts


8151 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

[Chao Gao]

On Wed, Apr 12, 2017 at 02:45:36AM +, Xuquan (Quan Xu) wrote:
>On April 07, 2017 11:24 AM, Chao Gao wrote:
>>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>>operation is operated during one event delivery and incur to inconsistent
>>views of vIOAPIC. For example, if a periodic timer interrupt is from PIT, when
>>set the corresponding bit in vIRR, the corresponding RTE is accessed in
>>pt_update_irq(). When this function returns, it accesses the RTE again to get
>>the vector it set in vIRR.  Between the two accesses, the content of RTE may
>>have been changed by another CPU for no protection method in use. This case
>>can incur the assertion failure in vmx_intr_assist().  Also after a periodic
>>timer interrupt is injected successfully, pt_irq_posted() will decrease the
>>count (pending_intr_nr). But if the corresponding RTE has been changed,
>>pt_irq_posted() will not decrease the count, resulting one more timer
>>interrupt.
>>
>>More discussion and history can be found in
>>1.https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg00906.ht
>>ml
>>2.https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.ht
>>ml
>>
>>This patch simply uses irq_lock to avoid these inconsistent views of vIOAPIC.
>
>To vLAPIC, is it in a similar situation?

For vLAPIC, there is no such situation. The irq field in structure periodic_time
has different meanings for vLAPIC/vIOAPIC case. For vLAPIC case, it is the 
interrupt
vector. For vIOAPIC case, it is the irq number; to get interrupt vector and to
deliver this interrupt, accessing IOAPIC RTE is needed.

Thanks
Chao

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

Re: [Xen-devel] [RFC PATCH] hvm/vpt: fix inconsistent views of vIOAPIC in vmx_intr_assist()

[Xuquan (Quan Xu)]

On April 07, 2017 11:24 AM, Chao Gao wrote:
>When injecting periodic timer interrupt in vmx_intr_assist(), multiple read
>operation is operated during one event delivery and incur to inconsistent
>views of vIOAPIC. For example, if a periodic timer interrupt is from PIT, when
>set the corresponding bit in vIRR, the corresponding RTE is accessed in
>pt_update_irq(). When this function returns, it accesses the RTE again to get
>the vector it set in vIRR.  Between the two accesses, the content of RTE may
>have been changed by another CPU for no protection method in use. This case
>can incur the assertion failure in vmx_intr_assist().  Also after a periodic
>timer interrupt is injected successfully, pt_irq_posted() will decrease the
>count (pending_intr_nr). But if the corresponding RTE has been changed,
>pt_irq_posted() will not decrease the count, resulting one more timer
>interrupt.
>
>More discussion and history can be found in
>1.https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg00906.ht
>ml
>2.https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg01019.ht
>ml
>
>This patch simply uses irq_lock to avoid these inconsistent views of vIOAPIC.

To vLAPIC, is it in a similar situation?


>To fix the deadlock, provide locked version of several functions.
>
>Signed-off-by: Chao Gao 
>---
> xen/arch/x86/hvm/irq.c  | 22 --
> xen/arch/x86/hvm/svm/intr.c | 21 +++--
>xen/arch/x86/hvm/vmx/intr.c |  9 +
> xen/arch/x86/hvm/vpic.c | 20 ++--
> xen/arch/x86/hvm/vpt.c  |  4 ++--
> xen/include/xen/hvm/irq.h   |  4 
> 6 files changed, 60 insertions(+), 20 deletions(-)
>
>diff --git a/xen/arch/x86/hvm/irq.c b/xen/arch/x86/hvm/irq.c index
>8625584..a1af61e 100644
>--- a/xen/arch/x86/hvm/irq.c
>+++ b/xen/arch/x86/hvm/irq.c
>@@ -126,37 +126,47 @@ void hvm_pci_intx_deassert(
> spin_unlock(>arch.hvm_domain.irq_lock);
> }
>
>-void hvm_isa_irq_assert(
>+void hvm_isa_irq_assert_locked(
> struct domain *d, unsigned int isa_irq)  {
> struct hvm_irq *hvm_irq = hvm_domain_irq(d);
> unsigned int gsi = hvm_isa_irq_to_gsi(isa_irq);
>
> ASSERT(isa_irq <= 15);
>-
>-spin_lock(>arch.hvm_domain.irq_lock);
>+ASSERT(spin_is_locked(>arch.hvm_domain.irq_lock));
>
> if ( !__test_and_set_bit(isa_irq, _irq->isa_irq.i) &&
>  (hvm_irq->gsi_assert_count[gsi]++ == 0) )
> assert_irq(d, gsi, isa_irq);
>+}
>
>+void hvm_isa_irq_assert(
>+struct domain *d, unsigned int isa_irq) {
>+spin_lock(>arch.hvm_domain.irq_lock);
>+hvm_isa_irq_assert_locked(d, isa_irq);
> spin_unlock(>arch.hvm_domain.irq_lock);
> }
>
>-void hvm_isa_irq_deassert(
>+void hvm_isa_irq_deassert_locked(
> struct domain *d, unsigned int isa_irq)  {
> struct hvm_irq *hvm_irq = hvm_domain_irq(d);
> unsigned int gsi = hvm_isa_irq_to_gsi(isa_irq);
>
> ASSERT(isa_irq <= 15);
>-
>-spin_lock(>arch.hvm_domain.irq_lock);
>+ASSERT(spin_is_locked(>arch.hvm_domain.irq_lock));
>
> if ( __test_and_clear_bit(isa_irq, _irq->isa_irq.i) &&
>  (--hvm_irq->gsi_assert_count[gsi] == 0) )
> deassert_irq(d, isa_irq);
>+}
>
>+void hvm_isa_irq_deassert(
>+struct domain *d, unsigned int isa_irq) {
>+spin_lock(>arch.hvm_domain.irq_lock);
>+hvm_isa_irq_deassert_locked(d, isa_irq);
> spin_unlock(>arch.hvm_domain.irq_lock);
> }
>
>diff --git a/xen/arch/x86/hvm/svm/intr.c b/xen/arch/x86/hvm/svm/intr.c
>index 8511ff0..d2a318c 100644
>--- a/xen/arch/x86/hvm/svm/intr.c
>+++ b/xen/arch/x86/hvm/svm/intr.c
>@@ -137,18 +137,25 @@ void svm_intr_assist(void)
> struct hvm_intack intack;
> enum hvm_intblk intblk;
>
>+/*
>+ * Avoid the vIOAPIC RTE being changed by another vCPU.
>+ * Otherwise, pt_update_irq() may return a wrong vector which is not
>in
>+ * vIRR and pt_irq_posted() may not recognize a timer interrupt has
>been
>+ * injected.
>+ */
>+spin_lock(>domain->arch.hvm_domain.irq_lock);
> /* Crank the handle on interrupt state. */
> pt_update_irq(v);
>
> do {
> intack = hvm_vcpu_has_pending_irq(v);
> if ( likely(intack.source == hvm_intsrc_none) )
>-return;
>+goto out;
>
> intblk = hvm_interrupt_blocked(v, intack);
> if ( intblk == hvm_intblk_svm_gif ) {
> ASSERT(nestedhvm_enabled(v->domain));
>-return;
>+goto out;
> }
>
> /* Interrupts for the nested guest are already @@ -165,13 +172,13
>@@ void svm_intr_assist(void)
> switch (rc) {
> case NSVM_INTR_NOTINTERCEPTED:
> /* Inject interrupt into 2nd level guest directly. */
>-break;
>+goto out;
> case NSVM_INTR_NOTHANDLED:
> case NSVM_INTR_FORCEVMEXIT:
>-return;
>+goto out;
> case NSVM_INTR_MASKED:
> /* Guest already enabled an interrupt 

[Xen-devel] [PATCH] tools:misc:xenpm: set max freq to all cpu with default cpuid

[Luwei Kang]

User can set max freq to specific cpu by
"xenpm set-scaling-maxfreq  "
or set max freq to all cpu with default cpuid by
"xenpm set-scaling-maxfreq ".

Set max freq with defaule cpuid will cause
segmentation fault after commit id d4906b5d05.
This patch will fix this issue and add ability
to set max freq with default cpuid.

Signed-off-by: Luwei Kang 
---
 tools/misc/xenpm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index ded40b9..abe31b5 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -99,8 +99,10 @@ static void parse_cpuid_and_int(int argc, char *argv[],
  exit(EINVAL);
 }
 
-parse_cpuid(argv[0], cpuid);
-if ( sscanf(argv[1], "%d", val) != 1 )
+if ( argc > 1 )
+parse_cpuid(argv[0], cpuid);
+
+if ( argc == 0 || sscanf(argv[argc > 1], "%d", val) != 1 )
 {
 fprintf(stderr, "Invalid %s '%s'\n", what, argv[1]);
 exit(EINVAL);
-- 
1.8.3.1


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

[Xen-devel] [PATCH v8 19/27] ARM: vITS: handle MAPTI command

[Andre Przywara]

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering LPI on the host can be quickly forwarded to a guest.
Beside entering the VCPU and the virtual LPI number in the respective
host LPI entry, we also initialize and add the already allocated
struct pending_irq to our radix tree, so that we can now easily find it
by its virtual LPI number.
We also read the property table to update the enabled bit and the
priority for our new LPI, as we might have missed this during an earlier
INVALL call (which only checks mapped LPIs).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c|  35 
 xen/arch/arm/vgic-v3-its.c   | 114 +++
 xen/include/asm-arm/gic_v3_its.h |   3 ++
 3 files changed, 152 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 900c9d1..fa1f2d5 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -860,6 +860,41 @@ int gicv3_remove_guest_event(struct domain *d, paddr_t 
vdoorbell_address,
 return 0;
 }
 
+/*
+ * Connects the event ID for an already assigned device to the given VCPU/vLPI
+ * pair. The corresponding physical LPI is already mapped on the host side
+ * (when assigning the physical device to the guest), so we just connect the
+ * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
+ * Returns a pointer to the already allocated struct pending_irq that is
+ * meant to be used by that event.
+ */
+struct pending_irq *gicv3_assign_guest_event(struct domain *d,
+ paddr_t vdoorbell_address,
+ uint32_t vdevid, uint32_t 
veventid,
+ struct vcpu *v, uint32_t virt_lpi)
+{
+struct its_device *dev;
+struct pending_irq *pirq = NULL;
+uint32_t host_lpi = 0;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, vdoorbell_address, vdevid);
+if ( dev )
+{
+host_lpi = get_host_lpi(dev, veventid);
+pirq = >pend_irqs[veventid];
+}
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !host_lpi || !pirq )
+return NULL;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
+v ? v->vcpu_id : INVALID_VCPU_ID, virt_lpi);
+
+return pirq;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 104017e..b7e61b2 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -390,6 +390,34 @@ static int its_handle_int(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+/*
+ * For a given virtual LPI read the enabled bit and priority from the virtual
+ * property table and update the virtual IRQ's state in the given pending_irq.
+ * Must be called with the respective VGIC VCPU lock held.
+ */
+static int update_lpi_property(struct domain *d, uint32_t vlpi,
+   struct pending_irq *p)
+{
+paddr_t addr;
+uint8_t property;
+int ret;
+
+addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
+
+ret = vgic_access_guest_memory(d, addr + vlpi - LPI_OFFSET,
+   , sizeof(property), false);
+if ( ret )
+return ret;
+
+p->lpi_priority = property & LPI_PROP_PRIO_MASK;
+if ( property & LPI_PROP_ENABLED )
+set_bit(GIC_IRQ_GUEST_ENABLED, >status);
+else
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+
+return 0;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -532,6 +560,88 @@ static int its_handle_mapd(struct virt_its *its, uint64_t 
*cmdptr)
 return ret;
 }
 
+static int its_handle_mapti(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+uint32_t intid = its_cmd_get_physical_id(cmdptr), _intid;
+uint16_t collid = its_cmd_get_collection(cmdptr);
+struct pending_irq *pirq;
+struct vcpu *vcpu = NULL;
+int ret = -1;
+
+if ( its_cmd_get_command(cmdptr) == GITS_CMD_MAPI )
+intid = eventid;
+
+spin_lock(>its_lock);
+/*
+ * Check whether there is a valid existing mapping. If yes, behavior is
+ * unpredictable, we choose to ignore this command here.
+ * This makes sure we start with a pristine pending_irq below.
+ */
+if ( read_itte_locked(its, devid, eventid, , &_intid) &&
+ _intid != INVALID_LPI )
+{
+spin_unlock(>its_lock);
+return -1;
+}
+
+/* Enter the mapping in our virtual ITS tables. */
+if ( 

[Xen-devel] [PATCH v8 21/27] ARM: vITS: handle MOVI command

[Andre Przywara]

The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 24 +
 xen/arch/arm/gic-v3-lpi.c| 15 +++
 xen/arch/arm/vgic-v3-its.c   | 57 
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 4 files changed, 100 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index fa1f2d5..1a08d43 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -895,6 +895,30 @@ struct pending_irq *gicv3_assign_guest_event(struct domain 
*d,
 return pirq;
 }
 
+/* Changes the target VCPU for a given host LPI assigned to a domain. */
+int gicv3_lpi_change_vcpu(struct domain *d, paddr_t vdoorbell,
+  uint32_t vdevid, uint32_t veventid,
+  unsigned int vcpu_id)
+{
+uint32_t host_lpi;
+struct its_device *dev;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, vdoorbell, vdevid);
+if ( dev )
+host_lpi = get_host_lpi(dev, veventid);
+else
+host_lpi = 0;
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !host_lpi )
+return -ENOENT;
+
+gicv3_lpi_update_host_vcpuid(host_lpi, vcpu_id);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index d427539..6af5ad9 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -225,6 +225,21 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int 
domain_id,
 write_u64_atomic(>data, hlpi.data);
 }
 
+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, unsigned int vcpu_id)
+{
+union host_lpi *hlpip;
+
+ASSERT(host_lpi >= LPI_OFFSET);
+
+host_lpi -= LPI_OFFSET;
+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+write_u16_atomic(>vcpu_id, vcpu_id);
+
+return 0;
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 0765810..be9de08 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -647,6 +647,57 @@ out_remove_mapping:
 return ret;
 }
 
+static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+int collid = its_cmd_get_collection(cmdptr);
+unsigned long flags;
+struct pending_irq *p;
+struct vcpu *ovcpu, *nvcpu;
+uint32_t vlpi;
+int ret = -1;
+
+spin_lock(>its_lock);
+/* Check for a mapped LPI and get the LPI number. */
+if ( !read_itte_locked(its, devid, eventid, , ) )
+goto out_unlock;
+
+if ( vlpi == INVALID_LPI )
+{
+spin_unlock(>its_lock);
+return -1;
+}
+
+/* Check the new collection ID and get the new VCPU pointer */
+nvcpu = get_vcpu_from_collection(its, collid);
+if ( !nvcpu )
+goto out_unlock;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* Update our cached vcpu_id in the pending_irq. */
+p = its->d->arch.vgic.handler->lpi_to_pending(its->d, vlpi);
+p->lpi_vcpu_id = nvcpu->vcpu_id;
+
+/* Now store the new collection in the translation table. */
+if ( !write_itte_locked(its, devid, eventid, collid, vlpi, ) )
+goto out_unlock;
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+spin_unlock(>its_lock);
+
+/* TODO: lookup currently-in-guest virtual IRQs and migrate them? */
+
+return gicv3_lpi_change_vcpu(its->d, its->doorbell_address,
+ devid, eventid, nvcpu->vcpu_id);
+
+out_unlock:
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -692,6 +743,12 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_MAPTI:
 ret = its_handle_mapti(its, command);
 break;
+case GITS_CMD_MOVALL:
+gdprintk(XENLOG_G_INFO, "ITS: ignoring MOVALL command\n");
+break;
+case GITS_CMD_MOVI:
+ret = its_handle_movi(its, command);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
 break;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index 7b16aeb..ee69e9b 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -175,8 +175,12 

[Xen-devel] [PATCH v8 11/27] ARM: VGIC: add vcpu_id to struct pending_irq

[Andre Przywara]

The target CPU for an LPI is encoded in the interrupt translation table
entry, so can't be easily derived from just an LPI number (short of
walking *all* tables and find the matching LPI).
To avoid this in case we need to know the VCPU (for the INVALL command,
for instance), put the VCPU ID in the struct pending_irq, so that it is
easily accessible.
We use the remaining 8 bits of padding space for that to avoid enlarging
the size of struct pending_irq. The number of VCPUs is limited to 127
at the moment anyway.

Signed-off-by: Andre Przywara 
---
 xen/include/asm-arm/vgic.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index e2111a5..02732db 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -73,6 +73,7 @@ struct pending_irq
 uint8_t lr;
 uint8_t priority;
 uint8_t lpi_priority;   /* Caches the priority if this is an LPI. */
+uint8_t lpi_vcpu_id;/* The VCPU for an LPI. */
 /* inflight is used to append instances of pending_irq to
  * vgic.inflight_irqs */
 struct list_head inflight;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 26/27] ARM: vITS: create and initialize virtual ITSes for Dom0

[Andre Przywara]

For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
This introduces a function to initialize a virtual ITS.
We maintain a list of virtual ITSes, at the moment for the only
purpose of later being able to free them again.
We configure the virtual ITSes to match the hardware ones, that is we
keep the number of device ID bits and event ID bits the same as the host
ITS.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 74 
 xen/arch/arm/vgic-v3.c   |  4 +++
 xen/include/asm-arm/domain.h |  1 +
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 4 files changed, 83 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 1622e53..956b59c 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
 struct domain *d;
+struct list_head vits_list;
 paddr_t doorbell_address;
 unsigned int devid_bits;
 unsigned int evid_bits;
@@ -100,14 +101,49 @@ unsigned int vgic_v3_its_count(const struct domain *d)
 
 int vgic_v3_its_init_domain(struct domain *d)
 {
+int ret;
+
+INIT_LIST_HEAD(>arch.vgic.vits_list);
 spin_lock_init(>arch.vgic.its_devices_lock);
 d->arch.vgic.its_devices = RB_ROOT;
 
+if ( is_hardware_domain(d) )
+{
+struct host_its *hw_its;
+
+list_for_each_entry(hw_its, _its_list, entry)
+{
+/*
+ * For each host ITS create a virtual ITS using the same
+ * base and thus doorbell address.
+ * Use the same number of device ID and event ID bits as the host.
+ */
+ret = vgic_v3_its_init_virtual(d, hw_its->addr,
+   hw_its->devid_bits,
+   hw_its->evid_bits);
+if ( ret )
+{
+vgic_v3_its_free_domain(d);
+return ret;
+}
+else
+d->arch.vgic.has_its = true;
+}
+}
+
 return 0;
 }
 
 void vgic_v3_its_free_domain(struct domain *d)
 {
+struct virt_its *pos, *temp;
+
+list_for_each_entry_safe( pos, temp, >arch.vgic.vits_list, vits_list )
+{
+list_del(>vits_list);
+xfree(pos);
+}
+
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }
 
@@ -1377,6 +1413,44 @@ static const struct mmio_handler_ops 
vgic_its_mmio_handler = {
 .write = vgic_v3_its_mmio_write,
 };
 
+int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
+ unsigned int devid_bits, unsigned int evid_bits)
+{
+struct virt_its *its;
+uint64_t base_attr;
+
+its = xzalloc(struct virt_its);
+if ( !its )
+return -ENOMEM;
+
+base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_SameAsInner << 
GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+its->cbaser  = base_attr;
+base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;/* 4K pages */
+its->baser_dev = GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+its->baser_dev |= (DEV_TABLE_ENTRY_SIZE - 1) << 
GITS_BASER_ENTRY_SIZE_SHIFT;
+its->baser_dev |= base_attr;
+its->baser_coll  = GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+its->baser_coll |= (COLL_TABLE_ENTRY_SIZE - 1) <<
+GITS_BASER_ENTRY_SIZE_SHIFT;
+its->baser_coll |= base_attr;
+its->d = d;
+its->doorbell_address = guest_addr + ITS_DOORBELL_OFFSET;
+its->devid_bits = devid_bits;
+its->evid_bits = evid_bits;
+spin_lock_init(>vcmd_lock);
+spin_lock_init(>its_lock);
+
+register_mmio_handler(d, _its_mmio_handler, guest_addr, SZ_64K, its);
+
+/* Register the virtual ITSes to be able to clean them up later. */
+list_add_tail(>vits_list, >arch.vgic.vits_list);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index e8ed658..e576e31 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1695,6 +1695,10 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.rdist_regions[0].first_cpu = 0;
 }
 
+/*
+ * For a hardware domain, this will iterate over the host ITSes
+ * and maps  one virtual ITS per host ITS at the same address.
+ */
 ret = vgic_v3_its_init_domain(d);
 if ( ret )
 return ret;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index b2d98bb..92f4ce5 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -115,6 +115,7 @@ struct arch_domain
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
 struct radix_tree_root pend_lpi_tree; /* Stores struct 

[Xen-devel] [PATCH v8 24/27] ARM: vITS: handle INVALL command

[Andre Przywara]

The INVALL command instructs an ITS to invalidate the configuration
data for all LPIs associated with a given redistributor (read: VCPU).
This is nasty to emulate exactly with our architecture, so we just
iterate over all mapped LPIs and filter for those from that particular
VCPU.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index f2789c5..9b5032b 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -480,6 +480,69 @@ out_unlock:
 return ret;
 }
 
+/*
+ * INVALL updates the per-LPI configuration status for every LPI mapped to
+ * a particular redistributor.
+ * We iterate over all mapped LPIs in our radix tree and update those.
+ */
+static int its_handle_invall(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+struct vcpu *vcpu;
+struct pending_irq *pirqs[16];
+uint64_t vlpi = 0;  /* 64-bit to catch overflows */
+unsigned int nr_lpis, i;
+unsigned long flags;
+int ret = 0;
+
+/*
+ * As this implementation walks over all mapped LPIs, it might take
+ * too long for a real guest, so we might want to revisit this
+ * implementation for DomUs.
+ * However this command is very rare, also we don't expect many
+ * LPIs to be actually mapped, so it's fine for Dom0 to use.
+ */
+ASSERT(is_hardware_domain(its->d));
+
+spin_lock(>its_lock);
+vcpu = get_vcpu_from_collection(its, collid);
+spin_unlock(>its_lock);
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+read_lock(>d->arch.vgic.pend_lpi_tree_lock);
+
+do
+{
+nr_lpis = radix_tree_gang_lookup(>d->arch.vgic.pend_lpi_tree,
+ (void **)pirqs, vlpi,
+ ARRAY_SIZE(pirqs));
+
+for ( i = 0; i < nr_lpis; i++ )
+{
+/* We only care about LPIs on our VCPU. */
+if ( pirqs[i]->lpi_vcpu_id != vcpu->vcpu_id )
+continue;
+
+vlpi = pirqs[i]->irq;
+/* If that fails for a single LPI, carry on to handle the rest. */
+ret = update_lpi_property(its->d, vlpi, pirqs[i]);
+if ( !ret )
+update_lpi_vgic_status(vcpu, pirqs[i], vlpi);
+}
+/*
+ * Loop over the next gang of pending_irqs until we reached the end of
+ * a (fully populated) tree or the lookup function returns less LPIs than
+ * it has been asked for.
+ */
+} while ( (++vlpi < its->d->arch.vgic.nr_lpis) &&
+  (nr_lpis == ARRAY_SIZE(pirqs)) );
+
+read_unlock(>d->arch.vgic.pend_lpi_tree_lock);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+return ret;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -822,6 +885,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_INV:
 ret = its_handle_inv(its, command);
 break;
+case GITS_CMD_INVALL:
+ret = its_handle_invall(its, command);
+break;
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, command);
 break;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 20/27] ARM: GICv3: handle unmapped LPIs

[Andre Przywara]

When LPIs get unmapped by a guest, they might still be in some LR of
some VCPU. Nevertheless we remove the corresponding pending_irq
(possibly freeing it), and detect this case (irq_to_pending() returns
NULL) when the LR gets cleaned up later.
However a *new* LPI may get mapped with the same number while the old
LPI is *still* in some LR. To avoid getting the wrong state, we mark
every newly mapped LPI as PRISTINE, which means: has never been in an
LR before. If we detect the LPI in an LR anyway, it must have been an
older one, which we can simply retire.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c | 17 -
 xen/arch/arm/vgic-v3-its.c |  5 +
 xen/include/asm-arm/vgic.h |  1 +
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index d752352..e8c3202 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -373,6 +373,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
 {
 ASSERT(!local_irq_is_enabled());
 
+clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status);
+
 gic_hw_ops->update_lr(lr, p, state);
 
 set_bit(GIC_IRQ_GUEST_VISIBLE, >status);
@@ -510,7 +512,17 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 }
 else if ( lr_val.state & GICH_LR_PENDING )
 {
-int q __attribute__ ((unused)) = 
test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+int q __attribute__ ((unused));
+
+if ( test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status) )
+{
+gic_hw_ops->clear_lr(i);
+clear_bit(i, _cpu(lr_mask));
+
+return;
+}
+
+q = test_and_clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
 #ifdef GIC_DEBUG
 if ( q )
 gdprintk(XENLOG_DEBUG, "trying to inject irq=%d into d%dv%d, when 
it is already pending in LR%d\n",
@@ -522,6 +534,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 gic_hw_ops->clear_lr(i);
 clear_bit(i, _cpu(lr_mask));
 
+if ( test_and_clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status) )
+return;
+
 if ( p->desc != NULL )
 clear_bit(_IRQ_INPROGRESS, >desc->status);
 clear_bit(GIC_IRQ_GUEST_VISIBLE, >status);
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index b7e61b2..0765810 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -618,6 +618,11 @@ static int its_handle_mapti(struct virt_its *its, uint64_t 
*cmdptr)
 goto out_remove_host_entry;
 
 pirq->lpi_vcpu_id = vcpu->vcpu_id;
+/*
+ * Mark this LPI as new, so any older (now unmapped) LPI in any LR
+ * can be easily recognised as such.
+ */
+set_bit(GIC_IRQ_GUEST_PRISTINE_LPI, pirq->status);
 
 /*
  * Now insert the pending_irq into the domain's LPI tree, so that
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 02732db..b1a7525 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -66,6 +66,7 @@ struct pending_irq
 #define GIC_IRQ_GUEST_VISIBLE  2
 #define GIC_IRQ_GUEST_ENABLED  3
 #define GIC_IRQ_GUEST_MIGRATING   4
+#define GIC_IRQ_GUEST_PRISTINE_LPI  5
 unsigned long status;
 struct irq_desc *desc; /* only set it the irq corresponds to a physical 
irq */
 unsigned int irq;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 16/27] ARM: vITS: handle INT command

[Andre Przywara]

The INT command sets a given LPI identified by a DeviceID/EventID pair
as pending and thus triggers it to be injected.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index e24ab60..eeb1306 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -342,6 +342,24 @@ static int its_handle_clear(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+static int its_handle_int(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct vcpu *vcpu;
+uint32_t vlpi;
+
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+if ( vlpi == INVALID_LPI )
+return -1;
+
+vgic_vcpu_inject_irq(vcpu, vlpi);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -374,6 +392,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_CLEAR:
 ret = its_handle_clear(its, command);
 break;
+case GITS_CMD_INT:
+ret = its_handle_int(its, command);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
 break;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 15/27] ARM: vITS: handle CLEAR command

[Andre Przywara]

This introduces the ITS command handler for the CLEAR command, which
clears the pending state of an LPI.
This removes a not-yet injected, but already queued IRQ from a VCPU.
As read_itte() is now eventually used, we add the static keyword.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 52 --
 1 file changed, 50 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 632ab84..e24ab60 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -227,8 +227,8 @@ static bool read_itte_locked(struct virt_its *its, uint32_t 
devid,
  * This function takes care of the locking by taking the its_lock itself, so
  * a caller shall not hold this. Before returning, the lock is dropped again.
  */
-bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
-   struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
+static bool read_itte(struct virt_its *its, uint32_t devid, uint32_t evid,
+  struct vcpu **vcpu_ptr, uint32_t *vlpi_ptr)
 {
 bool ret;
 
@@ -297,6 +297,51 @@ static uint64_t its_cmd_mask_field(uint64_t *its_cmd, 
unsigned int word,
 #define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
 #define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2, 8, 44) << 
8)
 
+/*
+ * CLEAR removes the pending state from an LPI. */
+static int its_handle_clear(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *p;
+struct vcpu *vcpu;
+uint32_t vlpi;
+unsigned long flags;
+
+/* Translate the DevID/EvID pair into a vCPU/vLPI pair. */
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+p = its->d->arch.vgic.handler->lpi_to_pending(its->d, vlpi);
+if ( !p )
+{
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return -1;
+}
+
+/*
+ * If the LPI is already visible on the guest, it is too late to
+ * clear the pending state. However this is a benign race that can
+ * happen on real hardware, too: If the LPI has already been forwarded
+ * to a CPU interface, a CLEAR request reaching the redistributor has
+ * no effect on that LPI anymore. Since LPIs are edge triggered and
+ * have no active state, we don't need to care about this here.
+ */
+if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+{
+/* Remove a pending, but not yet injected guest IRQ. */
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+list_del_init(>inflight);
+list_del_init(>lr_queue);
+}
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -326,6 +371,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 
 switch ( its_cmd_get_command(command) )
 {
+case GITS_CMD_CLEAR:
+ret = its_handle_clear(its, command);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
 break;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 03/27] ARM: GIC: Add checks for NULL pointer pending_irq's

[Andre Przywara]

For LPIs the struct pending_irq's are dynamically allocated and the
pointers will be stored in a radix tree. Since an LPI can be "unmapped"
at any time, teach the VGIC how to handle with irq_to_pending() returning
a NULL pointer.
We just do nothing in this case or clean up the LR if the virtual LPI
number was still in an LR.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c  | 37 -
 xen/arch/arm/vgic.c |  6 ++
 2 files changed, 38 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index dcb1783..62ae3b8 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -408,9 +408,15 @@ void gic_remove_from_queues(struct vcpu *v, unsigned int 
virtual_irq)
 spin_lock_irqsave(>arch.vgic.lock, flags);
 
 p = irq_to_pending(v, virtual_irq);
-
-if ( !list_empty(>lr_queue) )
-list_del_init(>lr_queue);
+/*
+ * If an LPIs has been removed meanwhile, it has been cleaned up
+ * already, so nothing to remove here.
+ */
+if ( p )
+{
+if ( !list_empty(>lr_queue) )
+list_del_init(>lr_queue);
+}
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
 }
 
@@ -418,6 +424,10 @@ void gic_raise_inflight_irq(struct vcpu *v, unsigned int 
virtual_irq)
 {
 struct pending_irq *n = irq_to_pending(v, virtual_irq);
 
+/* If an LPI has been removed meanwhile, there is nothing left to raise. */
+if ( !n )
+return;
+
 ASSERT(spin_is_locked(>arch.vgic.lock));
 
 if ( list_empty(>lr_queue) )
@@ -437,6 +447,11 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int 
virtual_irq,
 {
 int i;
 unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+struct pending_irq *p = irq_to_pending(v, virtual_irq);
+
+if ( !p )
+/* An unmapped LPI does not need to be raised. */
+return;
 
 ASSERT(spin_is_locked(>arch.vgic.lock));
 
@@ -445,12 +460,12 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int 
virtual_irq,
 i = find_first_zero_bit(_cpu(lr_mask), nr_lrs);
 if (i < nr_lrs) {
 set_bit(i, _cpu(lr_mask));
-gic_set_lr(i, irq_to_pending(v, virtual_irq), GICH_LR_PENDING);
+gic_set_lr(i, p, GICH_LR_PENDING);
 return;
 }
 }
 
-gic_add_to_lr_pending(v, irq_to_pending(v, virtual_irq));
+gic_add_to_lr_pending(v, p);
 }
 
 static void gic_update_one_lr(struct vcpu *v, int i)
@@ -464,7 +479,19 @@ static void gic_update_one_lr(struct vcpu *v, int i)
 
 gic_hw_ops->read_lr(i, _val);
 irq = lr_val.virq;
+
 p = irq_to_pending(v, irq);
+/* An LPI might have been unmapped, in which case we just clean up here. */
+if ( !p )
+{
+ASSERT(is_lpi(irq));
+
+gic_hw_ops->clear_lr(i);
+clear_bit(i, _cpu(lr_mask));
+
+return;
+}
+
 if ( lr_val.state & GICH_LR_ACTIVE )
 {
 set_bit(GIC_IRQ_GUEST_ACTIVE, >status);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index c953f13..b9fc837 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -473,6 +473,12 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int 
virq)
 spin_lock_irqsave(>arch.vgic.lock, flags);
 
 n = irq_to_pending(v, virq);
+/* If an LPI has been removed, there is nothing to inject here. */
+if ( !n )
+{
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return;
+}
 
 priority = vgic_get_virq_priority(v, virq);
 
-- 
2.8.2


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

[Xen-devel] [PATCH v8 25/27] ARM: vITS: increase mmio_count for each ITS

[Andre Przywara]

Increase the count of MMIO regions needed by one for each ITS Dom0 has
to emulate. We emulate the ITSes 1:1 from the hardware, so the number
is the number of host ITSes.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 15 +++
 xen/arch/arm/vgic-v3.c   |  3 +++
 xen/include/asm-arm/gic_v3_its.h |  7 +++
 3 files changed, 25 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 9b5032b..1622e53 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -83,6 +83,21 @@ struct vits_itte
 #define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
   (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
 
+unsigned int vgic_v3_its_count(const struct domain *d)
+{
+struct host_its *hw_its;
+unsigned int ret = 0;
+
+/* Only Dom0 can use emulated ITSes so far. */
+if ( !is_hardware_domain(d) )
+return 0;
+
+list_for_each_entry(hw_its, _its_list, entry)
+ret++;
+
+return ret;
+}
+
 int vgic_v3_its_init_domain(struct domain *d)
 {
 spin_lock_init(>arch.vgic.its_devices_lock);
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 33cd5f7..e8ed658 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1784,6 +1784,9 @@ int vgic_v3_init(struct domain *d, int *mmio_count)
 /* GICD region + number of Redistributors */
 *mmio_count = vgic_v3_rdist_count(d) + 1;
 
+/* one region per ITS */
+*mmio_count += vgic_v3_its_count(d);
+
 register_vgic_ops(d, _ops);
 
 return 0;
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index ee69e9b..ae79d5c 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -137,6 +137,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
 
 bool gicv3_its_host_has_its(void);
 
+unsigned int vgic_v3_its_count(const struct domain *d);
+
 void gicv3_do_LPI(unsigned int lpi);
 
 int gicv3_lpi_init_rdist(void __iomem * rdist_base);
@@ -193,6 +195,11 @@ static inline bool gicv3_its_host_has_its(void)
 return false;
 }
 
+static inline unsigned int vgic_v3_its_count(const struct domain *d)
+{
+return 0;
+}
+
 static inline void gicv3_do_LPI(unsigned int lpi)
 {
 /* We don't enable LPIs without an ITS. */
-- 
2.8.2


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

[Xen-devel] [PATCH v8 17/27] ARM: vITS: handle MAPC command

[Andre Przywara]

The MAPC command associates a given collection ID with a given
redistributor, thus mapping collections to VCPUs.
We just store the vcpu_id in the collection table for that.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index eeb1306..6e505cb 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -116,6 +116,21 @@ static paddr_t get_baser_phys_addr(uint64_t reg)
 #define COLL_TABLE_ENTRY_SIZE 2UL
 
 /* Must be called with the ITS lock held. */
+static int its_set_collection(struct virt_its *its, uint16_t collid,
+  uint16_t vcpu_id)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_coll);
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( collid >= its->max_collections )
+return -ENOENT;
+
+return vgic_access_guest_memory(its->d, addr + collid * sizeof(uint16_t),
+_id, sizeof(vcpu_id), true);
+}
+
+/* Must be called with the ITS lock held. */
 static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
  uint16_t collid)
 {
@@ -360,6 +375,29 @@ static int its_handle_int(struct virt_its *its, uint64_t 
*cmdptr)
 return 0;
 }
 
+static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t collid = its_cmd_get_collection(cmdptr);
+uint64_t rdbase = its_cmd_mask_field(cmdptr, 2, 16, 44);
+
+if ( collid >= its->max_collections )
+return -1;
+
+if ( rdbase >= its->d->max_vcpus )
+return -1;
+
+spin_lock(>its_lock);
+
+if ( its_cmd_get_validbit(cmdptr) )
+its_set_collection(its, collid, rdbase);
+else
+its_set_collection(its, collid, UNMAPPED_COLLECTION);
+
+spin_unlock(>its_lock);
+
+return 0;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -395,6 +433,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
+case GITS_CMD_MAPC:
+ret = its_handle_mapc(its, command);
+break;
 case GITS_CMD_SYNC:
 /* We handle ITS commands synchronously, so we ignore SYNC. */
 break;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 07/27] ARM: vGICv3: handle virtual LPI pending and property tables

[Andre Przywara]

Allow a guest to provide the address and size for the memory regions
it has reserved for the GICv3 pending and property tables.
We sanitise the various fields of the respective redistributor
registers.
The MMIO read and write accesses are protected by locks, to avoid any
changing of the property or pending table address while a redistributor
is live and also to protect the non-atomic vgic_reg64_extract() function
on the MMIO read side.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/vgic-v3.c   | 164 +++
 xen/include/asm-arm/domain.h |   5 ++
 2 files changed, 157 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index c059dbd..e15c875 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -233,12 +233,29 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 goto read_reserved;
 
 case VREG64(GICR_PROPBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+if ( !v->domain->arch.vgic.has_its )
+goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+vgic_lock(v);
+*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
+vgic_unlock(v);
+return 1;
 
 case VREG64(GICR_PENDBASER):
-/* LPI's not implemented */
-goto read_as_zero_64;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto read_as_zero_64;
+if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
+*r &= ~GICR_PENDBASER_PTZ;   /* WO, reads as 0 */
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return 1;
+}
 
 case 0x0080:
 goto read_reserved;
@@ -335,11 +352,95 @@ read_unknown:
 return 1;
 }
 
+static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
+int field_shift,
+uint64_t (*sanitise_fn)(uint64_t))
+{
+uint64_t field = (reg & field_mask) >> field_shift;
+
+field = sanitise_fn(field) << field_shift;
+
+return (reg & ~field_mask) | field;
+}
+
+/* We want to avoid outer shareable. */
+static uint64_t vgic_sanitise_shareability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_OuterShareable:
+return GIC_BASER_InnerShareable;
+default:
+return field;
+}
+}
+
+/* Avoid any inner non-cacheable mapping. */
+static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_CACHE_nCnB:
+case GIC_BASER_CACHE_nC:
+return GIC_BASER_CACHE_RaWb;
+default:
+return field;
+}
+}
+
+/* Non-cacheable or same-as-inner are OK. */
+static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
+{
+switch ( field )
+{
+case GIC_BASER_CACHE_SameAsInner:
+case GIC_BASER_CACHE_nC:
+return field;
+default:
+return GIC_BASER_CACHE_nC;
+}
+}
+
+static uint64_t sanitize_propbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
+  GICR_PROPBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
+  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PROPBASER_RES0_MASK;
+
+return reg;
+}
+
+static uint64_t sanitize_pendbaser(uint64_t reg)
+{
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
+  GICR_PENDBASER_SHAREABILITY_SHIFT,
+  vgic_sanitise_shareability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
+  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
+  vgic_sanitise_inner_cacheability);
+reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
+  GICR_PENDBASER_OUTER_CACHEABILITY_SHIFT,
+  vgic_sanitise_outer_cacheability);
+
+reg &= ~GICR_PENDBASER_RES0_MASK;
+
+return reg;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
 {
 struct hsr_dabt dabt = info->dabt;
+uint64_t 

[Xen-devel] [PATCH v8 00/27] arm64: Dom0 ITS emulation

[Andre Przywara]

Hi,

this is a reworked version of the second part of the ITS emulation series,
where the first part has been merged already.
It extends the concept of letting Xen deal with irq_to_pending()
potentially returning NULL, by making sure the retrieval and usage
of the pending_irq pointer is always happening under the VCPU VGIC lock
(patch 02 and 03). This allows us to free the memory for the pending_irqs
when a device gets unmapped.
Patch 20 contains a relatively easy solution to some LPI unmap/map corner
case (DISCARD;MAPTI sequence using the same virtual LPI number while the
VLPI is pending in some LR).
On top of these changes I addressed the remaining comments from v5 and v6.
For a detailed changelog see below.

Cheers,
Andre

--
This series adds support for emulation of an ARM GICv3 ITS interrupt
controller. For hardware which relies on the ITS to provide interrupts for
its peripherals this code is needed to get a machine booted into Dom0 at
all. ITS emulation for DomUs is only really useful with PCI passthrough,
which is not yet available for ARM. It is expected that this feature
will be co-developed with the ITS DomU code. However this code drop here
considered DomU emulation already, to keep later architectural changes
to a minimum.

This is technical preview version to allow early testing of the feature.
Things not (properly) addressed in this release:
- The MOVALL command is not emulated. In our case there is really nothing
to do here. We might need to revisit this in the future for DomU support.
- The INVALL command might need some rework to be more efficient. Currently
we iterate over all mapped LPIs, which might take a bit longer.
- Indirect tables are not supported. This affects both the host and the
virtual side.
- The command queue locking is currently suboptimal and should be made more
fine-grained in the future, if possible.
- We don't move the LPIs on the host to the pCPU where the target VCPU
is currently running on. Doing so would involve sending ITS commands to the
host. We should investigate whether this is feasible during scheduling.
- MOVI doesn't move pending IRQs.
- We need to properly investigate the possible interaction when devices get
removed. This requires to properly clean up and remove any associated
resources like pending or in-flight LPIs, for instance.

Some generic design principles:

* The current GIC code statically allocates structures for each supported
IRQ (both for the host and the guest), which due to the potentially
millions of LPI interrupts is not feasible to copy for the ITS.
So we refrain from introducing the ITS as a first class Xen interrupt
controller, also we don't hold struct irq_desc's or struct pending_irq's
for each possible LPI.
Fortunately LPIs are only interesting to guests, so we get away with
storing only the virtual IRQ number and the guest VCPU for each allocated
host LPI, which can be stashed into one uint64_t. This data is stored in
a two-level table, which is both memory efficient and quick to access.
We hook into the existing IRQ handling and VGIC code to avoid accessing
the normal structures, providing alternative methods for getting the
needed information (priority, is enabled?) for LPIs.
Whenever a guest maps a device, we allocate the maximum required number
of struct pending_irq's, so that any triggering LPI can find its data
structure. Upon the guest actually mapping the LPI, this pointer to the
corresponding pending_irq gets entered into a radix tree, so that it can
be quickly looked up.

* On the guest side we (later will) have to deal with malicious guests
trying to hog Xen with mapping requests for a lot of LPIs, for instance.
As the ITS actually uses system memory for storing status information,
we use this memory (which the guest has to provide) to naturally limit
a guest. Whenever we need information from any of the ITS tables, we
temporarily map them (which is cheap on arm64) and copy the required data.

* An obvious approach to handling some guest ITS commands would be to
propagate them to the host, for instance to map devices and LPIs and
to enable or disable LPIs.
However this (later with DomU support) will create an attack vector, as
a malicious guest could try to fill the host command queue with
propagated commands.
So we try to avoid this situation: Dom0 sending a device mapping (MAPD)
command is the only time we allow queuing commands to the host ITS command
queue, as this seems to be the only reliable way of getting the
required information at the moment. However at the same time we map all
events to LPIs already, also enable them. This avoids sending commands
later at runtime, as we can deal with mappings and LPI enabling/disabling
internally.

To accomodate the tech preview nature of this feature at the moment, there
is a Kconfig option to enable it. Also it is supported on arm64 only, which
will most likely not change in the future.
This leads to some hideous constructs like an #ifdef'ed 

[Xen-devel] [PATCH v8 27/27] ARM: vITS: create ITS subnodes for Dom0 DT

[Andre Przywara]

Dom0 expects all ITSes in the system to be propagated to be able to
use MSIs.
Create Dom0 DT nodes for each hardware ITS, keeping the register frame
address the same, as the doorbell address that the Dom0 drivers program
into the BARs has to match the hardware.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 73 
 xen/arch/arm/gic-v3.c|  4 ++-
 xen/include/asm-arm/gic_v3_its.h | 12 +++
 3 files changed, 88 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 1a08d43..1fb06ca 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -919,6 +920,78 @@ int gicv3_lpi_change_vcpu(struct domain *d, paddr_t 
vdoorbell,
 return 0;
 }
 
+/*
+ * Create the respective guest DT nodes from a list of host ITSes.
+ * This copies the reg property, so the guest sees the ITS at the same address
+ * as the host.
+ */
+int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+  const struct dt_device_node *gic,
+  void *fdt)
+{
+uint32_t len;
+int res;
+const void *prop = NULL;
+const struct dt_device_node *its = NULL;
+const struct host_its *its_data;
+
+if ( list_empty(_its_list) )
+return 0;
+
+/* The sub-nodes require the ranges property */
+prop = dt_get_property(gic, "ranges", );
+if ( !prop )
+{
+printk(XENLOG_ERR "Can't find ranges property for the gic node\n");
+return -FDT_ERR_XEN(ENOENT);
+}
+
+res = fdt_property(fdt, "ranges", prop, len);
+if ( res )
+return res;
+
+list_for_each_entry(its_data, _its_list, entry)
+{
+its = its_data->dt_node;
+
+res = fdt_begin_node(fdt, its->name);
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,gic-v3-its");
+if ( res )
+return res;
+
+res = fdt_property(fdt, "msi-controller", NULL, 0);
+if ( res )
+return res;
+
+if ( its->phandle )
+{
+res = fdt_property_cell(fdt, "phandle", its->phandle);
+if ( res )
+return res;
+}
+
+/* Use the same reg regions as the ITS node in host DTB. */
+prop = dt_get_property(its, "reg", );
+if ( !prop )
+{
+printk(XENLOG_ERR "GICv3: Can't find ITS reg property.\n");
+res = -FDT_ERR_XEN(ENOENT);
+return res;
+}
+
+res = fdt_property(fdt, "reg", prop, len);
+if ( res )
+return res;
+
+fdt_end_node(fdt);
+}
+
+return res;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index d539d6c..c927306 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1172,8 +1172,10 @@ static int gicv3_make_hwdom_dt_node(const struct domain 
*d,
 
 res = fdt_property(fdt, "reg", new_cells, len);
 xfree(new_cells);
+if ( res )
+return res;
 
-return res;
+return gicv3_its_make_hwdom_dt_nodes(d, gic, fdt);
 }
 
 static const hw_irq_controller gicv3_host_irq_type = {
diff --git a/xen/include/asm-arm/gic_v3_its.h b/xen/include/asm-arm/gic_v3_its.h
index dbae6ee..d2a3e53 100644
--- a/xen/include/asm-arm/gic_v3_its.h
+++ b/xen/include/asm-arm/gic_v3_its.h
@@ -162,6 +162,11 @@ void vgic_v3_its_free_domain(struct domain *d);
 int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
 unsigned int devid_bits, unsigned int evid_bits);
 
+/* Create the appropriate DT nodes for a hardware domain. */
+int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+  const struct dt_device_node *gic,
+  void *fdt);
+
 /*
  * Map a device on the host by allocating an ITT on the host (ITS).
  * "nr_event" specifies how many events (interrupts) this device will need.
@@ -245,6 +250,13 @@ static inline void vgic_v3_its_free_domain(struct domain 
*d)
 {
 }
 
+static inline int gicv3_its_make_hwdom_dt_nodes(const struct domain *d,
+const struct dt_device_node 
*gic,
+void *fdt)
+{
+return 0;
+}
+
 #endif /* CONFIG_HAS_ITS */
 
 #endif
-- 
2.8.2


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

[Xen-devel] [PATCH v8 10/27] ARM: GIC: export vgic_init_pending_irq()

[Andre Przywara]

For LPIs we later want to dynamically allocate struct pending_irqs.
Let's export the vgic_init_pending_irq() to be able to reuse it.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic.c| 2 +-
 xen/include/asm-arm/vgic.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index e385b43..c8fe89c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -61,7 +61,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned 
int irq)
 return vgic_get_rank(v, rank);
 }
 
-static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
+void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
 {
 INIT_LIST_HEAD(>inflight);
 INIT_LIST_HEAD(>lr_queue);
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 6b17802..e2111a5 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -302,6 +302,7 @@ extern struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
unsigned int virq);
 extern void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq);
 extern void vgic_vcpu_inject_spi(struct domain *d, unsigned int virq);
 extern void vgic_clear_pending_irqs(struct vcpu *v);
+extern void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq);
 extern struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq);
 extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int irq);
 extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n, 
int s);
-- 
2.8.2


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

[Xen-devel] [PATCH v8 04/27] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Andre Przywara]

For the same reason that allocating a struct irq_desc for each
possible LPI is not an option, having a struct pending_irq for each LPI
is also not feasible. We only care about mapped LPIs, so we can get away
with having struct pending_irq's only for them.
Maintain a radix tree per domain where we drop the pointer to the
respective pending_irq. The index used is the virtual LPI number.
The memory for the actual structures has been allocated already per
device at device mapping time.
Teach the existing VGIC functions to find the right pointer when being
given a virtual LPI number.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v2.c   |  8 
 xen/arch/arm/vgic-v3.c   | 23 +++
 xen/arch/arm/vgic.c  |  2 ++
 xen/include/asm-arm/domain.h |  2 ++
 xen/include/asm-arm/vgic.h   |  2 ++
 5 files changed, 37 insertions(+)

diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
index dc9f95b..0587569 100644
--- a/xen/arch/arm/vgic-v2.c
+++ b/xen/arch/arm/vgic-v2.c
@@ -702,10 +702,18 @@ static void vgic_v2_domain_free(struct domain *d)
 /* Nothing to be cleanup for this driver */
 }
 
+static struct pending_irq *vgic_v2_lpi_to_pending(struct domain *d,
+  unsigned int vlpi)
+{
+/* Dummy function, no LPIs on a VGICv2. */
+BUG();
+}
+
 static const struct vgic_ops vgic_v2_ops = {
 .vcpu_init   = vgic_v2_vcpu_init,
 .domain_init = vgic_v2_domain_init,
 .domain_free = vgic_v2_domain_free,
+.lpi_to_pending = vgic_v2_lpi_to_pending,
 .max_vcpus = 8,
 };
 
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index ebcca22..f462610 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1454,6 +1454,9 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.nr_regions = rdist_count;
 d->arch.vgic.rdist_regions = rdist_regions;
 
+rwlock_init(>arch.vgic.pend_lpi_tree_lock);
+radix_tree_init(>arch.vgic.pend_lpi_tree);
+
 /*
  * Domain 0 gets the hardware address.
  * Guests get the virtual platform layout.
@@ -1533,14 +1536,34 @@ static int vgic_v3_domain_init(struct domain *d)
 static void vgic_v3_domain_free(struct domain *d)
 {
 vgic_v3_its_free_domain(d);
+radix_tree_destroy(>arch.vgic.pend_lpi_tree, NULL);
 xfree(d->arch.vgic.rdist_regions);
 }
 
+/*
+ * Looks up a virtual LPI number in our tree of mapped LPIs. This will return
+ * the corresponding struct pending_irq, which we also use to store the
+ * enabled and pending bit plus the priority.
+ * Returns NULL if an LPI cannot be found (or no LPIs are supported).
+ */
+static struct pending_irq *vgic_v3_lpi_to_pending(struct domain *d,
+  unsigned int lpi)
+{
+struct pending_irq *pirq;
+
+read_lock(>arch.vgic.pend_lpi_tree_lock);
+pirq = radix_tree_lookup(>arch.vgic.pend_lpi_tree, lpi);
+read_unlock(>arch.vgic.pend_lpi_tree_lock);
+
+return pirq;
+}
+
 static const struct vgic_ops v3_ops = {
 .vcpu_init   = vgic_v3_vcpu_init,
 .domain_init = vgic_v3_domain_init,
 .domain_free = vgic_v3_domain_free,
 .emulate_reg  = vgic_v3_emulate_reg,
+.lpi_to_pending = vgic_v3_lpi_to_pending,
 /*
  * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
  * that can be supported is up to 4096(==256*16) in theory.
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index b9fc837..c2bfdb1 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -439,6 +439,8 @@ struct pending_irq *irq_to_pending(struct vcpu *v, unsigned 
int irq)
  * are used for SPIs; the rests are used for per cpu irqs */
 if ( irq < 32 )
 n = >arch.vgic.pending_irqs[irq];
+else if ( is_lpi(irq) )
+n = v->domain->arch.vgic.handler->lpi_to_pending(v->domain, irq);
 else
 n = >domain->arch.vgic.pending_irqs[irq - 32];
 return n;
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 7c3829d..3d8e84c 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,8 @@ struct arch_domain
 uint32_t rdist_stride;  /* Re-Distributor stride */
 struct rb_root its_devices; /* Devices mapped to an ITS */
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
+struct radix_tree_root pend_lpi_tree; /* Stores struct pending_irq's */
+rwlock_t pend_lpi_tree_lock;/* Protects the pend_lpi_tree */
 unsigned int intid_bits;
 #endif
 } vgic;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index df75064..c9075a9 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -134,6 +134,8 @@ struct vgic_ops {
 void (*domain_free)(struct domain *d);
 /* vGIC sysreg/cpregs emulate */
 bool (*emulate_reg)(struct cpu_user_regs *regs, union hsr hsr);
+/* 

[Xen-devel] [PATCH v8 12/27] ARM: vGIC: advertise LPI support

[Andre Przywara]

To let a guest know about the availability of virtual LPIs, set the
respective bits in the virtual GIC registers and let a guest control
the LPI enable bit.
Only report the LPI capability if the host has initialized at least
one ITS.
This removes a "TBD" comment, as we now populate the processor number
in the GICR_TYPE register.
Advertise 24 bits worth of LPIs to the guest.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3.c | 67 ++
 1 file changed, 62 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 849a6f3..33cd5f7 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -170,8 +170,19 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* We have not implemented LPI's, read zero */
-goto read_as_zero_32;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto read_as_zero_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+*r = vgic_reg32_extract(!!(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED),
+info);
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+return 1;
+}
 
 case VREG32(GICR_IIDR):
 if ( dabt.size != DABT_WORD ) goto bad_width;
@@ -183,16 +194,20 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 uint64_t typer, aff;
 
 if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
-/* TBD: Update processor id in [23:8] when ITS support is added */
 aff = (MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 3) << 56 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 2) << 48 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 1) << 40 |
MPIDR_AFFINITY_LEVEL(v->arch.vmpidr, 0) << 32);
 typer = aff;
+/* We use the VCPU ID as the redistributor ID in bits[23:8] */
+typer |= (v->vcpu_id & 0x) << 8;
 
 if ( v->arch.vgic.flags & VGIC_V3_RDIST_LAST )
 typer |= GICR_TYPER_LAST;
 
+if ( v->domain->arch.vgic.has_its )
+typer |= GICR_TYPER_PLPIS;
+
 *r = vgic_reg64_extract(typer, info);
 
 return 1;
@@ -426,6 +441,25 @@ static uint64_t sanitize_pendbaser(uint64_t reg)
 return reg;
 }
 
+static void vgic_vcpu_enable_lpis(struct vcpu *v)
+{
+uint64_t reg = v->domain->arch.vgic.rdist_propbase;
+unsigned int nr_lpis = BIT((reg & 0x1f) + 1);
+
+if ( nr_lpis < LPI_OFFSET )
+nr_lpis = 0;
+else
+nr_lpis -= LPI_OFFSET;
+
+if ( !v->domain->arch.vgic.rdists_enabled )
+{
+v->domain->arch.vgic.nr_lpis = nr_lpis;
+v->domain->arch.vgic.rdists_enabled = true;
+}
+
+v->arch.vgic.flags |= VGIC_V3_LPIS_ENABLED;
+}
+
 static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, mmio_info_t *info,
   uint32_t gicr_reg,
   register_t r)
@@ -436,8 +470,26 @@ static int __vgic_v3_rdistr_rd_mmio_write(struct vcpu *v, 
mmio_info_t *info,
 switch ( gicr_reg )
 {
 case VREG32(GICR_CTLR):
-/* LPI's not implemented */
-goto write_ignore_32;
+{
+unsigned long flags;
+
+if ( !v->domain->arch.vgic.has_its )
+goto write_ignore_32;
+if ( dabt.size != DABT_WORD ) goto bad_width;
+
+vgic_lock(v);   /* protects rdists_enabled */
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+/* LPIs can only be enabled once, but never disabled again. */
+if ( (r & GICR_CTLR_ENABLE_LPIS) &&
+ !(v->arch.vgic.flags & VGIC_V3_LPIS_ENABLED) )
+vgic_vcpu_enable_lpis(v);
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+vgic_unlock(v);
+
+return 1;
+}
 
 case VREG32(GICR_IIDR):
 /* RO */
@@ -1058,6 +1110,11 @@ static int vgic_v3_distr_mmio_read(struct vcpu *v, 
mmio_info_t *info,
 typer = ((ncpus - 1) << GICD_TYPE_CPUS_SHIFT |
  DIV_ROUND_UP(v->domain->arch.vgic.nr_spis, 32));
 
+if ( v->domain->arch.vgic.has_its )
+{
+typer |= GICD_TYPE_LPIS;
+irq_bits = v->domain->arch.vgic.intid_bits;
+}
 typer |= (irq_bits - 1) << GICD_TYPE_ID_BITS_SHIFT;
 
 *r = vgic_reg32_extract(typer, info);
-- 
2.8.2


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

[Xen-devel] [PATCH v8 23/27] ARM: vITS: handle INV command

[Andre Przywara]

The INV command instructs the ITS to update the configuration data for
a given LPI by re-reading its entry from the property table.
We don't need to care so much about the priority value, but enabling
or disabling an LPI has some effect: We remove or push virtual LPIs
to their VCPUs, also check the virtual pending bit if an LPI gets enabled.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 09cb3af..f2789c5 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -418,6 +418,68 @@ static int update_lpi_property(struct domain *d, uint32_t 
vlpi,
 return 0;
 }
 
+/*
+ * Checks whether an LPI that got enabled or disabled needs to change
+ * something in the VGIC (added or removed from the LR or queues).
+ * Must be called with the VCPU VGIC lock held.
+ */
+static void update_lpi_vgic_status(struct vcpu *v, struct pending_irq *p,
+   uint32_t vlpi)
+{
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+if ( test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+{
+if ( !list_empty(>inflight) &&
+ !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
+gic_raise_guest_irq(v, vlpi, p->lpi_priority);
+}
+else
+{
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+list_del_init(>lr_queue);
+}
+}
+
+static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
+{
+struct domain *d = its->d;
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+struct pending_irq *p;
+unsigned long flags;
+struct vcpu *vcpu;
+uint32_t vlpi;
+int ret = -1;
+
+/* Translate the event into a vCPU/vLPI pair. */
+if ( !read_itte(its, devid, eventid, , ) )
+return -1;
+
+if ( vlpi == INVALID_LPI )
+return -1;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);
+
+p = d->arch.vgic.handler->lpi_to_pending(d, vlpi);
+if ( !p )
+goto out_unlock;
+
+/* Read the property table and update our cached status. */
+if ( update_lpi_property(d, vlpi, p) )
+goto out_unlock;
+
+/* Check whether the LPI needs to go on a VCPU. */
+update_lpi_vgic_status(vcpu, p, vlpi);
+
+ret = 0;
+
+out_unlock:
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+return ret;
+}
+
 static int its_handle_mapc(struct virt_its *its, uint64_t *cmdptr)
 {
 uint32_t collid = its_cmd_get_collection(cmdptr);
@@ -757,6 +819,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
+case GITS_CMD_INV:
+ret = its_handle_inv(its, command);
+break;
 case GITS_CMD_MAPC:
 ret = its_handle_mapc(its, command);
 break;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 22/27] ARM: vITS: handle DISCARD command

[Andre Przywara]

The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index be9de08..09cb3af 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -276,9 +276,9 @@ static bool read_itte(struct virt_its *its, uint32_t devid, 
uint32_t evid,
  * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
  * Must be called with the ITS lock held.
  */
-bool write_itte_locked(struct virt_its *its, uint32_t devid,
-   uint32_t evid, uint32_t collid, uint32_t vlpi,
-   struct vcpu **vcpu_ptr)
+static bool write_itte_locked(struct virt_its *its, uint32_t devid,
+  uint32_t evid, uint32_t collid, uint32_t vlpi,
+  struct vcpu **vcpu_ptr)
 {
 paddr_t addr;
 struct vits_itte itte;
@@ -698,6 +698,27 @@ out_unlock:
 return ret;
 }
 
+static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+int ret;
+
+spin_lock(>its_lock);
+
+/* Remove from the radix tree and remove the host entry. */
+ret = its_discard_event(its, devid, eventid);
+
+/* Remove from the guest's ITTE. */
+if ( ret || write_itte_locked(its, devid, eventid,
+  UNMAPPED_COLLECTION, INVALID_LPI, NULL) )
+ret = -1;
+
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
 
@@ -730,6 +751,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_CLEAR:
 ret = its_handle_clear(its, command);
 break;
+case GITS_CMD_DISCARD:
+ret = its_handle_discard(its, command);
+break;
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;
-- 
2.8.2


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

[Xen-devel] [PATCH v8 02/27] ARM: VGIC: move irq_to_pending() calls under the VGIC VCPU lock

[Andre Przywara]

So far irq_to_pending() is just a convenience function to lookup
in statically allocated arrays. This will change with LPIs, which are
more dynamic.
So move the irq_to_pending() call under the VGIC VCPU lock, so we
only use this pointer while holding the lock.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic.c  | 5 -
 xen/arch/arm/vgic.c | 8 +---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index da19130..dcb1783 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -402,10 +402,13 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, 
struct pending_irq *n)
 
 void gic_remove_from_queues(struct vcpu *v, unsigned int virtual_irq)
 {
-struct pending_irq *p = irq_to_pending(v, virtual_irq);
+struct pending_irq *p;
 unsigned long flags;
 
 spin_lock_irqsave(>arch.vgic.lock, flags);
+
+p = irq_to_pending(v, virtual_irq);
+
 if ( !list_empty(>lr_queue) )
 list_del_init(>lr_queue);
 spin_unlock_irqrestore(>arch.vgic.lock, flags);
diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 83569b0..c953f13 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -466,14 +466,16 @@ void vgic_clear_pending_irqs(struct vcpu *v)
 void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
 {
 uint8_t priority;
-struct pending_irq *iter, *n = irq_to_pending(v, virq);
+struct pending_irq *iter, *n;
 unsigned long flags;
 bool running;
 
-priority = vgic_get_virq_priority(v, virq);
-
 spin_lock_irqsave(>arch.vgic.lock, flags);
 
+n = irq_to_pending(v, virq);
+
+priority = vgic_get_virq_priority(v, virq);
+
 /* vcpu offline */
 if ( test_bit(_VPF_down, >pause_flags) )
 {
-- 
2.8.2


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

[Xen-devel] [PATCH v8 18/27] ARM: vITS: handle MAPD command

[Andre Przywara]

The MAPD command maps a device by associating a memory region for
storing ITEs with a certain device ID. Since it features a valid bit,
MAPD also covers the "unmap" functionality, which we also cover here.
We store the given guest physical address in the device table, and, if
this command comes from Dom0, tell the host ITS driver about this new
mapping, so it can issue the corresponding host MAPD command and create
the required tables. We take care of rolling back actions should one
step fail.
Upon unmapping a device we make sure we clean up all associated
resources and release the memory again.
We use our existing guest memory access function to find the right ITT
entry and store the mapping there (in guest memory).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c|  60 +
 xen/arch/arm/gic-v3-lpi.c|  18 +
 xen/arch/arm/vgic-v3-its.c   | 137 +++
 xen/include/asm-arm/gic_v3_its.h |   6 ++
 4 files changed, 221 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index aebc257..900c9d1 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -800,6 +800,66 @@ out:
 return ret;
 }
 
+/* Must be called with the its_device_lock held. */
+static struct its_device *get_its_device(struct domain *d, paddr_t vdoorbell,
+  uint32_t vdevid)
+{
+struct rb_node *node = d->arch.vgic.its_devices.rb_node;
+struct its_device *dev;
+
+ASSERT(spin_is_locked(>arch.vgic.its_devices_lock));
+
+while (node)
+{
+int cmp;
+
+dev = rb_entry(node, struct its_device, rbnode);
+cmp = compare_its_guest_devices(dev, vdoorbell, vdevid);
+
+if ( !cmp )
+return dev;
+
+if ( cmp > 0 )
+node = node->rb_left;
+else
+node = node->rb_right;
+}
+
+return NULL;
+}
+
+static uint32_t get_host_lpi(struct its_device *dev, uint32_t eventid)
+{
+uint32_t host_lpi = INVALID_LPI;
+
+if ( dev && (eventid < dev->eventids) )
+host_lpi = dev->host_lpi_blocks[eventid / LPI_BLOCK] +
+   (eventid % LPI_BLOCK);
+
+return host_lpi;
+}
+
+int gicv3_remove_guest_event(struct domain *d, paddr_t vdoorbell_address,
+ uint32_t vdevid, uint32_t veventid)
+{
+struct its_device *dev;
+uint32_t host_lpi = INVALID_LPI;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, vdoorbell_address, vdevid);
+if ( dev && veventid <= dev->eventids )
+host_lpi = get_host_lpi(dev, veventid);
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( host_lpi == INVALID_LPI )
+return -EINVAL;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
+INVALID_VCPU_ID, INVALID_LPI);
+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 44f6315..d427539 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -207,6 +207,24 @@ out:
 irq_exit();
 }
 
+void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
+ unsigned int vcpu_id, uint32_t virt_lpi)
+{
+union host_lpi *hlpip, hlpi;
+
+ASSERT(host_lpi >= LPI_OFFSET);
+
+host_lpi -= LPI_OFFSET;
+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+hlpi.virt_lpi = virt_lpi;
+hlpi.dom_id = domain_id;
+hlpi.vcpu_id = vcpu_id;
+
+write_u64_atomic(>data, hlpi.data);
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 6e505cb..104017e 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
 struct domain *d;
+paddr_t doorbell_address;
 unsigned int devid_bits;
 unsigned int evid_bits;
 spinlock_t vcmd_lock;   /* Protects the virtual command buffer, which 
*/
@@ -166,6 +167,20 @@ static struct vcpu *get_vcpu_from_collection(struct 
virt_its *its,
 #define DEV_TABLE_ENTRY(addr, bits) \
 (((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
 
+/* Set the address of an ITT for a given device ID. */
+static int its_set_itt_address(struct virt_its *its, uint32_t devid,
+   paddr_t itt_address, uint32_t nr_bits)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_dev);
+uint64_t itt_entry = DEV_TABLE_ENTRY(itt_address, nr_bits);
+
+if ( devid >= its->max_devices )
+return -ENOENT;
+
+return vgic_access_guest_memory(its->d, addr + devid * sizeof(uint64_t),
+_entry, 

[Xen-devel] [PATCH v8 09/27] ARM: vGICv3: re-use vgic_reg64_check_access

[Andre Przywara]

vgic_reg64_check_access() checks for a valid access width of a 64-bit
MMIO register, which is useful beyond the current GICv3 emulation only.
Move this function to the vgic-emul.h to be easily reusable.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/vgic-v3.c  | 9 -
 xen/include/asm-arm/vgic-emul.h | 9 +
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index e15c875..849a6f3 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -161,15 +161,6 @@ static void vgic_store_irouter(struct domain *d, struct 
vgic_irq_rank *rank,
 }
 }
 
-static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
-{
-/*
- * 64 bits registers can be accessible using 32-bit and 64-bit unless
- * stated otherwise (See 8.1.3 ARM IHI 0069A).
- */
-return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
-}
-
 static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu *v, mmio_info_t *info,
  uint32_t gicr_reg,
  register_t *r)
diff --git a/xen/include/asm-arm/vgic-emul.h b/xen/include/asm-arm/vgic-emul.h
index 184a1f0..e52fbaa 100644
--- a/xen/include/asm-arm/vgic-emul.h
+++ b/xen/include/asm-arm/vgic-emul.h
@@ -12,6 +12,15 @@
 #define VRANGE32(start, end) start ... end + 3
 #define VRANGE64(start, end) start ... end + 7
 
+/*
+ * 64 bits registers can be accessible using 32-bit and 64-bit unless
+ * stated otherwise (See 8.1.3 ARM IHI 0069A).
+ */
+static inline bool vgic_reg64_check_access(struct hsr_dabt dabt)
+{
+return ( dabt.size == DABT_DOUBLE_WORD || dabt.size == DABT_WORD );
+}
+
 #endif /* __ASM_ARM_VGIC_EMUL_H__ */
 
 /*
-- 
2.8.2


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

[Xen-devel] [PATCH v8 05/27] ARM: GICv3: forward pending LPIs to guests

[Andre Przywara]

Upon receiving an LPI on the host, we need to find the right VCPU and
virtual IRQ number to get this IRQ injected.
Iterate our two-level LPI table to find this information quickly when
the host takes an LPI. Call the existing injection function to let the
GIC emulation deal with this interrupt.
Also we enhance struct pending_irq to cache the pending bit and the
priority information for LPIs. Reading the information from there is
faster than accessing the property table from guest memory. Also it
use some padding area, so does not require more memory.
This introduces a do_LPI() as a hardware gic_ops and a function to
retrieve the (cached) priority value of an LPI and a vgic_ops.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v2.c|  7 
 xen/arch/arm/gic-v3-lpi.c| 71 
 xen/arch/arm/gic-v3.c|  1 +
 xen/arch/arm/gic.c   |  8 -
 xen/arch/arm/vgic-v2.c   |  7 
 xen/arch/arm/vgic-v3.c   | 12 +++
 xen/arch/arm/vgic.c  |  7 +++-
 xen/include/asm-arm/domain.h |  3 +-
 xen/include/asm-arm/gic.h|  2 ++
 xen/include/asm-arm/gic_v3_its.h |  8 +
 xen/include/asm-arm/vgic.h   |  2 ++
 11 files changed, 125 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 270a136..ffbe47c 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1217,6 +1217,12 @@ static int __init gicv2_init(void)
 return 0;
 }
 
+static void gicv2_do_LPI(unsigned int lpi)
+{
+/* No LPIs in a GICv2 */
+BUG();
+}
+
 const static struct gic_hw_operations gicv2_ops = {
 .info= _info,
 .init= gicv2_init,
@@ -1244,6 +1250,7 @@ const static struct gic_hw_operations gicv2_ops = {
 .make_hwdom_madt = gicv2_make_hwdom_madt,
 .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
 .iomem_deny_access   = gicv2_iomem_deny_access,
+.do_LPI  = gicv2_do_LPI,
 };
 
 /* Set up the GIC */
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index 292f2d0..44f6315 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -136,6 +136,77 @@ uint64_t gicv3_get_redist_address(unsigned int cpu, bool 
use_pta)
 return per_cpu(lpi_redist, cpu).redist_id << 16;
 }
 
+/*
+ * Handle incoming LPIs, which are a bit special, because they are potentially
+ * numerous and also only get injected into guests. Treat them specially here,
+ * by just looking up their target vCPU and virtual LPI number and hand it
+ * over to the injection function.
+ * Please note that LPIs are edge-triggered only, also have no active state,
+ * so spurious interrupts on the host side are no issue (we can just ignore
+ * them).
+ * Also a guest cannot expect that firing interrupts that haven't been
+ * fully configured yet will reach the CPU, so we don't need to care about
+ * this special case.
+ */
+void gicv3_do_LPI(unsigned int lpi)
+{
+struct domain *d;
+union host_lpi *hlpip, hlpi;
+struct vcpu *vcpu;
+
+irq_enter();
+
+/* EOI the LPI already. */
+WRITE_SYSREG32(lpi, ICC_EOIR1_EL1);
+
+/* Find out if a guest mapped something to this physical LPI. */
+hlpip = gic_get_host_lpi(lpi);
+if ( !hlpip )
+goto out;
+
+hlpi.data = read_u64_atomic(>data);
+
+/*
+ * Unmapped events are marked with an invalid LPI ID. We can safely
+ * ignore them, as they have no further state and no-one can expect
+ * to see them if they have not been mapped.
+ */
+if ( hlpi.virt_lpi == INVALID_LPI )
+goto out;
+
+d = rcu_lock_domain_by_id(hlpi.dom_id);
+if ( !d )
+goto out;
+
+/* Make sure we don't step beyond the vcpu array. */
+if ( hlpi.vcpu_id >= d->max_vcpus )
+{
+rcu_unlock_domain(d);
+goto out;
+}
+
+vcpu = d->vcpu[hlpi.vcpu_id];
+
+/* Check if the VCPU is ready to receive LPIs. */
+if ( vcpu->arch.vgic.flags & VGIC_V3_LPIS_ENABLED )
+/*
+ * TODO: Investigate what to do here for potential interrupt storms.
+ * As we keep all host LPIs enabled, for disabling LPIs we would need
+ * to queue a ITS host command, which we avoid so far during a guest's
+ * runtime. Also re-enabling would trigger a host command upon the
+ * guest sending a command, which could be an attack vector for
+ * hogging the host command queue.
+ * See the thread around here for some background:
+ * https://lists.xen.org/archives/html/xen-devel/2016-12/msg3.html
+ */
+vgic_vcpu_inject_irq(vcpu, hlpi.virt_lpi);
+
+rcu_unlock_domain(d);
+
+out:
+irq_exit();
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 29c8964..8140c5f 100644
--- a/xen/arch/arm/gic-v3.c
+++ 

[Xen-devel] [PATCH v8 13/27] ARM: vITS: add command handling stub and MMIO emulation

[Andre Przywara]

Emulate the memory mapped ITS registers and provide a stub to introduce
the ITS command handling framework (but without actually emulating any
commands at this time).
This fixes a misnomer in our virtual ITS structure, where the spec is
confusingly using ID_bits in GITS_TYPER to denote the number of event IDs
(in contrast to GICD_TYPER, where it means number of LPIs).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 523 ++-
 xen/include/asm-arm/gic_v3_its.h |   3 +
 2 files changed, 525 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 065ffe2..a60f9b2 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -19,6 +19,16 @@
  * along with this program; If not, see .
  */
 
+/*
+ * Locking order:
+ *
+ * its->vcmd_lock(protects the command queue)
+ * its->its_lock (protects the translation tables)
+ * d->its_devices_lock   (protects the device RB tree)
+ * v->vgic.lock  (protects the struct pending_irq)
+ * d->pend_lpi_tree_lock (protects the radix tree)
+ */
+
 #include 
 #include 
 #include 
@@ -43,7 +53,7 @@
 struct virt_its {
 struct domain *d;
 unsigned int devid_bits;
-unsigned int intid_bits;
+unsigned int evid_bits;
 spinlock_t vcmd_lock;   /* Protects the virtual command buffer, which 
*/
 uint64_t cwriter;   /* consists of CWRITER and CREADR and those   
*/
 uint64_t creadr;/* shadow variables cwriter and creadr. */
@@ -53,6 +63,7 @@ struct virt_its {
 uint64_t baser_dev, baser_coll; /* BASER0 and BASER1 for the guest */
 unsigned int max_collections;
 unsigned int max_devices;
+/* changing "enabled" requires to hold *both* the vcmd_lock and its_lock */
 bool enabled;
 };
 
@@ -67,6 +78,9 @@ struct vits_itte
 uint16_t pad;
 };
 
+#define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
+  (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
+
 int vgic_v3_its_init_domain(struct domain *d)
 {
 spin_lock_init(>arch.vgic.its_devices_lock);
@@ -80,6 +94,513 @@ void vgic_v3_its_free_domain(struct domain *d)
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }
 
+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
+   unsigned int shift, unsigned int size)
+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
+#define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2, 8, 44) << 
8)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+#define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))
+
+/*
+ * Must be called with the vcmd_lock held.
+ * TODO: Investigate whether we can be smarter here and don't need to hold
+ * the lock all of the time.
+ */
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
+{
+paddr_t addr = its->cbaser & GENMASK(51, 12);
+uint64_t command[4];
+
+ASSERT(spin_is_locked(>vcmd_lock));
+
+if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;
+
+while ( its->creadr != its->cwriter )
+{
+int ret;
+
+ret = vgic_access_guest_memory(d, addr + its->creadr,
+   command, sizeof(command), false);
+if ( ret )
+return ret;
+
+switch ( its_cmd_get_command(command) )
+{
+case GITS_CMD_SYNC:
+/* We handle ITS commands synchronously, so we ignore SYNC. */
+break;
+default:
+gdprintk(XENLOG_WARNING, "ITS: unhandled ITS command %lu\n",
+ its_cmd_get_command(command));
+break;
+}
+
+write_u64_atomic(>creadr, (its->creadr + ITS_CMD_SIZE) %
+ ITS_CMD_BUFFER_SIZE(its->cbaser));
+
+if ( ret )
+gdprintk(XENLOG_WARNING,
+ "ITS: ITS command error %d while handling command %lu\n",
+ ret, its_cmd_get_command(command));
+}
+
+return 0;
+}
+

[Xen-devel] [PATCH v8 08/27] ARM: introduce vgic_access_guest_memory()

[Andre Przywara]

From: Vijaya Kumar K 

This function allows to copy a chunk of data from and to guest physical
memory. It looks up the associated page from the guest's p2m tree
and maps this page temporarily for the time of the access.
This function was originally written by Vijaya as part of an earlier series:
https://patchwork.kernel.org/patch/8177251

Signed-off-by: Vijaya Kumar K 
Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic.c| 50 ++
 xen/include/asm-arm/vgic.h |  3 +++
 2 files changed, 53 insertions(+)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index b6fe34f..e385b43 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -602,6 +603,55 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
 }
 
 /*
+ * Temporarily map one physical guest page and copy data to or from it.
+ * The data to be copied cannot cross a page boundary.
+ */
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+ uint32_t size, bool_t is_write)
+{
+struct page_info *page;
+uint64_t offset;
+p2m_type_t p2mt;
+int ret = 0;
+void *p;
+
+page = get_page_from_gfn(d, paddr_to_pfn(gpa), , P2M_ALLOC);
+if ( !page )
+{
+printk(XENLOG_G_ERR "d%d: vITS: Failed to get table entry\n",
+   d->domain_id);
+return -EINVAL;
+}
+
+if ( !p2m_is_ram(p2mt) )
+{
+put_page(page);
+printk(XENLOG_G_ERR "d%d: vITS: memory used by the ITS should be RAM.",
+   d->domain_id);
+return -EINVAL;
+}
+
+p = __map_domain_page(page);
+/* Offset within the mapped page */
+offset = gpa & ~PAGE_MASK;
+/* Do not cross a page boundary. */
+if ( size <= (PAGE_SIZE - offset) )
+{
+if ( is_write )
+memcpy(p + offset, buf, size);
+else
+memcpy(buf, p + offset, size);
+}
+else
+ret = -ENOSPC;
+
+unmap_domain_page(p);
+put_page(page);
+
+return ret;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 7efa164..6b17802 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -313,6 +313,9 @@ extern void register_vgic_ops(struct domain *d, const 
struct vgic_ops *ops);
 int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
 
+int vgic_access_guest_memory(struct domain *d, paddr_t gpa, void *buf,
+ uint32_t size, bool_t is_write);
+
 extern int domain_vgic_register(struct domain *d, int *mmio_count);
 extern int vcpu_vgic_free(struct vcpu *v);
 extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
-- 
2.8.2


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

[Xen-devel] [PATCH v8 14/27] ARM: vITS: introduce translation table walks

[Andre Przywara]

The ITS stores the target (v)CPU and the (virtual) LPI number in tables.
Introduce functions to walk those tables and translate an device ID -
event ID pair into a pair of virtual LPI and vCPU.
We map those tables on demand - which is cheap on arm64 - and copy the
respective entries before using them, to avoid the guest tampering with
them meanwhile.

To allow compiling without warnings, we declare two functions as
non-static for the moment, which two later patches will fix.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 183 +
 1 file changed, 183 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index a60f9b2..632ab84 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -78,6 +78,7 @@ struct vits_itte
 uint16_t pad;
 };
 
+#define UNMAPPED_COLLECTION  ((uint16_t)~0)
 #define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
   (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
 
@@ -94,6 +95,188 @@ void vgic_v3_its_free_domain(struct domain *d)
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }
 
+/*
+ * The physical address is encoded slightly differently depending on
+ * the used page size: the highest four bits are stored in the lowest
+ * four bits of the field for 64K pages.
+ */
+static paddr_t get_baser_phys_addr(uint64_t reg)
+{
+if ( reg & BIT(9) )
+return (reg & GENMASK(47, 16)) |
+((reg & GENMASK(15, 12)) << 36);
+else
+return reg & GENMASK(47, 12);
+}
+
+/*
+ * Our collection table encoding:
+ * Just contains the 16-bit VCPU ID of the respective vCPU.
+ */
+#define COLL_TABLE_ENTRY_SIZE 2UL
+
+/* Must be called with the ITS lock held. */
+static struct vcpu *get_vcpu_from_collection(struct virt_its *its,
+ uint16_t collid)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_coll);
+uint16_t vcpu_id;
+int ret;
+
+ASSERT(spin_is_locked(>its_lock));
+
+if ( collid >= its->max_collections )
+return NULL;
+
+ret = vgic_access_guest_memory(its->d, addr + collid * sizeof(uint16_t),
+   _id, sizeof(vcpu_id), false);
+if ( ret )
+return NULL;
+
+if ( vcpu_id == UNMAPPED_COLLECTION || vcpu_id >= its->d->max_vcpus )
+return NULL;
+
+return its->d->vcpu[vcpu_id];
+}
+
+/*
+ * Our device table encodings:
+ * Contains the guest physical address of the Interrupt Translation Table in
+ * bits [51:8], and the size of it is encoded as the number of bits minus one
+ * in the lowest 5 bits of the word.
+ */
+#define DEV_TABLE_ENTRY_SIZE  8UL
+#define DEV_TABLE_ITT_ADDR(x) ((x) & GENMASK(51, 8))
+#define DEV_TABLE_ITT_SIZE(x) (BIT(((x) & GENMASK(4, 0)) + 1))
+#define DEV_TABLE_ENTRY(addr, bits) \
+(((addr) & GENMASK(51, 8)) | (((bits) - 1) & GENMASK(4, 0)))
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * that device ID.
+ * TODO: add support for walking indirect tables.
+ */
+static int its_get_itt(struct virt_its *its, uint32_t devid,
+   uint64_t *itt)
+{
+paddr_t addr = get_baser_phys_addr(its->baser_dev);
+
+if ( devid >= its->max_devices )
+return -EINVAL;
+
+return vgic_access_guest_memory(its->d, addr + devid * sizeof(uint64_t),
+itt, sizeof(*itt), false);
+}
+
+/*
+ * Lookup the address of the Interrupt Translation Table associated with
+ * a device ID and return the address of the ITTE belonging to the event ID
+ * (which is an index into that table).
+ */
+static paddr_t its_get_itte_address(struct virt_its *its,
+uint32_t devid, uint32_t evid)
+{
+uint64_t itt;
+int ret;
+
+ret = its_get_itt(its, devid, );
+if ( ret )
+return INVALID_PADDR;
+
+if ( evid >= DEV_TABLE_ITT_SIZE(itt) ||
+ DEV_TABLE_ITT_ADDR(itt) == INVALID_PADDR )
+return INVALID_PADDR;
+
+return DEV_TABLE_ITT_ADDR(itt) + evid * sizeof(struct vits_itte);
+}
+
+/*
+ * Queries the collection and device tables to get the vCPU and virtual
+ * LPI number for a given guest event. This first accesses the guest memory
+ * to resolve the address of the ITTE, then reads the ITTE entry at this
+ * address and puts the result in vcpu_ptr and vlpi_ptr.
+ * Must be called with the ITS lock held.
+ */
+static bool read_itte_locked(struct virt_its *its, uint32_t devid,
+ uint32_t evid, struct vcpu **vcpu_ptr,
+ uint32_t *vlpi_ptr)
+{
+paddr_t addr;
+struct vits_itte itte;
+struct vcpu *vcpu;
+
+ASSERT(spin_is_locked(>its_lock));
+
+addr = its_get_itte_address(its, devid, evid);
+if ( addr == INVALID_PADDR )
+return false;
+
+if ( vgic_access_guest_memory(its->d, addr, , sizeof(itte), false) )
+

[Xen-devel] [PATCH v8 01/27] ARM: GICv3: propagate number of host LPIs to GICv3 guest

[Andre Przywara]

The host supports a certain number of LPI identifiers, as stored in
the GICD_TYPER register.
Store this number from the hardware register in vgic_v3_hw to allow
injecting the very same number into a guest (Dom0).

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3.c| 6 +-
 xen/arch/arm/vgic-v3.c   | 7 ++-
 xen/include/asm-arm/domain.h | 1 +
 xen/include/asm-arm/vgic.h   | 3 ++-
 4 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index a559e5e..29c8964 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1579,6 +1579,7 @@ static int __init gicv3_init(void)
 {
 int res, i;
 uint32_t reg;
+unsigned int intid_bits;
 
 if ( !cpu_has_gicv3 )
 {
@@ -1622,8 +1623,11 @@ static int __init gicv3_init(void)
i, r->base, r->base + r->size);
 }
 
+reg = readl_relaxed(GICD + GICD_TYPER);
+intid_bits = GICD_TYPE_ID_BITS(reg);
+
 vgic_v3_setup_hw(dbase, gicv3.rdist_count, gicv3.rdist_regions,
- gicv3.rdist_stride);
+ gicv3.rdist_stride, intid_bits);
 gicv3_init_v2();
 
 spin_lock_init();
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index d10757a..ebcca22 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -57,18 +57,21 @@ static struct {
 unsigned int nr_rdist_regions;
 const struct rdist_region *regions;
 uint32_t rdist_stride; /* Re-distributor stride */
+unsigned int intid_bits;  /* Number of interrupt ID bits */
 } vgic_v3_hw;
 
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride)
+  uint32_t rdist_stride,
+  unsigned int intid_bits)
 {
 vgic_v3_hw.enabled = 1;
 vgic_v3_hw.dbase = dbase;
 vgic_v3_hw.nr_rdist_regions = nr_rdist_regions;
 vgic_v3_hw.regions = regions;
 vgic_v3_hw.rdist_stride = rdist_stride;
+vgic_v3_hw.intid_bits = intid_bits;
 }
 
 static struct vcpu *vgic_v3_irouter_to_vcpu(struct domain *d, uint64_t irouter)
@@ -1482,6 +1485,8 @@ static int vgic_v3_domain_init(struct domain *d)
 
 first_cpu += size / d->arch.vgic.rdist_stride;
 }
+
+d->arch.vgic.intid_bits = vgic_v3_hw.intid_bits;
 }
 else
 {
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 6de8082..7c3829d 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -111,6 +111,7 @@ struct arch_domain
 uint32_t rdist_stride;  /* Re-Distributor stride */
 struct rb_root its_devices; /* Devices mapped to an ITS */
 spinlock_t its_devices_lock;/* Protects the its_devices tree */
+unsigned int intid_bits;
 #endif
 } vgic;
 
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 544867a..df75064 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -346,7 +346,8 @@ struct rdist_region;
 void vgic_v3_setup_hw(paddr_t dbase,
   unsigned int nr_rdist_regions,
   const struct rdist_region *regions,
-  uint32_t rdist_stride);
+  uint32_t rdist_stride,
+  unsigned int intid_bits);
 #endif
 
 #endif /* __ASM_ARM_VGIC_H__ */
-- 
2.8.2


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

Re: [Xen-devel] [PATCH] blkfront: add uevent for size change

[Marc Olson]

On Tue, Apr 11, 2017 at 04:04:59PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> > When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> > notify the guest about the change. This allows for custom udev rules, such
> > as automatically resizing a filesystem, when an event occurs.
> 
> Looks pretty reasonable.
> 
> Could you confirm what the udevadm --monitor --kernel --udev emits when this 
> happens?

Relevant output:

KERNEL[577.206230] change   /devices/vbd-51728/block/xvdb (block)
UDEV  [577.226218] change   /devices/vbd-51728/block/xvdb (block)

Of course, this is missing without the patch.

/marc

> 
> Thanks!
> 
> > 
> > Signed-off-by: Marc Olson 
> > ---
> >  drivers/block/xen-blkfront.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 2fee2ee..66abf9c 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -1996,6 +1996,7 @@ static void blkfront_connect(struct blkfront_info 
> > *info)
> > unsigned long sector_size;
> > unsigned int physical_sector_size;
> > unsigned int binfo;
> > +   char *envp[] = { "RESIZE=1", NULL };
> > int err;
> >  
> > switch (info->connected) {
> > @@ -2012,6 +2013,8 @@ static void blkfront_connect(struct blkfront_info 
> > *info)
> >sectors);
> > set_capacity(info->gd, sectors);
> > revalidate_disk(info->gd);
> > +   kobject_uevent_env(_to_dev(info->gd)->kobj,
> > +  KOBJ_CHANGE, envp);
> >  
> > return;
> > case BLKIF_STATE_SUSPENDED:
> > -- 
> > 2.7.4
> > 
> 

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

Re: [Xen-devel] null domains after xl destroy

[Glenn Enright]

On 12/04/17 10:23, Andrew Cooper wrote:

On 11/04/2017 23:13, Glenn Enright wrote:

On 11/04/17 21:49, Dietmar Hahn wrote:

Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:

On 11/04/17 17:59, Juergen Gross wrote:

On 11/04/17 07:25, Glenn Enright wrote:

Hi all

We are seeing an odd issue with domu domains from xl destroy, under
recent 4.9 kernels a (null) domain is left behind.


I guess this is the dom0 kernel version?


This has occurred on a variety of hardware, with no obvious
commonality.

4.4.55 does not show this behavior.

On my test machine I have the following packages installed under
centos6, from https://xen.crc.id.au/

~]# rpm -qa | grep xen
xen47-licenses-4.7.2-4.el6.x86_64
xen47-4.7.2-4.el6.x86_64
kernel-xen-4.9.21-1.el6xen.x86_64
xen47-ocaml-4.7.2-4.el6.x86_64
xen47-libs-4.7.2-4.el6.x86_64
xen47-libcacard-4.7.2-4.el6.x86_64
xen47-hypervisor-4.7.2-4.el6.x86_64
xen47-runtime-4.7.2-4.el6.x86_64
kernel-xen-firmware-4.9.21-1.el6xen.x86_64

I've also replicated the issue with 4.9.17 and 4.9.20

To replicate, on a cleanly booted dom0 with one pv VM, I run the
following on the VM

{
while true; do
 dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
done
}

Then on the dom0 I do this sequence to reliably get a null domain.
This
occurs with oxenstored and xenstored both.

{
xl sync 1
xl destroy 1
}

xl list then renders something like ...

(null)   1 4 4 --p--d
9.8 0


Something is referencing the domain, e.g. some of its memory pages are
still mapped by dom0.


You can try
# xl debug-keys q
and further
# xl dmesg
to see the output of the previous command. The 'q' dumps domain
(and guest debug) info.
# xl debug-keys h
prints all possible parameters for more informations.

Dietmar.



I've done this as requested, below is the output.


(XEN) Memory pages belonging to domain 1:
(XEN) DomPage 00071c00: caf=0001, taf=7401
(XEN) DomPage 00071c01: caf=0001, taf=7401
(XEN) DomPage 00071c02: caf=0001, taf=7401
(XEN) DomPage 00071c03: caf=0001, taf=7401
(XEN) DomPage 00071c04: caf=0001, taf=7401
(XEN) DomPage 00071c05: caf=0001, taf=7401
(XEN) DomPage 00071c06: caf=0001, taf=7401
(XEN) DomPage 00071c07: caf=0001, taf=7401
(XEN) DomPage 00071c08: caf=0001, taf=7401
(XEN) DomPage 00071c09: caf=0001, taf=7401
(XEN) DomPage 00071c0a: caf=0001, taf=7401
(XEN) DomPage 00071c0b: caf=0001, taf=7401
(XEN) DomPage 00071c0c: caf=0001, taf=7401
(XEN) DomPage 00071c0d: caf=0001, taf=7401
(XEN) DomPage 00071c0e: caf=0001, taf=7401
(XEN) DomPage 00071c0f: caf=0001, taf=7401


There are 16 pages still referenced from somewhere.

Can you grab all of `xenstore-ls -f` in dom0?  There is probably a
backend still attached.

~Andrew



Note this is under oxenstored presently.

# xenstore-ls -f
/local = ""
/local/domain = ""
/local/domain/0 = ""
/local/domain/0/control = ""
/local/domain/0/control/feature-poweroff = "1"
/local/domain/0/control/feature-reboot = "1"
/local/domain/0/control/feature-suspend = "1"
/local/domain/0/domid = "0"
/local/domain/0/name = "Domain-0"
/vm = ""
/libxl = ""

# xl list
NameID   Mem VCPUs  State 
Time(s)
Domain-0 0  1512 2 r- 
  35.0
(null)   1 8 4 --p--d 
   8.5


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

Re: [Xen-devel] [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[Stefano Stabellini]

On Tue, 11 Apr 2017, hrg wrote:
> On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini
>  wrote:
> > On Mon, 10 Apr 2017, Stefano Stabellini wrote:
> >> On Mon, 10 Apr 2017, hrg wrote:
> >> > On Sun, Apr 9, 2017 at 11:55 PM, hrg  wrote:
> >> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:
> >> > >> Hi,
> >> > >>
> >> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
> >> > >> instead of first level entry (if map to rom other than guest memory
> >> > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned
> >> > >> out memory, qemu did not invalidate cache entries in linked
> >> > >> list(entry->next), so when VM balloon back in memory, gfns probably
> >> > >> mapped to different mfns, thus if guest asks device to DMA to these
> >> > >> GPA, qemu may DMA to stale MFNs.
> >> > >>
> >> > >> So I think in xen_invalidate_map_cache() linked lists should also be
> >> > >> checked and invalidated.
> >> > >>
> >> > >> What’s your opinion? Is this a bug? Is my analyze correct?
> >>
> >> Yes, you are right. We need to go through the list for each element of
> >> the array in xen_invalidate_map_cache. Can you come up with a patch?
> >
> > I spoke too soon. In the regular case there should be no locked mappings
> > when xen_invalidate_map_cache is called (see the DPRINTF warning at the
> > beginning of the functions). Without locked mappings, there should never
> > be more than one element in each list (see xen_map_cache_unlocked:
> > entry->lock == true is a necessary condition to append a new entry to
> > the list, otherwise it is just remapped).
> >
> > Can you confirm that what you are seeing are locked mappings
> > when xen_invalidate_map_cache is called? To find out, enable the DPRINTK
> > by turning it into a printf or by defininig MAPCACHE_DEBUG.
> 
> In fact, I think the DPRINTF above is incorrect too. In
> pci_add_option_rom(), rtl8139 rom is locked mapped in
> pci_add_option_rom->memory_region_get_ram_ptr (after
> memory_region_init_ram). So actually I think we should remove the
> DPRINTF warning as it is normal.

Let me explain why the DPRINTF warning is there: emulated dma operations
can involve locked mappings. Once a dma operation completes, the related
mapping is unlocked and can be safely destroyed. But if we destroy a
locked mapping in xen_invalidate_map_cache, while a dma is still
ongoing, QEMU will crash. We cannot handle that case.

However, the scenario you described is different. It has nothing to do
with DMA. It looks like pci_add_option_rom calls
memory_region_get_ram_ptr to map the rtl8139 rom. The mapping is a
locked mapping and it is never unlocked or destroyed.

It looks like "ptr" is not used after pci_add_option_rom returns. Does
the append patch fix the problem you are seeing? For the proper fix, I
think we probably need some sort of memory_region_unmap wrapper or maybe
a call to address_space_unmap.


diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index e6b08e1..04f98b7 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -2242,6 +2242,7 @@ static void pci_add_option_rom(PCIDevice *pdev, bool 
is_default_rom,
 }
 
 pci_register_bar(pdev, PCI_ROM_SLOT, 0, >rom);
+xen_invalidate_map_cache_entry(ptr);
 }
 
 static void pci_del_option_rom(PCIDevice *pdev)___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] null domains after xl destroy

[Andrew Cooper]

On 11/04/2017 23:13, Glenn Enright wrote:
> On 11/04/17 21:49, Dietmar Hahn wrote:
>> Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:
>>> On 11/04/17 17:59, Juergen Gross wrote:
 On 11/04/17 07:25, Glenn Enright wrote:
> Hi all
>
> We are seeing an odd issue with domu domains from xl destroy, under
> recent 4.9 kernels a (null) domain is left behind.

 I guess this is the dom0 kernel version?

> This has occurred on a variety of hardware, with no obvious
> commonality.
>
> 4.4.55 does not show this behavior.
>
> On my test machine I have the following packages installed under
> centos6, from https://xen.crc.id.au/
>
> ~]# rpm -qa | grep xen
> xen47-licenses-4.7.2-4.el6.x86_64
> xen47-4.7.2-4.el6.x86_64
> kernel-xen-4.9.21-1.el6xen.x86_64
> xen47-ocaml-4.7.2-4.el6.x86_64
> xen47-libs-4.7.2-4.el6.x86_64
> xen47-libcacard-4.7.2-4.el6.x86_64
> xen47-hypervisor-4.7.2-4.el6.x86_64
> xen47-runtime-4.7.2-4.el6.x86_64
> kernel-xen-firmware-4.9.21-1.el6xen.x86_64
>
> I've also replicated the issue with 4.9.17 and 4.9.20
>
> To replicate, on a cleanly booted dom0 with one pv VM, I run the
> following on the VM
>
> {
> while true; do
>  dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
> done
> }
>
> Then on the dom0 I do this sequence to reliably get a null domain.
> This
> occurs with oxenstored and xenstored both.
>
> {
> xl sync 1
> xl destroy 1
> }
>
> xl list then renders something like ...
>
> (null)   1 4 4 --p--d
> 9.8 0

 Something is referencing the domain, e.g. some of its memory pages are
 still mapped by dom0.
>>
>> You can try
>> # xl debug-keys q
>> and further
>> # xl dmesg
>> to see the output of the previous command. The 'q' dumps domain
>> (and guest debug) info.
>> # xl debug-keys h
>> prints all possible parameters for more informations.
>>
>> Dietmar.
>>
>
> I've done this as requested, below is the output.
>
> 
> (XEN) Memory pages belonging to domain 1:
> (XEN) DomPage 00071c00: caf=0001, taf=7401
> (XEN) DomPage 00071c01: caf=0001, taf=7401
> (XEN) DomPage 00071c02: caf=0001, taf=7401
> (XEN) DomPage 00071c03: caf=0001, taf=7401
> (XEN) DomPage 00071c04: caf=0001, taf=7401
> (XEN) DomPage 00071c05: caf=0001, taf=7401
> (XEN) DomPage 00071c06: caf=0001, taf=7401
> (XEN) DomPage 00071c07: caf=0001, taf=7401
> (XEN) DomPage 00071c08: caf=0001, taf=7401
> (XEN) DomPage 00071c09: caf=0001, taf=7401
> (XEN) DomPage 00071c0a: caf=0001, taf=7401
> (XEN) DomPage 00071c0b: caf=0001, taf=7401
> (XEN) DomPage 00071c0c: caf=0001, taf=7401
> (XEN) DomPage 00071c0d: caf=0001, taf=7401
> (XEN) DomPage 00071c0e: caf=0001, taf=7401
> (XEN) DomPage 00071c0f: caf=0001, taf=7401

There are 16 pages still referenced from somewhere.

Can you grab all of `xenstore-ls -f` in dom0?  There is probably a
backend still attached.

~Andrew

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

[Xen-devel] [ovmf baseline-only test] 71173: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
baseline version:
 ovmf 1ea946d0f9ea7de963545fbe93cc7f781c03d0b2

Last test of basis71169  2017-04-10 14:21:51 Z1 days
Testing same since71173  2017-04-11 19:51:36 Z0 days1 attempts


People who touched revisions under test:
  Hess Chen 
  Liming Gao 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
Author: Hess Chen 
Date:   Mon Apr 10 10:57:18 2017 +0800

BaseTools/ECC: Change check rule for Ifndef statement

Remove the check of Ifndef statement on .c files, only check on .h
files.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen 
Reviewed-by: Yonghong Zhu 

commit ab200776cdba018c4b6e5f712628482d46ba4931
Author: Liming Gao 
Date:   Tue Apr 11 14:21:34 2017 +0800

BaseTools: Add option in CLANG38 to disable warning unknown-warning-option

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

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

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

[Xen-devel] [xen-4.4-testing test] 107365: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
106822

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken in 107326 pass in 107365
 test-armhf-armhf-libvirt-raw 7 host-ping-check-xen fail in 107326 pass in 
107365
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 107326 
pass in 107365
 test-amd64-i386-xend-qemut-winxpsp3 9 windows-install fail in 107326 pass in 
107365
 test-armhf-armhf-xl-multivcpu 16 guest-start.2   fail in 107351 pass in 107326
 test-armhf-armhf-xl-arndale   6 xen-boot fail in 107351 pass in 107365
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail in 107351 
pass in 107365
 test-amd64-amd64-pv  17 guest-localmigrate/x10 fail pass in 107326
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 107351
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail pass 
in 107351

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 107351 blocked in 
106822
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pae-invlpg~shadow fail like 106822
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 106822
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 106822
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106822
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 106822
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106822

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-3   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 

Re: [Xen-devel] null domains after xl destroy

[Glenn Enright]

On 11/04/17 21:49, Dietmar Hahn wrote:

Am Dienstag, 11. April 2017, 20:03:14 schrieb Glenn Enright:

On 11/04/17 17:59, Juergen Gross wrote:

On 11/04/17 07:25, Glenn Enright wrote:

Hi all

We are seeing an odd issue with domu domains from xl destroy, under
recent 4.9 kernels a (null) domain is left behind.


I guess this is the dom0 kernel version?


This has occurred on a variety of hardware, with no obvious commonality.

4.4.55 does not show this behavior.

On my test machine I have the following packages installed under
centos6, from https://xen.crc.id.au/

~]# rpm -qa | grep xen
xen47-licenses-4.7.2-4.el6.x86_64
xen47-4.7.2-4.el6.x86_64
kernel-xen-4.9.21-1.el6xen.x86_64
xen47-ocaml-4.7.2-4.el6.x86_64
xen47-libs-4.7.2-4.el6.x86_64
xen47-libcacard-4.7.2-4.el6.x86_64
xen47-hypervisor-4.7.2-4.el6.x86_64
xen47-runtime-4.7.2-4.el6.x86_64
kernel-xen-firmware-4.9.21-1.el6xen.x86_64

I've also replicated the issue with 4.9.17 and 4.9.20

To replicate, on a cleanly booted dom0 with one pv VM, I run the
following on the VM

{
while true; do
 dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
done
}

Then on the dom0 I do this sequence to reliably get a null domain. This
occurs with oxenstored and xenstored both.

{
xl sync 1
xl destroy 1
}

xl list then renders something like ...

(null)   1 4 4 --p--d
9.8 0


Something is referencing the domain, e.g. some of its memory pages are
still mapped by dom0.


You can try
# xl debug-keys q
and further
# xl dmesg
to see the output of the previous command. The 'q' dumps domain
(and guest debug) info.
# xl debug-keys h
prints all possible parameters for more informations.

Dietmar.



I've done this as requested, below is the output.

(XEN) 'q' pressed -> dumping domain info (now=0x92:D6C271CE)
(XEN) General information for domain 0:
(XEN) refcnt=3 dying=0 pause_count=0
(XEN) nr_pages=387072 xenheap_pages=5 shared_pages=0 paged_pages=0 
dirty_cpus={0-1} max_pages=4294967295

(XEN) handle=---- vm_assist=000d
(XEN) Rangesets belonging to domain 0:
(XEN) I/O Ports  { 0-1f, 22-3f, 44-60, 62-9f, a2-cfb, d00-1007, 
100c- }

(XEN) log-dirty  { }
(XEN) Interrupts { 1-30 }
(XEN) I/O Memory { 0-fedff, fef00-ff }
(XEN) Memory pages belonging to domain 0:
(XEN) DomPage list too long to display
(XEN) XenPage 0020e9c5: caf=c002, 
taf=7402
(XEN) XenPage 0020e9c4: caf=c001, 
taf=7401
(XEN) XenPage 0020e9c3: caf=c001, 
taf=7401
(XEN) XenPage 0020e9c2: caf=c001, 
taf=7401
(XEN) XenPage 000e7d2e: caf=c002, 
taf=7402

(XEN) NODE affinity for domain 0: [0]
(XEN) VCPU information and callbacks for domain 0:
(XEN) VCPU0: CPU0 [has=T] poll=0 upcall_pend=01 upcall_mask=00 
dirty_cpus={0}

(XEN) cpu_hard_affinity={0} cpu_soft_affinity={0-3}
(XEN) pause_count=0 pause_flags=0
(XEN) No periodic timer
(XEN) VCPU1: CPU1 [has=T] poll=0 upcall_pend=00 upcall_mask=00 
dirty_cpus={1}

(XEN) cpu_hard_affinity={1} cpu_soft_affinity={0-3}
(XEN) pause_count=0 pause_flags=0
(XEN) No periodic timer
(XEN) General information for domain 1:
(XEN) refcnt=1 dying=2 pause_count=2
(XEN) nr_pages=2114 xenheap_pages=0 shared_pages=0 paged_pages=0 
dirty_cpus={} max_pages=1280256

(XEN) handle=a481c2eb-31e3-4ae6-9809-290e746c8eec vm_assist=000d
(XEN) Rangesets belonging to domain 1:
(XEN) I/O Ports  { }
(XEN) log-dirty  { }
(XEN) Interrupts { }
(XEN) I/O Memory { }
(XEN) Memory pages belonging to domain 1:
(XEN) DomPage 00071c00: caf=0001, taf=7401
(XEN) DomPage 00071c01: caf=0001, taf=7401
(XEN) DomPage 00071c02: caf=0001, taf=7401
(XEN) DomPage 00071c03: caf=0001, taf=7401
(XEN) DomPage 00071c04: caf=0001, taf=7401
(XEN) DomPage 00071c05: caf=0001, taf=7401
(XEN) DomPage 00071c06: caf=0001, taf=7401
(XEN) DomPage 00071c07: caf=0001, taf=7401
(XEN) DomPage 00071c08: caf=0001, taf=7401
(XEN) DomPage 00071c09: caf=0001, taf=7401
(XEN) DomPage 00071c0a: caf=0001, taf=7401
(XEN) DomPage 00071c0b: caf=0001, taf=7401
(XEN) DomPage 00071c0c: caf=0001, taf=7401
(XEN) DomPage 00071c0d: caf=0001, taf=7401
(XEN) DomPage 00071c0e: caf=0001, taf=7401
(XEN) DomPage 00071c0f: caf=0001, taf=7401
(XEN) NODE affinity for domain 1: [0]
(XEN) VCPU information and callbacks for domain 1:
(XEN) VCPU0: CPU0 [has=F] poll=0 

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

[Stefano Stabellini]

On Tue, 11 Apr 2017, Bhupinder Thakur wrote:
> Hi,
> 
> Kindly let me know if my understanding is correct.
> 
> Using a domctl API will allow us to keep the vUART configuration
> flexible. Currently, we can operate on one ring-buf PFN and an event
> channel port only for a single vUART but if we use DOMCTL interface,
> then we can effectively get/set multiple event channel ports/multiple
> PFNs from/to Xen in a single domctl call.
> 
> I am not clear who will be the caller of this domctl API. Is it
> xenconsoled or the toolstack? Currently, xenconsoled reads the
> ring-buf PFN and event channel from the xenstore, which is populated
> by the toolstack.

The caller could be either, but I think it would make sense for it to be
xenconsoled to cut the middle-man (xl).


> On 8 March 2017 at 23:52, Stefano Stabellini  wrote:
> > On Wed, 8 Mar 2017, Jan Beulich wrote:
> >> >>> On 08.03.17 at 15:45,  wrote:
> >> > I was looking at the backend code and see it is using DOMCTL command. I
> >> > guess it is considered that the console backend will be tied to a
> >> > specific Xen version. Am I correct?
> >>
> >> I don't think I'm qualified to talk about the console backend
> >> implementation (and possible quirks it has). Generally I'd expect
> >> backends not to use domctl-s, as that would tie them to the tool
> >> stack domain.
> >>
> >> > so maybe we can introduce new domctl command for handling vUART. This
> >> > would avoid us to commit on an ABI and allow us to extend it if
> >> > necessary in the future to support multiple UARTs.
> >>
> >> Well, without having the context of who it would be to use such a
> >> domctl (and for what purpose) I don#t think I can comment here.
> >
> > I guess the assumption was that xenconsoled was part of the Xen tools.
> > Indeed, it is part of the tools and is installed as such.
> >
> > I don't have an opinion on this. If introducing a new DOMCTL makes the
> > code nicer in xen and xenconsoled, taking away some edges, like the
> > changes to evtchn_send, then we should probably just do it.
> 

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

[Xen-devel] [libvirt test] 107362: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  fd6e3f48ede2e3a01ef849ea4411d6507515956e
baseline version:
 libvirt  4c661a944d75638db76483bbd058981b4c0595a8

Last test of basis   107325  2017-04-09 17:17:18 Z2 days
Testing same since   107353  2017-04-10 16:31:08 Z1 days2 attempts


People who touched revisions under test:
  John Ferlan 
  Marc Hartmayer 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=fd6e3f48ede2e3a01ef849ea4411d6507515956e
+ . 

Re: [Xen-devel] [ARM] Native application design and discussion (I hope)

[Stefano Stabellini]

On Fri, 7 Apr 2017, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Volodymyr Babchuk wrote:
> > >> Native application is an another domain type. It has own vCPU (only one 
> > >> at this
> > >> moment) Native app is loaded as any other kernel, using ELF loader.
> > >> It looks like another stub-domain such as MiniOS, but there are two big
> > >> differences:
> > >
> > > Could you describe the reason why you are suggesting it? Unless strictly
> > > necessary, I wouldn't go down the vcpu route, because as soon as we
> > > bring a vcpu into the picture, we have a number of problems, including
> > > scheduling, affinity, etc. It is also user-visible (xl vcpu-list) which
> > > I don't think it should be.
> > I used this in my PoC because I didn't want to do extra work. Also this 
> > looks
> > very natural. Domain is actually the same as a process, vcpu is like a 
> > thread.
> > But yes, I already had some issues with scheduler. Manageable, thought.
> > 
> > > I understand that one of the goals is "Modularity", which makes us think
> > > of an ELF loader, such as the one for a new domain. I agree that
> > > modularity is important, but I would solve it as a second step. In first
> > > instance, I would limit the scope to run some code under
> > > /xen/arch/arm/apps or, better, /apps (for example) in a lower privilege
> > > mode. After that is done and working, I am sure we can find a way to
> > > dynamically load more apps at run time.
> > Again, use of existing domain framework was the easiest way. I needed
> > some container to hold app and domain fits perfectly. I need to map pages
> > there, need routines to copy to and from its memory, need p2m code, etc.
> > 
> > But, yes, if we are going to implement this in right way, then maybe we need
> > separate identities like 'app_container' and 'app_thread'. See below.
> > 
> > >
> > > A vcpu is expected to be running simultenously with other vcpus of the
> > > same domain or different domains. The scheduler is expected to choose
> > > when it is supposed to be running. On the other end, an el0 app runs to
> > > handle/emulate a single request from a guest vcpu, which will be paused
> > > until the el0 app finishes. After that, the guest vcpu will resume.
> > Okay, but what should be stored in `current` while el0 application is 
> > running?
> > Remember, that it can issue syscalls, which will be handled in hypervisor.
> > 
> > We can create separates types for native applications. But then we can end
> > having two parallel and mostly identical frameworks. One for domains and
> > another one - for apps. What do you think?
> 
> This is a great topic for the Xen Hackathon.
> 
> This is the most difficult problem that we need to solve as part of this
> work. It is difficult to have the right answer at the beginning, before
> seeing any code. If the app_container/app_thread approach causes too
> much duplication of work, the alternative would be to fix/improve
> stubdoms (minios) until they match what we need. Specifically, these
> would be the requirements:
> 
> 1) Determinism: a stubdom servicing a given guest needs to be scheduled
>immediately after the guest vcpu traps into Xen. It needs to
>deterministic. The stubdom vcpu has to be scheduled on the same pcpu.
>This is probably the most important missing thing at the moment.
> 
> 2) Accounting: memory and cpu time of a stubdom should be accounted
>agaist the domain it is servicing. Otherwise it's not fair.
> 
> 3) Visibility: stub domains and vcpus should be marked differently from other
>vcpus as not to confuse the user. Otherwise "xl list" becomes
>confusing.
> 
> 
> 1) and 2) are particularly important. If we had them, we would not need
> el0 apps. I believe stubdoms would be as fast as el0 apps too.

CC'ing George and Dario. I was speaking with George about this topic,
I'll let him explain his view as scheduler maintainer, but he suggested
to avoid scheduler modifications (all schedulers would need to be
taught to handle this) and extend struct vcpu for el0 apps instead.


> > >> At this moment entry point is hardcoded and you need to update it every 
> > >> time
> > >> you rebuild native application. Also there are no actual parameters 
> > >> passed.
> > >> Also, whole code is a piece of gosa, because it was first time I hacked 
> > >> XEN.
> > >
> > > :-)
> > > I would start by introducing a proper way to pass parameters and return
> > > values.
> > >
> > >> I don't want to repeat benchmark results, because they already was 
> > >> posted in ML.
> > >> You can find them at [3].
> > >>
> > >> I understand that I have missed many things:
> > >>
> > >> 1. How to ship and load native app, because some of them will be needed 
> > >> even
> > >> before dom0 is created.
> > >
> > > I envision something like Linux's insmod, but I suggest postponing this
> > > problem. At the moment, it would be fine to assume that all apps need to
> > > be built statically and cannot be loaded at 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   9 debian-install   fail REGR. vs. 107219

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuuc322fdd41ad5b313dab0b674154a22b3c665acce
baseline version:
 qemuu1fde6ee885d3e778acb326cab9f7037939839537

Last test of basis   107219  2017-04-05 15:36:01 Z6 days
Failing since107250  2017-04-06 17:17:05 Z5 days5 attempts
Testing same since   107360  2017-04-10 23:13:23 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Alex Williamson 
  Eduardo Habkost 
  Fam Zheng 
  Greg Kurz 
  Jeff Cody 
  Kashyap Chamarthy 
  Kevin Wolf 
  Li Qiang 
  Li Qiang 
  Max Reitz 
  Nikunj A Dadhania 
  Paolo Bonzini 
  Peter Maydell 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken in 107313 pass in 107358
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 107313 pass 
in 107328
 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 107313 pass in 107358
 test-arm64-arm64-libvirt-qcow2 9 debian-di-install fail in 107313 pass in 
107358
 test-armhf-armhf-xl-xsm   6 xen-boot   fail pass in 107313
 test-armhf-armhf-xl-multivcpu  6 xen-boot  fail pass in 107328
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail pass in 
107328

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop   fail REGR. vs. 107238
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 107313 like 
107238
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107238
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107238
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107238
 test-armhf-armhf-xl   6 xen-boot fail  like 107238
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107238
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107238

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl 12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 107313 never 
pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 107313 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 107313 
never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 107313 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 107313 never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-check

[Xen-devel] [xen-4.6-testing baseline-only test] 71172: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 71153
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 71153

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt13 saverestore-support-check fail blocked in 71153
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail blocked in 71153
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail   like 71153
 test-xtf-amd64-amd64-3  33 xtf/test-hvm32pae-invlpg~shadow fail like 71153
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail   like 71153
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71153
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 71153
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 71153
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71153
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 71153

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

version targeted for testing:
 xen  cf35a354efe2d45d6c345455100fc8023eb038e2
baseline version:
 xen  bb92bb77bc98d44cc8e4d8e6d61ae82517455f41

Last test of basis71153  2017-04-06 01:47:30 Z5 days
Testing same since71172  2017-04-11 10:44:11 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Dave Scott 
  David Scott 
  Ian Jackson 
  Jonathan Davies 
  Juergen Gross 
  Stefano Stabellini 
  Thomas Sanders 

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

Re: [Xen-devel] [PATCH] blkfront: add uevent for size change

[Konrad Rzeszutek Wilk]

On Tue, Apr 11, 2017 at 12:24:09PM -0700, Marc Olson wrote:
> When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
> notify the guest about the change. This allows for custom udev rules, such
> as automatically resizing a filesystem, when an event occurs.

Looks pretty reasonable.

Could you confirm what the udevadm --monitor --kernel --udev emits when this 
happens?

Thanks!

> 
> Signed-off-by: Marc Olson 
> ---
>  drivers/block/xen-blkfront.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 2fee2ee..66abf9c 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -1996,6 +1996,7 @@ static void blkfront_connect(struct blkfront_info *info)
>   unsigned long sector_size;
>   unsigned int physical_sector_size;
>   unsigned int binfo;
> + char *envp[] = { "RESIZE=1", NULL };
>   int err;
>  
>   switch (info->connected) {
> @@ -2012,6 +2013,8 @@ static void blkfront_connect(struct blkfront_info *info)
>  sectors);
>   set_capacity(info->gd, sectors);
>   revalidate_disk(info->gd);
> + kobject_uevent_env(_to_dev(info->gd)->kobj,
> +KOBJ_CHANGE, envp);
>  
>   return;
>   case BLKIF_STATE_SUSPENDED:
> -- 
> 2.7.4
> 

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

[Xen-devel] [PATCH] blkfront: add uevent for size change

[Marc Olson]

When a blkfront device is resized from dom0, emit a KOBJ_CHANGE uevent to
notify the guest about the change. This allows for custom udev rules, such
as automatically resizing a filesystem, when an event occurs.

Signed-off-by: Marc Olson 
---
 drivers/block/xen-blkfront.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 2fee2ee..66abf9c 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1996,6 +1996,7 @@ static void blkfront_connect(struct blkfront_info *info)
unsigned long sector_size;
unsigned int physical_sector_size;
unsigned int binfo;
+   char *envp[] = { "RESIZE=1", NULL };
int err;
 
switch (info->connected) {
@@ -2012,6 +2013,8 @@ static void blkfront_connect(struct blkfront_info *info)
   sectors);
set_capacity(info->gd, sectors);
revalidate_disk(info->gd);
+   kobject_uevent_env(_to_dev(info->gd)->kobj,
+  KOBJ_CHANGE, envp);
 
return;
case BLKIF_STATE_SUSPENDED:
-- 
2.7.4


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f8c1facf34a1f65082fa22fdbc20a6e0ab8887b4
baseline version:
 ovmf 1ea946d0f9ea7de963545fbe93cc7f781c03d0b2

Last test of basis   107329  2017-04-10 00:44:13 Z1 days
Testing same since   107364  2017-04-11 06:45:29 Z0 days1 attempts


People who touched revisions under test:
  Hess Chen 
  Liming Gao 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH v4 09/13] qobject: Use simpler QDict/QList scalar insertion macros

[Eric Blake]

We now have macros in place to make it less verbose to add a scalar
to QDict and QList, so use them.  To make this patch smaller to
review, a couple of subdirectories were done in earlier patches.

Patch created mechanically via:
  spatch --sp-file scripts/coccinelle/qobject.cocci \
--macro-file scripts/cocci-macro-file.h --dir . --in-place
and needed only one touch-up in monitor.c to avoid a long line.

Signed-off-by: Eric Blake 

---
v4: no change
v3: new patch
---
 block.c   | 45 +++--
 blockdev.c| 30 +-
 hw/block/xen_disk.c   |  2 +-
 hw/usb/xen-usb.c  | 12 ++--
 monitor.c | 23 +++
 qapi/qmp-event.c  |  2 +-
 qemu-img.c|  6 +++---
 qemu-io.c |  2 +-
 qemu-nbd.c|  2 +-
 qobject/qdict.c   |  2 +-
 target/s390x/cpu_models.c |  4 ++--
 util/qemu-option.c|  2 +-
 12 files changed, 60 insertions(+), 72 deletions(-)

diff --git a/block.c b/block.c
index 9024518..c8a6bce 100644
--- a/block.c
+++ b/block.c
@@ -937,16 +937,14 @@ static void update_flags_from_options(int *flags, 
QemuOpts *opts)
 static void update_options_from_flags(QDict *options, int flags)
 {
 if (!qdict_haskey(options, BDRV_OPT_CACHE_DIRECT)) {
-qdict_put(options, BDRV_OPT_CACHE_DIRECT,
-  qbool_from_bool(flags & BDRV_O_NOCACHE));
+qdict_put_bool(options, BDRV_OPT_CACHE_DIRECT, flags & BDRV_O_NOCACHE);
 }
 if (!qdict_haskey(options, BDRV_OPT_CACHE_NO_FLUSH)) {
-qdict_put(options, BDRV_OPT_CACHE_NO_FLUSH,
-  qbool_from_bool(flags & BDRV_O_NO_FLUSH));
+qdict_put_bool(options, BDRV_OPT_CACHE_NO_FLUSH,
+   flags & BDRV_O_NO_FLUSH);
 }
 if (!qdict_haskey(options, BDRV_OPT_READ_ONLY)) {
-qdict_put(options, BDRV_OPT_READ_ONLY,
-  qbool_from_bool(!(flags & BDRV_O_RDWR)));
+qdict_put_bool(options, BDRV_OPT_READ_ONLY, !(flags & BDRV_O_RDWR));
 }
 }

@@ -1362,7 +1360,7 @@ static int bdrv_fill_options(QDict **options, const char 
*filename,
 /* Fetch the file name from the options QDict if necessary */
 if (protocol && filename) {
 if (!qdict_haskey(*options, "filename")) {
-qdict_put(*options, "filename", qstring_from_str(filename));
+qdict_put_str(*options, "filename", filename);
 parse_filename = true;
 } else {
 error_setg(errp, "Can't specify 'file' and 'filename' options at "
@@ -1383,7 +1381,7 @@ static int bdrv_fill_options(QDict **options, const char 
*filename,
 }

 drvname = drv->format_name;
-qdict_put(*options, "driver", qstring_from_str(drvname));
+qdict_put_str(*options, "driver", drvname);
 } else {
 error_setg(errp, "Must specify either driver or file");
 return -EINVAL;
@@ -2038,7 +2036,7 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict 
*parent_options,
 }

 if (bs->backing_format[0] != '\0' && !qdict_haskey(options, "driver")) {
-qdict_put(options, "driver", qstring_from_str(bs->backing_format));
+qdict_put_str(options, "driver", bs->backing_format);
 }

 backing_hd = bdrv_open_inherit(*backing_filename ? backing_filename : NULL,
@@ -2193,12 +2191,9 @@ static BlockDriverState 
*bdrv_append_temp_snapshot(BlockDriverState *bs,
 }

 /* Prepare options QDict for the temporary file */
-qdict_put(snapshot_options, "file.driver",
-  qstring_from_str("file"));
-qdict_put(snapshot_options, "file.filename",
-  qstring_from_str(tmp_filename));
-qdict_put(snapshot_options, "driver",
-  qstring_from_str("qcow2"));
+qdict_put_str(snapshot_options, "file.driver", "file");
+qdict_put_str(snapshot_options, "file.filename", tmp_filename);
+qdict_put_str(snapshot_options, "driver", "qcow2");

 bs_snapshot = bdrv_open(NULL, NULL, snapshot_options, flags, errp);
 snapshot_options = NULL;
@@ -2373,8 +2368,7 @@ static BlockDriverState *bdrv_open_inherit(const char 
*filename,
 goto fail;
 }

-qdict_put(options, "file",
-  qstring_from_str(bdrv_get_node_name(file_bs)));
+qdict_put_str(options, "file", bdrv_get_node_name(file_bs));
 }
 }

@@ -2396,8 +2390,8 @@ static BlockDriverState *bdrv_open_inherit(const char 
*filename,
  * sure to update both bs->options (which has the full effective
  * options for bs) and options (which has file.* already removed).
  */
-qdict_put(bs->options, "driver", qstring_from_str(drv->format_name));
-qdict_put(options, "driver", qstring_from_str(drv->format_name));
+qdict_put_str(bs->options, "driver", drv->format_name);
+

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  15 guest-start.2fail REGR. vs. 107247

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

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  17cd6621688bce9972d924264fd7aba44c31
baseline version:
 xen  de5f36a266b41cafc47c876700a9c1a494aa296f

Last test of basis   107247  2017-04-06 15:46:51 Z5 days
Failing since107275  2017-04-07 17:57:44 Z4 days4 attempts
Testing same since   107359  2017-04-10 21:44:44 Z0 days1 attempts


People who touched revisions under test:
  Adrian Pop 
  Andre Przywara 
  Andrew Cooper 
  Chao Gao 
  Daniel De Graaf 
  Daniel Kiper 
  Dario Faggioli 
  Feng Wu 
  George Dunlap 
  Haozhong Zhang 
  Ian Jackson 
  Ian Jackson 
  Jan Beulich 
  Jan Beulich  [x86]
  Jonathan Davies 
  

[Xen-devel] [PATCH] xen: credit2: cleanup patch for type betterness

[Praveen Kumar]

The patch actually doesn't impact the functionality as such. This only replaces
bool_t with bool in credit2.

Signed-off-by: Praveen Kumar 
---
 xen/common/sched_credit2.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ee7b443f9e..1dfed923d3 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -639,17 +639,17 @@ static void deactivate_runqueue(struct csched2_private 
*prv, int rqi)
 __cpumask_clear_cpu(rqi, >active_queues);
 }
 
-static inline bool_t same_node(unsigned int cpua, unsigned int cpub)
+static inline bool same_node(unsigned int cpua, unsigned int cpub)
 {
 return cpu_to_node(cpua) == cpu_to_node(cpub);
 }
 
-static inline bool_t same_socket(unsigned int cpua, unsigned int cpub)
+static inline bool same_socket(unsigned int cpua, unsigned int cpub)
 {
 return cpu_to_socket(cpua) == cpu_to_socket(cpub);
 }
 
-static inline bool_t same_core(unsigned int cpua, unsigned int cpub)
+static inline bool same_core(unsigned int cpua, unsigned int cpub)
 {
 return same_socket(cpua, cpub) &&
cpu_to_core(cpua) == cpu_to_core(cpub);
@@ -1882,7 +1882,7 @@ static void migrate(const struct scheduler *ops,
  *  - svc is not already flagged to migrate,
  *  - if svc is allowed to run on at least one of the pcpus of rqd.
  */
-static bool_t vcpu_is_migrateable(struct csched2_vcpu *svc,
+static bool vcpu_is_migrateable(struct csched2_vcpu *svc,
   struct csched2_runqueue_data *rqd)
 {
 struct vcpu *v = svc->vcpu;
@@ -1900,7 +1900,7 @@ static void balance_load(const struct scheduler *ops, int 
cpu, s_time_t now)
 struct csched2_private *prv = csched2_priv(ops);
 int i, max_delta_rqi = -1;
 struct list_head *push_iter, *pull_iter;
-bool_t inner_load_updated = 0;
+bool inner_load_updated = 0;
 
 balance_state_t st = { .best_push_svc = NULL, .best_pull_svc = NULL };
 
@@ -2584,7 +2584,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
  */
 static struct task_slice
 csched2_schedule(
-const struct scheduler *ops, s_time_t now, bool_t tasklet_work_scheduled)
+const struct scheduler *ops, s_time_t now, bool tasklet_work_scheduled)
 {
 const int cpu = smp_processor_id();
 struct csched2_runqueue_data *rqd;
@@ -2592,7 +2592,7 @@ csched2_schedule(
 struct csched2_vcpu *snext = NULL;
 unsigned int skipped_vcpus = 0;
 struct task_slice ret;
-bool_t tickled;
+bool tickled;
 
 SCHED_STAT_CRANK(schedule);
 CSCHED2_VCPU_CHECK(current);
-- 
2.12.0


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

Re: [Xen-devel] [RFC XEN PATCH v2 00/15] Add vNVDIMM support to HVM domains

[Konrad Rzeszutek Wilk]

On Tue, Apr 04, 2017 at 11:59:03AM -0700, Dan Williams wrote:
> >> I don't think KVM has the same issue, but honestly I don't have the
> >> full mental model of how KVM supports mmap. I've at least been able to
> >> run a guest where the "pmem" is just dynamic page cache on the host
> >> side so the physical memory mapping is changing all the time due to
> >> swap. KVM does not have this third-party M2P mapping table to keep up
> >> to date so I assume it is just handled by the standard mmap support
> >> for establishing a guest physical address range and the standard
> >> mapping-invalidate + remap mechanism just works.
> >
> > Could it be possible to have an Xen driver that would listen on
> > these notifications and percolate those changes this driver. Then
> > this driver would make the appropiate hypercalls to update the M2P ?
> >
> > That would solve the 2/ I think?
> 
> I think that could work. That sounds like userfaultfd support for DAX
> which is something I want to take a look at in the next couple kernel
> cycles for other reasons like live migration of guest-VMs with DAX
> mappings.

I would need to educate myself a bit more about this.
But I just realized we lost Haozhong on this thread. Adding him back in,
perhaps he has more experience with that.

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 09/13] qobject: Use simpler QDict/QList scalar insertion macros

[Eric Blake]

On 04/11/2017 12:12 PM, Markus Armbruster wrote:
> Eric Blake  writes:
> 
>> We now have macros in place to make it less verbose to add a scalar
>> to QDict and QList, so use them.  To make this patch smaller to
>> review, a couple of subdirectories were done in earlier patches.
>>
>> Patch created mechanically via:
>>   spatch --sp-file scripts/coccinelle/qobject.cocci \
>> --macro-file scripts/cocci-macro-file.h --dir . --in-place
>> and needed only one touch-up in monitor.c to avoid a long line.
>>
>> Signed-off-by: Eric Blake 
>> ---
>>  block.c   | 45 +++--
>>  blockdev.c| 30 +-
>>  hw/block/xen_disk.c   |  2 +-
>>  hw/usb/xen-usb.c  | 12 ++--
>>  monitor.c | 23 +++
>>  qapi/qmp-event.c  |  2 +-
>>  qemu-img.c|  6 +++---
>>  qemu-io.c |  2 +-
>>  qemu-nbd.c|  2 +-
>>  qobject/qdict.c   |  2 +-
>>  target/s390x/cpu_models.c |  4 ++--
>>  util/qemu-option.c|  2 +-
>>  12 files changed, 60 insertions(+), 72 deletions(-)
> 
> Looks like you intent is to split the application of qobject.cocci into
> block [PATCH 07], tests [PATCH 08] and rest [PATCH 09, i.e. this one].
> Okay, although everything on one patch would also be okay for me.
> However, this patch also contains block stuff: block.c blockdev.c
> qemu-{img,io,nbd}.c.  Move to PATCH 07?

Can do either way, although I'd have to tweak the commit message's
sample command lines I used for the split if you like it kept separate.
Maybe even just a comment in patch 07 that 'only files under block/ are
touched here; other block-related patches will be fixed in the remaining
global cleanup'.

Do you have a preference?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Daniel Kiper]

On Tue, Apr 11, 2017 at 04:59:16PM +0200, Petr Tesarik wrote:
> On Tue, 11 Apr 2017 15:00:58 +0200
> Daniel Kiper  wrote:
>
> > On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > > On 03/04/17 14:42, Daniel Kiper wrote:
> > > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > > >> For kdump to work correctly it needs the physical address of
> > > >> vmcoreinfo_note. When running as dom0 this means the virtual address
> > > >> has to be translated to the related machine address.
> > > >>
> > > >> paddr_vmcoreinfo_note() is meant to do the translation via
> > > >> __pa_symbol() only, but being attributed "weak" it can be replaced
> > > >> easily in Xen case.
> > > >>
> > > >> Signed-off-by: Juergen Gross 
> > > >
> > > > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > > > hypervisor analysis work without any issue (at least basic commands
> > > > like dmesg, bt, ps, etc.)? If yes for both you can add:
> > > >
> > > > Reviewed-by: Daniel Kiper 
> > >
> > > So can I add your R-b: now?
> >
> > My R-b is still valid. Though, let's wait for Petr's Tested-by. He
> > did makedumpfile tests but I asked him to do crash tool tests too.
> > I think it is important.
>
> Tested-by: Petr Tesarik 
>
> I copied the complete /proc/vmcore to a directory on disk. Exactly
> as expected, crash works both without the patch and with the patch, as
> it does not use VMCOREINFO at all (instead, crash obtains the
> information from kernel debuginfo directly).

Thanks for doing the tests. I suppose that you have tested HVM guests.
IIRC, PV guests are not supported by crash right now due to p2m VMA
mapping. At least it was an issue some time ago. Is it still valid?
Anyway, one guy in Oracle works on fix for that issue and I do review.
We are going to post it in 2-3 weeks.

Juergen, I do not have any objections any longer. You can go ahead.
Ahhh... I see. You have posted v3. Good!

Daniel

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 09/13] qobject: Use simpler QDict/QList scalar insertion macros

[Markus Armbruster]

Eric Blake  writes:

> We now have macros in place to make it less verbose to add a scalar
> to QDict and QList, so use them.  To make this patch smaller to
> review, a couple of subdirectories were done in earlier patches.
>
> Patch created mechanically via:
>   spatch --sp-file scripts/coccinelle/qobject.cocci \
> --macro-file scripts/cocci-macro-file.h --dir . --in-place
> and needed only one touch-up in monitor.c to avoid a long line.
>
> Signed-off-by: Eric Blake 
> ---
>  block.c   | 45 +++--
>  blockdev.c| 30 +-
>  hw/block/xen_disk.c   |  2 +-
>  hw/usb/xen-usb.c  | 12 ++--
>  monitor.c | 23 +++
>  qapi/qmp-event.c  |  2 +-
>  qemu-img.c|  6 +++---
>  qemu-io.c |  2 +-
>  qemu-nbd.c|  2 +-
>  qobject/qdict.c   |  2 +-
>  target/s390x/cpu_models.c |  4 ++--
>  util/qemu-option.c|  2 +-
>  12 files changed, 60 insertions(+), 72 deletions(-)

Looks like you intent is to split the application of qobject.cocci into
block [PATCH 07], tests [PATCH 08] and rest [PATCH 09, i.e. this one].
Okay, although everything on one patch would also be okay for me.
However, this patch also contains block stuff: block.c blockdev.c
qemu-{img,io,nbd}.c.  Move to PATCH 07?

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

[Xen-devel] [linux-arm-xen test] 107296: trouble: broken/pass

[osstest service owner]

flight 107296 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107296/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken REGR. vs. 107176

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107176
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107176

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 linux9ceff47026d8db55dc9f133a40ae4042c71fcb13
baseline version:
 linux6878b2fa7229c9208a02d45f280c71389cba0617

Last test of basis   107176  2017-04-04 09:44:38 Z7 days
Failing since107256  2017-04-07 00:24:43 Z4 days2 attempts
Testing same since   107296  2017-04-08 07:12:44 Z3 days1 attempts


10162 people touched revisions under test,
not listing them all

jobs:
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-arm64  pass
 build-armhf  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-arm64-pvopspass
 build-armhf-pvopspass
 test-arm64-arm64-xl  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-arm64-arm64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-armhf-armhf-xl-arndale  broken  
 test-arm64-arm64-xl-credit2  pass
 test-armhf-armhf-xl-credit2

Re: [Xen-devel] [PATCH] xen: credit2: enable per cpu runqueue creation

[George Dunlap]

On 11/04/17 17:15, Praveen Kumar wrote:
> The patch introduces a new command line option 'cpu' that when used will 
> create
> runqueue per logical pCPU. This may be useful for small systems, and also for
> development, performance evalution and comparison.
> 
> Signed-off-by: Praveen Kumar 
> Reviewed-by: Dario Faggioli 

Praveen,

Unfortunately this didn't get checked in before the feature freeze -- I
think I may have dropped the ball on this one.

I'll queue this one up to be merged once the Xen 4.10 development window
opens.

 -George


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

[Xen-devel] ITS emulation: case for checking pending_irq against NULL

[Andre Przywara]

Hello,

this is trying to make the point that having NULL pointer entries in the
radix tree and letting Xen handle that is a valid case.
To some degree this serves as a tag (LPI has been unmapped), so should
semantically come close to what we are discussing.
It has the big advantage of being able to immediately clean up the
pending_irq and free it right away.

So I checked all call sites of irq_to_pending (see below). A number of
them is *not* used for LPIs (but only for SPIs, for instance). An LPI
number will never make it to those places.
A number of calls is already protected in patch 10/34 in the v7, and I
just added one case.
Interestingly all those calls use the retrieved pending_irq pointer
either already under the VCPU VGIC lock or can be easily moved under it
without changing any semantics. Since irq_to_pending right now was just
a wrapper around some static array lookup, so far we just didn't bother
with taking the lock before or after the irq_to_pending call. Changing
this now doesn't change anything for the existing code.

So this means that the pending_irq pointer is only retrieved and used
under the lock - which gives us the guarantee that it's always valid to
use. So as long as we hold the VGIC VCPU lock while we replace the radix
tree entry we can't never have a use-after-free race.

So this is the summary based on "git grep irq_to_pending":
xen/arch/arm/gic.c:
gic_route_irq_to_guest(): only called for SPIs
gic_remove_irq_from_guest(): only called for SPIs
gic_remove_from_queues(): PROTECTED, VCPU VGIC lock
gic_raise_inflight_irq(): PROTECTED, VCPU VGIC lock
gic_raise_guest_irq(): TO BE PROTECTED, VCPU VGIC lock
gic_update_one_lr(): PROTECTED, VCPU VGIC lock

xen/arch/arm/vgic.c:
vgic_migrate_irq(): not called for LPIs (not for virtual IRQs)
arch_move_irqs(): not iterating over LPIs
vgic_disable_irqs(): not called for LPIs
vgic_enable_irqs(): not called for LPIs
vgic_vcpu_inject_irq(): PROTECTED, moved under VCPU VGIC lock

xen/include/asm-arm/event.h:
local_events_need_delivery_nomask(): only called for a PPI

xen/include/asm-arm/vgic.h:
(prototype)

So here is the suggestion (yet another one, I know):
- DISCARD translates the DevID/EvID pair to a vCPU/vLPI pair. This is
done under the vcmd lock and ITS lock. We then lock the respective vCPU
VGIC lock, take the radix tree lock and remove the pending_irq from the
radix tree (making it read NULL), drop the radix tree lock and vCPU VGIC
lock again. We clean up the pending_irq (removing from lists) under the
lock still.
Any VGIC code either sees a valid pending_irq pointer (and uses it only
while holding the vCPU lock!) or a NULL pointer, and due to patch 10/34
can deal with this.
A VCPU returning will just clear the LR when it reads NULL (because
there is nothing to handle).

- MAPD(V=0) just does the above in a loop with every mapped event. At
the end it can safely free the pend_irq array.

I implemented that along with addressing the other comments and pushed
this to
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/its/v8-pre

Maybe we can use this as a discussion base?

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH v2] x86emul: add "unblock NMI" retire flag

[Andrew Cooper]

On 11/04/17 16:36, Jan Beulich wrote:
> No matter that we emulate IRET for (guest) real more only right now, we
> should get its effect on (virtual) NMI delivery right.
>
> Signed-off-by: Jan Beulich 
> ---
> v2: Adjust x86_emulate_wrapper() accordingly.
>
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
>  memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio->mmio_insn_bytes);
>  }
>  
> -if ( rc != X86EMUL_OKAY )
> -return rc;
> +new_intr_shadow = hvmemul_ctxt->intr_shadow;
>  
> -if ( hvmemul_ctxt->ctxt.retire.singlestep )
> -hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
> +/*
> + * IRET, if valid in the given context, clears NMI blocking
> + * (irrespective of rc).
> + */
> +if ( hvmemul_ctxt->ctxt.retire.unblock_nmi )
> +new_intr_shadow &= ~HVM_INTR_SHADOW_NMI;
>  
> -new_intr_shadow = hvmemul_ctxt->intr_shadow;
> +if ( rc == X86EMUL_OKAY )
> +{

On further thought, given the assertion, you don't need to introduce
this check, and can avoid the block indentation.  It should make the
patch rather smaller.

> +if ( hvmemul_ctxt->ctxt.retire.singlestep )
> +hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
>  
> -/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. */
> -if ( hvmemul_ctxt->ctxt.retire.mov_ss )
> -new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
> -else
> -new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
> -
> -/* STI instruction toggles STI shadow, else we just clear it. */
> -if ( hvmemul_ctxt->ctxt.retire.sti )
> -new_intr_shadow ^= HVM_INTR_SHADOW_STI;
> -else
> -new_intr_shadow &= ~HVM_INTR_SHADOW_STI;
> +/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. 
> */
> +if ( hvmemul_ctxt->ctxt.retire.mov_ss )
> +new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
> +else
> +new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
> +
> +/* STI instruction toggles STI shadow, else we just clear it. */
> +if ( hvmemul_ctxt->ctxt.retire.sti )
> +new_intr_shadow ^= HVM_INTR_SHADOW_STI;
> +else
> +new_intr_shadow &= ~HVM_INTR_SHADOW_STI;
> +}
>  
>  if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
>  {
> @@ -1981,13 +1988,11 @@ static int _hvm_emulate_one(struct hvm_e
>  hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
>  }
>  
> -if ( hvmemul_ctxt->ctxt.retire.hlt &&
> +if ( rc == X86EMUL_OKAY && hvmemul_ctxt->ctxt.retire.hlt &&
>   !hvm_local_events_need_delivery(curr) )

Similarly, you don't need the OKAY check here.

Otherwise, Reviewed-by: Andrew Cooper 

> -{
>  hvm_hlt(regs->eflags);
> -}
>  
> -return X86EMUL_OKAY;
> +return rc;
>  }
>  
>  int hvm_emulate_one(
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4002,6 +4002,7 @@ x86_emulate(
>  uint32_t mask = X86_EFLAGS_VIP | X86_EFLAGS_VIF | X86_EFLAGS_VM;
>  
>  fail_if(!in_realmode(ctxt, ops));
> +ctxt->retire.unblock_nmi = true;
>  if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
>, op_bytes, ctxt, ops)) ||
>   (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
> @@ -7918,9 +7919,17 @@ int x86_emulate_wrapper(
>  
>  rc = x86_emulate(ctxt, ops);
>  
> -/* Retire flags should only be set for successful instruction emulation. 
> */
> +/*
> + * Most retire flags should only be set for successful instruction
> + * emulation.
> + */
>  if ( rc != X86EMUL_OKAY )
> -ASSERT(ctxt->retire.raw == 0);
> +{
> +typeof(ctxt->retire) retire = ctxt->retire;
> +
> +retire.unblock_nmi = false;
> +ASSERT(!retire.raw);
> +}
>  
>  /* All cases returning X86EMUL_EXCEPTION should have fault semantics. */
>  if ( rc == X86EMUL_EXCEPTION )
> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
> @@ -490,6 +490,7 @@ struct x86_emulate_ctxt
>  bool hlt:1;  /* Instruction HLTed. */
>  bool mov_ss:1;   /* Instruction sets MOV-SS irq shadow. */
>  bool sti:1;  /* Instruction sets STI irq shadow. */
> +bool unblock_nmi:1;  /* Instruction clears NMI blocking. */
>  bool singlestep:1;   /* Singlestepping was active. */
>  };
>  } retire;
>
>


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

[Xen-devel] [PATCH] xen: credit2: enable per cpu runqueue creation

[Praveen Kumar]

The patch introduces a new command line option 'cpu' that when used will create
runqueue per logical pCPU. This may be useful for small systems, and also for
development, performance evalution and comparison.

Signed-off-by: Praveen Kumar 
Reviewed-by: Dario Faggioli 

---
 docs/misc/xen-command-line.markdown |  3 ++-
 xen/common/sched_credit2.c  | 15 +++
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 5815d87dab..6e73766574 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -525,7 +525,7 @@ also slow in responding to load changes.
 The default value of `1 sec` is rather long.
 
 ### credit2\_runqueue
-> `= core | socket | node | all`
+> `= cpu | core | socket | node | all`
 
 > Default: `socket`
 
@@ -536,6 +536,7 @@ balancing (for instance, it will deal better with 
hyperthreading),
 but also more overhead.
 
 Available alternatives, with their meaning, are:
+* `cpu`: one runqueue per each logical pCPUs of the host;
 * `core`: one runqueue per each physical core of the host;
 * `socket`: one runqueue per each physical socket (which often,
 but not always, matches a NUMA node) of the host;
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index bb1c657e76..ee7b443f9e 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -301,6 +301,9 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  * want that to happen basing on topology. At the moment, it is possible
  * to choose to arrange runqueues to be:
  *
+ * - per-cpu: meaning that there will be one runqueue per logical cpu. This
+ *will happen when if the opt_runqueue parameter is set to 'cpu'.
+ *
  * - per-core: meaning that there will be one runqueue per each physical
  * core of the host. This will happen if the opt_runqueue
  * parameter is set to 'core';
@@ -322,11 +325,13 @@ integer_param("credit2_balance_over", 
opt_overload_balance_tolerance);
  * either the same physical core, the same physical socket, the same NUMA
  * node, or just all of them, will be put together to form runqueues.
  */
-#define OPT_RUNQUEUE_CORE   0
-#define OPT_RUNQUEUE_SOCKET 1
-#define OPT_RUNQUEUE_NODE   2
-#define OPT_RUNQUEUE_ALL3
+#define OPT_RUNQUEUE_CPU0
+#define OPT_RUNQUEUE_CORE   1
+#define OPT_RUNQUEUE_SOCKET 2
+#define OPT_RUNQUEUE_NODE   3
+#define OPT_RUNQUEUE_ALL4
 static const char *const opt_runqueue_str[] = {
+[OPT_RUNQUEUE_CPU] = "cpu",
 [OPT_RUNQUEUE_CORE] = "core",
 [OPT_RUNQUEUE_SOCKET] = "socket",
 [OPT_RUNQUEUE_NODE] = "node",
@@ -682,6 +687,8 @@ cpu_to_runqueue(struct csched2_private *prv, unsigned int 
cpu)
 BUG_ON(cpu_to_socket(cpu) == XEN_INVALID_SOCKET_ID ||
cpu_to_socket(peer_cpu) == XEN_INVALID_SOCKET_ID);
 
+if (opt_runqueue == OPT_RUNQUEUE_CPU)
+continue;
 if ( opt_runqueue == OPT_RUNQUEUE_ALL ||
  (opt_runqueue == OPT_RUNQUEUE_CORE && same_core(peer_cpu, cpu)) ||
  (opt_runqueue == OPT_RUNQUEUE_SOCKET && same_socket(peer_cpu, 
cpu)) ||
-- 
2.12.0


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

[Xen-devel] [PATCH v3] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Juergen Gross]

For kdump to work correctly it needs the physical address of
vmcoreinfo_note. When running as dom0 this means the virtual address
has to be translated to the related machine address.

paddr_vmcoreinfo_note() is meant to do the translation via
__pa_symbol() only, but being attributed "weak" it can be replaced
easily in Xen case.

Signed-off-by: Juergen Gross 
Tested-by: Petr Tesarik 
Reviewed-by: Boris Ostrovsky 
Reviewed-by: Daniel Kiper 
---
Changes in V3:
- rebased to recent Xen patches

Changes in V2:
- use __pa_symbol() (Boris Ostrovsky)
- remove unneeded casts (Jan Beulich)
---
 arch/x86/xen/mmu_pv.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c
index 284d189f40dd..9657187bc7bd 100644
--- a/arch/x86/xen/mmu_pv.c
+++ b/arch/x86/xen/mmu_pv.c
@@ -49,6 +49,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_KEXEC_CORE
+#include 
+#endif
 
 #include 
 
@@ -2715,3 +2718,13 @@ 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);
+
+#ifdef CONFIG_KEXEC_CORE
+phys_addr_t paddr_vmcoreinfo_note(void)
+{
+   if (xen_pv_domain())
+   return virt_to_machine(_note).maddr;
+   else
+   return __pa_symbol(_note);
+}
+#endif /* CONFIG_KEXEC_CORE */
-- 
2.12.0


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

Re: [Xen-devel] [PATCH v5 23/30] ARM: vITS: handle MAPTI command

[Andre Przywara]

Hi,

On 06/04/17 01:45, Stefano Stabellini wrote:
> On Thu, 6 Apr 2017, Andre Przywara wrote:
>> The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
>> pair and actually instantiates LPI interrupts.
>> We connect the already allocated host LPI to this virtual LPI, so that
>> any triggering LPI on the host can be quickly forwarded to a guest.
>> Beside entering the VCPU and the virtual LPI number in the respective
>> host LPI entry, we also initialize and add the already allocated
>> struct pending_irq to our radix tree, so that we can now easily find it
>> by its virtual LPI number.
>> To be able to later find the targetting VCPU for any given LPI without
>> having to walk *all* ITS tables, we store the VCPU ID in the pending_irq
>> struct as well.
>> This exports the vgic_init_pending_irq() function to be able to
>> initialize a new struct pending_irq.
>> As write_itte() is now eventually used, we can now add the static tag.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-v3-its.c| 74 ++
>>  xen/arch/arm/gic-v3-lpi.c| 18 ++
>>  xen/arch/arm/vgic-v3-its.c   | 76 
>> ++--
>>  xen/arch/arm/vgic.c  |  2 +-
>>  xen/include/asm-arm/gic_v3_its.h |  6 
>>  xen/include/asm-arm/vgic.h   |  2 ++
>>  6 files changed, 175 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>> index 76b0316..d970119 100644
>> --- a/xen/arch/arm/gic-v3-its.c
>> +++ b/xen/arch/arm/gic-v3-its.c
>> @@ -777,6 +777,80 @@ out:
>>  return ret;
>>  }
>>  
>> +/* Must be called with the its_device_lock held. */
>> +static struct its_devices *get_its_device(struct domain *d, paddr_t 
>> vdoorbell,
>> +  uint32_t vdevid)
>> +{
>> +struct rb_node *node = d->arch.vgic.its_devices.rb_node;
>> +struct its_devices *dev;
>> +
>> +ASSERT(spin_is_locked(>arch.vgic.its_devices_lock));
>> +
>> +while (node)
>> +{
>> +int cmp;
>> +
>> +dev = rb_entry(node, struct its_devices, rbnode);
>> +cmp = compare_its_guest_devices(dev, vdoorbell, vdevid);
>> +
>> +if ( !cmp )
>> +return dev;
>> +
>> +if ( cmp > 0 )
>> +node = node->rb_left;
>> +else
>> +node = node->rb_right;
>> +}
>> +
>> +return NULL;
>> +}
>> +
>> +static uint32_t get_host_lpi(struct its_devices *dev, uint32_t eventid)
>> +{
>> +uint32_t host_lpi = 0;
>> +
>> +if ( dev && (eventid < dev->eventids) )
>> +host_lpi = dev->host_lpi_blocks[eventid / LPI_BLOCK] +
>> +   (eventid % LPI_BLOCK);
>> +
>> +return host_lpi;
>> +}
>> +
>> +/*
>> + * Connects the event ID for an already assigned device to the given 
>> VCPU/vLPI
>> + * pair. The corresponding physical LPI is already mapped on the host side
>> + * (when assigning the physical device to the guest), so we just connect the
>> + * target VCPU/vLPI pair to that interrupt to inject it properly if it 
>> fires.
>> + * Returns a pointer to the already allocated struct pending_irq that is
>> + * meant to be used by that event.
>> + */
>> +struct pending_irq *gicv3_assign_guest_event(struct domain *d,
>> + paddr_t vdoorbell_address,
>> + uint32_t vdevid, uint32_t 
>> veventid,
>> + struct vcpu *v, uint32_t 
>> virt_lpi)
>> +{
>> +struct its_devices *dev;
>> +struct pending_irq *pirq = NULL;
>> +uint32_t host_lpi = 0;
>> +
>> +spin_lock(>arch.vgic.its_devices_lock);
>> +dev = get_its_device(d, vdoorbell_address, vdevid);
>> +if ( dev )
>> +{
>> +host_lpi = get_host_lpi(dev, veventid);
>> +pirq = >pend_irqs[veventid];
>> +}
>> +spin_unlock(>arch.vgic.its_devices_lock);
>> +
>> +if ( !host_lpi || !pirq )
>> +return NULL;
>> +
>> +gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
>> +v ? v->vcpu_id : INVALID_VCPU_ID, virt_lpi);
>> +
>> +return pirq;
>> +}
>> +
>>  /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. 
>> */
>>  void gicv3_its_dt_init(const struct dt_device_node *node)
>>  {
>> diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
>> index 7d20986..c997ed5 100644
>> --- a/xen/arch/arm/gic-v3-lpi.c
>> +++ b/xen/arch/arm/gic-v3-lpi.c
>> @@ -216,6 +216,24 @@ void gicv3_do_LPI(unsigned int lpi)
>>  rcu_unlock_domain(d);
>>  }
>>  
>> +void gicv3_lpi_update_host_entry(uint32_t host_lpi, int domain_id,
>> + unsigned int vcpu_id, uint32_t virt_lpi)
>> +{
>> +union host_lpi *hlpip, hlpi;
>> +
>> +ASSERT(host_lpi >= LPI_OFFSET);
>> +
>> +host_lpi -= LPI_OFFSET;
>> +
>> +hlpip = _data.host_lpis[host_lpi 

Re: [Xen-devel] [PATCH v10 17/25] x86: refactor psr: CDP: implement set value callback functions.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> @@ -94,6 +102,13 @@ struct feat_node {
>  unsigned int cos_max;
>  unsigned int cbm_len;
>  
> +/*
> + * An array to save all 'enum cbm_type' values of the feature. It is
> + * used with cos_num together to get/write a feature's COS registers
> + * values one by one.
> + */
> +enum cbm_type type[PSR_MAX_COS_NUM];

So here it finally comes. But it's needed the latest in the first CDP
patch, quite possibly even earlier.

> +static int compare_val(const uint32_t val[],
> +   const struct feat_node *feat,
> +   unsigned int cos)
> +{
> +int rc = 0;

The variable deserves a better name and type bool, according to its
usage. But I'm unconvinced the variable is needed at all - I think
without it the intention of the function would be more clear. See
remarks further down.

> +unsigned int i;
> +
> +for ( i = 0; i < feat->props->cos_num; i++ )
> +{
> +uint32_t feat_val = 0;

Pointless initializer again.

> +rc = 0;
> +
> +/* If cos is bigger than cos_max, we need compare default value. */
> +if ( cos > feat->props->cos_max )
> +{
> +/*
> + * COS ID 0 always stores the default value so input 0 to get
> + * default value.
> + */
> +feat->props->get_val(feat, 0, feat->props->type[i], _val);
> +
> +/*
> + * If cos is bigger than feature's cos_max, the val should be
> + * default value. Otherwise, it fails to find a COS ID. So we
> + * have to exit find flow.
> + */
> +if ( val[i] != feat_val )
> +return -EINVAL;
> +
> +rc = 1;
> +continue;

Drop these two.

> +}

else
{

> +
> +/* For CDP, DATA is the first item in val[], CODE is the second. */
> +feat->props->get_val(feat, cos, feat->props->type[i], _val);
> +if ( val[i] != feat_val )
> +break;

return 0;
}

> +
> +rc = 1;

Drop.

> +}
> +
> +return rc;

return 1;

> @@ -851,43 +948,21 @@ static int find_cos(const uint32_t val[], unsigned int 
> array_len,
>   */
>  for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
>  {
> -uint32_t default_val = 0;
> -
>  feat = info->features[i];
>  if ( !feat )
>  continue;
>  
>  /*
> - * COS ID 0 always stores the default value so input 0 to get
> - * default value.
> - */
> -feat->props->get_val(feat, 0, 0, _val);
> -
> -/*
>   * Compare value according to feature array order.
>   * We must follow this order because value array is assembled
>   * as this order.
>   */
> -if ( cos > feat->props->cos_max )
> -{
> -/*
> - * If cos is bigger than feature's cos_max, the val should be
> - * default value. Otherwise, it fails to find a COS ID. So we
> - * have to exit find flow.
> - */
> -if ( val[0] != default_val )
> -return -EINVAL;
> -
> -found = true;
> -}
> -else
> -{
> -if ( val[0] == feat->cos_reg_val[cos] )
> -found = true;
> -}
> +rc = compare_val(val, feat, cos);

Why is this being moved into a function here rather than being
introduced as a function right away?

> @@ -922,9 +997,14 @@ static bool fits_cos_max(const uint32_t val[],
>  
>  if ( cos > feat->props->cos_max )
>  {
> -feat->props->get_val(feat, 0, 0, _val);
> -if ( val[0] != default_val )
> -return false;
> +/* For CDP, DATA is the first item in val[], CODE is the second. 
> */

This CDP specific comment doesn't belong into a generic function.

> @@ -1033,6 +1116,40 @@ static int write_psr_msr(unsigned int socket, unsigned 
> int cos,
>  return 0;
>  }
>  
> +static void restore_default_val(unsigned int socket, unsigned int cos,
> +enum psr_feat_type feat_type)
> +{
> +unsigned int i, j;
> +uint32_t default_val;
> +const struct psr_socket_info *info = get_socket_info(socket);
> +
> +for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
> +{
> +const struct feat_node *feat = info->features[i];

Blank line here.

> +/*
> + * There are four judgements:
> + * 1. Input 'feat_type' is valid so we have to get feature according 
> to
> + *it. If current feature type (i) does not match 'feat_type', we
> + *need skip it, so continue to check next feature.
> + * 2. Input 'feat_type' is 'PSR_SOCKET_MAX_FEAT' which means 

Re: [Xen-devel] [PATCH v6 24/36] ARM: vITS: add command handling stub and MMIO emulation

[Andre Przywara]

Hi,

On 09/04/17 21:16, Julien Grall wrote:
> Hi Andre,
> 
> On 04/07/2017 06:32 PM, Andre Przywara wrote:
>> Emulate the memory mapped ITS registers and provide a stub to introduce
>> the ITS command handling framework (but without actually emulating any
>> commands at this time).
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/vgic-v3-its.c   | 512
>> +++
>>  xen/include/asm-arm/gic_v3_its.h |   3 +
>>  2 files changed, 515 insertions(+)
>>
>> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
>> index 065ffe2..a171a3b 100644
>> --- a/xen/arch/arm/vgic-v3-its.c
>> +++ b/xen/arch/arm/vgic-v3-its.c
>> @@ -67,6 +67,9 @@ struct vits_itte
>>  uint16_t pad;
>>  };
>>
>> +#define GITS_BASER_RO_MASK   (GITS_BASER_TYPE_MASK | \
>> +  (31UL << GITS_BASER_ENTRY_SIZE_SHIFT))
>> +
>>  int vgic_v3_its_init_domain(struct domain *d)
>>  {
>>  spin_lock_init(>arch.vgic.its_devices_lock);
>> @@ -80,6 +83,515 @@ void vgic_v3_its_free_domain(struct domain *d)
>>  ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
>>  }
>>
>> +/**
>> + * Functions that handle ITS commands *
>> + **/
>> +
>> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd, unsigned int word,
>> +   unsigned int shift, unsigned int
>> size)
>> +{
>> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
>> +}
>> +
>> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0, 
>> 0,  8)
>> +#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0,
>> 32, 32)
>> +#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1, 
>> 0,  5)
>> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1, 
>> 0, 32)
>> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1,
>> 32, 32)
>> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2, 
>> 0, 16)
>> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2,
>> 16, 32)
>> +#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2,
>> 63,  1)
>> +#define its_cmd_get_ittaddr(cmd)(its_cmd_mask_field(cmd, 2,
>> 8, 44) << 8)
>> +
>> +#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>> +
>> +/*
>> + * Requires the vcmd_lock to be held.
>> + * TODO: Investigate whether we can be smarter here and don't need to
>> hold
>> + * the lock all of the time.
>> + */
>> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its)
>> +{
>> +paddr_t addr = its->cbaser & GENMASK(51, 12);
>> +uint64_t command[4];
>> +uint64_t creadr = its->creadr;
>> +
>> +ASSERT(spin_is_locked(>vcmd_lock));
>> +
>> +if ( its->cwriter >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
>> +return -1;
>> +
>> +while ( creadr != its->cwriter )
>> +{
>> +int ret;
>> +
>> +ret = vgic_access_guest_memory(d, addr + creadr,
>> +   command, sizeof(command), false);
>> +if ( ret )
>> +return ret;
>> +
>> +switch ( its_cmd_get_command(command) )
>> +{
>> +case GITS_CMD_SYNC:
>> +/* We handle ITS commands synchronously, so we ignore
>> SYNC. */
>> +break;
>> +default:
>> +gdprintk(XENLOG_WARNING, "ITS: unhandled ITS command %lu\n",
>> + its_cmd_get_command(command));
>> +break;
>> +}
>> +
>> +creadr += ITS_CMD_SIZE;
>> +if ( creadr == ITS_CMD_BUFFER_SIZE(its->cbaser) )
>> +creadr = 0;
>> +its->creadr = creadr;   /* allow the guest to see the
>> progress */
> 
> I hope you know that the compiler can decide to drop the temporary
> variable for optimization? ;) So it may decide to write-back everytime
> in its->creadr.

I don't think it can do it, because creadr is different from its->creadr
here (on purpose!). So doing this optimization would violate the program
semantic (because the end-of-buffer value would never be visible).

But just to be sure I replaced this check with a modulo operation over
the ITS_CMD_BUFFER_SIZE.
Not sure everyone likes *that* now, though ;-)

Cheers,
Andre.

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

Re: [Xen-devel] [PATCH v10 16/25] x86: refactor psr: CDP: implement get value flow.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> @@ -755,7 +765,7 @@ static int gather_val_array(uint32_t val[],
>  cos = 0;
>  
>  /* Value getting order is same as feature array. */
> -feat->props->get_val(feat, cos, [0]);
> +feat->props->get_val(feat, cos, 0, [0]);

How can this be literal zero here (and in further cases below)?

Jan


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

[Xen-devel] [PATCH v2] x86emul: add "unblock NMI" retire flag

[Jan Beulich]

No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right.

Signed-off-by: Jan Beulich 
---
v2: Adjust x86_emulate_wrapper() accordingly.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
 memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio->mmio_insn_bytes);
 }
 
-if ( rc != X86EMUL_OKAY )
-return rc;
+new_intr_shadow = hvmemul_ctxt->intr_shadow;
 
-if ( hvmemul_ctxt->ctxt.retire.singlestep )
-hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+/*
+ * IRET, if valid in the given context, clears NMI blocking
+ * (irrespective of rc).
+ */
+if ( hvmemul_ctxt->ctxt.retire.unblock_nmi )
+new_intr_shadow &= ~HVM_INTR_SHADOW_NMI;
 
-new_intr_shadow = hvmemul_ctxt->intr_shadow;
+if ( rc == X86EMUL_OKAY )
+{
+if ( hvmemul_ctxt->ctxt.retire.singlestep )
+hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
 
-/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. */
-if ( hvmemul_ctxt->ctxt.retire.mov_ss )
-new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
-else
-new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
-
-/* STI instruction toggles STI shadow, else we just clear it. */
-if ( hvmemul_ctxt->ctxt.retire.sti )
-new_intr_shadow ^= HVM_INTR_SHADOW_STI;
-else
-new_intr_shadow &= ~HVM_INTR_SHADOW_STI;
+/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. */
+if ( hvmemul_ctxt->ctxt.retire.mov_ss )
+new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
+else
+new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
+
+/* STI instruction toggles STI shadow, else we just clear it. */
+if ( hvmemul_ctxt->ctxt.retire.sti )
+new_intr_shadow ^= HVM_INTR_SHADOW_STI;
+else
+new_intr_shadow &= ~HVM_INTR_SHADOW_STI;
+}
 
 if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
 {
@@ -1981,13 +1988,11 @@ static int _hvm_emulate_one(struct hvm_e
 hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
 }
 
-if ( hvmemul_ctxt->ctxt.retire.hlt &&
+if ( rc == X86EMUL_OKAY && hvmemul_ctxt->ctxt.retire.hlt &&
  !hvm_local_events_need_delivery(curr) )
-{
 hvm_hlt(regs->eflags);
-}
 
-return X86EMUL_OKAY;
+return rc;
 }
 
 int hvm_emulate_one(
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4002,6 +4002,7 @@ x86_emulate(
 uint32_t mask = X86_EFLAGS_VIP | X86_EFLAGS_VIF | X86_EFLAGS_VM;
 
 fail_if(!in_realmode(ctxt, ops));
+ctxt->retire.unblock_nmi = true;
 if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
   , op_bytes, ctxt, ops)) ||
  (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
@@ -7918,9 +7919,17 @@ int x86_emulate_wrapper(
 
 rc = x86_emulate(ctxt, ops);
 
-/* Retire flags should only be set for successful instruction emulation. */
+/*
+ * Most retire flags should only be set for successful instruction
+ * emulation.
+ */
 if ( rc != X86EMUL_OKAY )
-ASSERT(ctxt->retire.raw == 0);
+{
+typeof(ctxt->retire) retire = ctxt->retire;
+
+retire.unblock_nmi = false;
+ASSERT(!retire.raw);
+}
 
 /* All cases returning X86EMUL_EXCEPTION should have fault semantics. */
 if ( rc == X86EMUL_EXCEPTION )
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -490,6 +490,7 @@ struct x86_emulate_ctxt
 bool hlt:1;  /* Instruction HLTed. */
 bool mov_ss:1;   /* Instruction sets MOV-SS irq shadow. */
 bool sti:1;  /* Instruction sets STI irq shadow. */
+bool unblock_nmi:1;  /* Instruction clears NMI blocking. */
 bool singlestep:1;   /* Singlestepping was active. */
 };
 } retire;


x86emul: add "unblock NMI" retire flag

No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right.

Signed-off-by: Jan Beulich 
---
v2: Adjust x86_emulate_wrapper() accordingly.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
 memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio->mmio_insn_bytes);
 }
 
-if ( rc != X86EMUL_OKAY )
-return rc;
+new_intr_shadow = hvmemul_ctxt->intr_shadow;
 
-if ( hvmemul_ctxt->ctxt.retire.singlestep )
-hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+/*
+ * IRET, if valid in the given context, clears NMI blocking
+ * (irrespective of rc).
+ */
+if ( hvmemul_ctxt->ctxt.retire.unblock_nmi )
+

Re: [Xen-devel] [PATCH v10 13/25] x86: refactor psr: L3 CAT: set value: implement write msr flow.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> +static void do_write_psr_msr(void *data)
> +{
> +struct cos_write_info *info = data;
> +unsigned int cos= info->cos;
> +struct feat_node *feat  = info->feature;
> +
> +if ( cos > feat->props->cos_max )
> +return;

This check can as well be done in the caller, allowing to avoid the IPI
in case it's true.

> +feat->props->write_msr(cos, info->val, feat);

Once the function consists of just this I wonder if it wasn't better
to invoke the hook directly from write_psr_msr().

Jan


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

Re: [Xen-devel] [PATCH v10 12/25] x86: refactor psr: L3 CAT: set value: implement cos id picking flow.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -800,15 +800,82 @@ static int find_cos(const uint32_t val[], unsigned int 
> array_len,
>  return -ENOENT;
>  }
>  
> +static bool fits_cos_max(const uint32_t val[],
> + uint32_t array_len,
> + const struct psr_socket_info *info,
> + unsigned int cos)
> +{
> +unsigned int i;
> +
> +for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
> +{
> +uint32_t default_val = 0;

Move this into the most narrow scope it's needed in, which will make
pretty clear that the initializer again isn't needed.

> +const struct feat_node *feat = info->features[i];
> +if ( !feat )
> +continue;
> +
> +if ( array_len < feat->props->cos_num )
> +return false;
> +
> +if ( cos > feat->props->cos_max )
> +{
> +feat->props->get_val(feat, 0, _val);
> +if ( val[0] != default_val )

Same question as before.

Jan


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

Re: [Xen-devel] [PATCH v10 11/25] x86: refactor psr: L3 CAT: set value: implement cos finding flow.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -720,8 +720,83 @@ static int find_cos(const uint32_t val[], unsigned int 
> array_len,
>  const struct psr_socket_info *info,
>  spinlock_t *ref_lock)
>  {
> +unsigned int cos, i;
> +const unsigned int *ref = info->cos_ref;
> +const struct feat_node *feat;
> +unsigned int cos_max;
> +
>  ASSERT(spin_is_locked(ref_lock));
>  
> +/* cos_max is the one of the feature which is being set. */
> +feat = info->features[feat_type];
> +if ( !feat )
> +return -ENOENT;
> +
> +cos_max = feat->props->cos_max;
> +
> +for ( cos = 0; cos <= cos_max; cos++ )
> +{
> +const uint32_t *val_ptr = val;
> +bool found = false;
> +
> +if ( cos && !ref[cos] )
> +continue;
> +
> +/*
> + * If fail to find cos in below loop, need find whole feature array
> + * again from beginning.
> + */

This comment is unrelated to any of the immediately surrounding
code. Either move it, or get rid of it altogether.

> +for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
> +{
> +uint32_t default_val = 0;

Pointless initializer as it seems.

> +feat = info->features[i];
> +if ( !feat )
> +continue;
> +
> +/*
> + * COS ID 0 always stores the default value so input 0 to get
> + * default value.
> + */
> +feat->props->get_val(feat, 0, _val);
> +
> +/*
> + * Compare value according to feature array order.
> + * We must follow this order because value array is assembled
> + * as this order.
> + */
> +if ( cos > feat->props->cos_max )
> +{
> +/*
> + * If cos is bigger than feature's cos_max, the val should be
> + * default value. Otherwise, it fails to find a COS ID. So we
> + * have to exit find flow.
> + */
> +if ( val[0] != default_val )
> +return -EINVAL;
> +
> +found = true;
> +}
> +else
> +{
> +if ( val[0] == feat->cos_reg_val[cos] )
> +found = true;
> +}

Same question as on previous patch- why val[0] twice above,
despite cos_num possibly being larger than 1? And wouldn't this
need to be val_ptr anyway?

> +/* If fail to match, go to next cos to compare. */
> +if ( !found )
> +break;
> +
> +val_ptr += feat->props->cos_num;
> +if ( val_ptr - val > array_len )
> +return -ENOSPC;

This again looks suspicious - the check should once again be done
before accessing the respective array element(s).

Jan


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

Re: [Xen-devel] [PATCH v10 10/25] x86: refactor psr: L3 CAT: set value: assemble features value array.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> @@ -593,7 +616,21 @@ int psr_get_val(struct domain *d, unsigned int socket,
>  /* Set value functions */
>  static unsigned int get_cos_num(const struct psr_socket_info *info)
>  {
> -return 0;
> +unsigned int num = 0, i;
> +
> +/* Get all features total amount. */
> +for ( i = 0; i < PSR_SOCKET_MAX_FEAT; i++ )
> +{
> +const struct feat_node *feat = info->features[i];
> +if ( !feat )

Blank line between ... (and I likely won't repeat this any further)

> +continue;
> +
> +feat = info->features[i];

???

> @@ -611,7 +679,40 @@ static int insert_val_to_array(uint32_t val[],
> enum cbm_type type,
> uint32_t new_val)
>  {
> -return -EINVAL;
> +const struct feat_node *feat;
> +unsigned int i;
> +
> +ASSERT(feat_type < PSR_SOCKET_MAX_FEAT);
> +
> +/* Insert new value into array according to feature's position in array. 
> */
> +for ( i = 0; i < feat_type; i++ )
> +{
> +feat = info->features[i];
> +if ( !feat )
> +continue;
> +
> +if ( array_len <= feat->props->cos_num )
> +return -ENOSPC;
> +
> +array_len -= feat->props->cos_num;
> +
> +val += feat->props->cos_num;
> +}
> +
> +feat = info->features[feat_type];
> +if ( !feat )
> +return -ENOENT;
> +
> +if ( array_len < feat->props->cos_num )
> +return -ENOSPC;
> +
> +if ( !psr_check_cbm(feat->props->cbm_len, new_val) )
> +return -EINVAL;
> +
> +/* Value setting position is same as feature array. */
> +val[0] = new_val;

How come this is array index 0 unconditionally, when cos_num
may be greater than 1?

Jan


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

Re: [Xen-devel] [PATCH v10 09/25] x86: refactor psr: L3 CAT: set value: implement framework.

[Jan Beulich]

>>> On 01.04.17 at 15:53,  wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -157,10 +157,26 @@ static void free_socket_resources(unsigned int socket)
>  {
>  unsigned int i;
>  struct psr_socket_info *info = socket_info + socket;
> +struct domain *d;
>  
>  if ( !info )
>  return;
>  
> +/* Restore domain cos id to 0 when socket is offline. */
> +for_each_domain ( d )
> +{
> +unsigned int cos = d->arch.psr_cos_ids[socket];
> +if ( cos == 0 )

Blank line between declaration(s) and statement(s) please.

> +continue;
> +
> +spin_lock(>ref_lock);
> +ASSERT(!cos || info->cos_ref[cos]);

You've checked cos to be non-zero already above.

> +info->cos_ref[cos]--;
> +spin_unlock(>ref_lock);
> +
> +d->arch.psr_cos_ids[socket] = 0;
> +}

Overall, while you say in the revision log that this was a suggestion of
mine, I don't recall any such (and I've just checked the v9 thread of
this patch without finding anything), and hence it's not really clear to
me why this is needed. After all you should be freeing info anyway
(albeit I can't see this happening, which would look to be a bug in
patch 5), so getting the refcounts adjusted seems pointless in any
event. Whether d->arch.psr_cos_ids[socket] needs clearing I'm not
certain - this may indeed by unavoidable, to match up with
psr_alloc_cos() using xzalloc.

Furthermore I'm not at all convinced this is appropriate to do in the
context of a CPU_UP_CANCELED / CPU_DEAD notification: If you
have a few thousand VMs, the loop above may take a while.

> @@ -574,15 +590,210 @@ int psr_get_val(struct domain *d, unsigned int socket,
>  return 0;
>  }
>  
> -int psr_set_l3_cbm(struct domain *d, unsigned int socket,
> -   uint64_t cbm, enum cbm_type type)
> +/* Set value functions */
> +static unsigned int get_cos_num(const struct psr_socket_info *info)
>  {
>  return 0;
>  }
>  
> +static int gather_val_array(uint32_t val[],
> +unsigned int array_len,
> +const struct psr_socket_info *info,
> +unsigned int old_cos)
> +{
> +return -EINVAL;
> +}
> +
> +static int insert_val_to_array(uint32_t val[],

As indicated before, I'm pretty convinced "into" would be more
natural than "to".

> +   unsigned int array_len,
> +   const struct psr_socket_info *info,
> +   enum psr_feat_type feat_type,
> +   enum cbm_type type,
> +   uint32_t new_val)
> +{
> +return -EINVAL;
> +}
> +
> +static int find_cos(const uint32_t val[], unsigned int array_len,
> +enum psr_feat_type feat_type,
> +const struct psr_socket_info *info,
> +spinlock_t *ref_lock)

I don't think I did suggest adding another parameter here. The lock
is accessible from info, isn't it? In which case, as I _did_ suggest,
you should drop const from it instead. But ...

> +{
> +ASSERT(spin_is_locked(ref_lock));

... the assertion seems rather pointless anyway with there just
being a single caller, which very visibly acquires the lock up front.

> +static int pick_avail_cos(const struct psr_socket_info *info,
> +  spinlock_t *ref_lock,

Same here then.

> +int psr_set_val(struct domain *d, unsigned int socket,
> +uint32_t val, enum cbm_type type)
> +{
> +unsigned int old_cos;
> +int cos, ret;
> +unsigned int *ref;
> +uint32_t *val_array;
> +struct psr_socket_info *info = get_socket_info(socket);
> +unsigned int array_len;
> +enum psr_feat_type feat_type;
> +
> +if ( IS_ERR(info) )
> +return PTR_ERR(info);
> +
> +feat_type = psr_cbm_type_to_feat_type(type);
> +if ( feat_type > ARRAY_SIZE(info->features) ||

I think I did point out the off-by-one mistake here in an earlier patch
already.

> + !info->features[feat_type] )
> +return -ENOENT;
> +
> +/*
> + * Step 0:
> + * old_cos means the COS ID current domain is using. By default, it is 0.
> + *
> + * For every COS ID, there is a reference count to record how many 
> domains
> + * are using the COS register corresponding to this COS ID.
> + * - If ref[old_cos] is 0, that means this COS is not used by any domain.
> + * - If ref[old_cos] is 1, that means this COS is only used by current
> + *   domain.
> + * - If ref[old_cos] is more than 1, that mean multiple domains are using
> + *   this COS.
> + */
> +old_cos = d->arch.psr_cos_ids[socket];
> +ASSERT(old_cos < MAX_COS_REG_CNT);
> +
> +ref = info->cos_ref;
> +
> +/*
> + * Step 1:
> + * Gather a value array to store all features cos_reg_val[old_cos].
> + * And, set the input new val into array according to 

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Petr Tesarik]

On Tue, 11 Apr 2017 15:00:58 +0200
Daniel Kiper  wrote:

> On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> > On 03/04/17 14:42, Daniel Kiper wrote:
> > > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> > >> For kdump to work correctly it needs the physical address of
> > >> vmcoreinfo_note. When running as dom0 this means the virtual address
> > >> has to be translated to the related machine address.
> > >>
> > >> paddr_vmcoreinfo_note() is meant to do the translation via
> > >> __pa_symbol() only, but being attributed "weak" it can be replaced
> > >> easily in Xen case.
> > >>
> > >> Signed-off-by: Juergen Gross 
> > >
> > > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > > hypervisor analysis work without any issue (at least basic commands
> > > like dmesg, bt, ps, etc.)? If yes for both you can add:
> > >
> > > Reviewed-by: Daniel Kiper 
> >
> > So can I add your R-b: now?
> 
> My R-b is still valid. Though, let's wait for Petr's Tested-by. He
> did makedumpfile tests but I asked him to do crash tool tests too.
> I think it is important.

Tested-by: Petr Tesarik 

I copied the complete /proc/vmcore to a directory on disk. Exactly
as expected, crash works both without the patch and with the patch, as
it does not use VMCOREINFO at all (instead, crash obtains the
information from kernel debuginfo directly).

Without the patch:

morricone:/abuild/dumps/2017-04-11-16:38/:[0]# crash vmlinux vmcore 

crash 7.1.8
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
crash: vmlinux: no .gnu_debuglink section
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

  KERNEL: vmlinux   
DUMPFILE: vmcore
CPUS: 12 [OFFLINE: 11]
DATE: Tue Apr 11 16:37:34 2017
  UPTIME: 00:11:51
LOAD AVERAGE: 0.04, 0.08, 0.08
   TASKS: 269
NODENAME: morricone
 RELEASE: 4.11.0-rc5-default-pt+
 VERSION: #1 SMP PREEMPT Thu Apr 6 17:40:53 CEST 2017
 MACHINE: x86_64  (2400 Mhz)
  MEMORY: 16 GB
   PANIC: "sysrq: SysRq : Trigger a crash"
 PID: 12009
 COMMAND: "bash"
TASK: 8804065d2080  [THREAD_INFO: 8804065d2080]
 CPU: 7
   STATE: TASK_RUNNING (SYSRQ)

crash> 


With the patch included:

morricone:/abuild/dumps/2017-04-11-12:52/:[0]# crash vmlinux vmcore  

crash 7.1.8
Copyright (C) 2002-2016  Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
Copyright (C) 1999-2006  Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011  NEC Corporation
Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions.  Enter "help copying" to see the conditions.
This program has absolutely no warranty.  Enter "help warranty" for details.
 
crash: vmlinux: no .gnu_debuglink section
GNU gdb (GDB) 7.6
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...

  KERNEL: vmlinux   
DUMPFILE: vmcore
CPUS: 12 [OFFLINE: 11]
DATE: Tue Apr 11 12:51:15 2017
  UPTIME: 4 days, 01:31:42
LOAD AVERAGE: 0.04, 0.01, 0.00
   TASKS: 634
NODENAME: morricone
 RELEASE: 4.11.0-rc5-default-pt+
 VERSION: #2 SMP PREEMPT Fri Apr 7 09:34:10 CEST 2017
 MACHINE: x86_64  (2400 Mhz)
  MEMORY: 16 GB
   PANIC: "sysrq: SysRq : Trigger a crash"
 PID: 19503
 COMMAND: "bash"
 

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

On 11/04/17 16:42, Raslan, KarimAllah wrote:
> 
>> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky  
>> wrote:
>>
>>
>>

 I think the right thing is indeed to revert 72a9b186292 (and
 therefore da72ff5bfcb02).  Any objections?
>>>
>>> For the end result: depends. Is there a real error or not?
>>> KarimAllah wrote that his concerns are of a theoretical nature as
>>> xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
>>> a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?
>>
>>
>> Judged by 'BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector))' in 
>> xen_hvm_guest_init() this can't boot on 3.4.
> 
> Correct.
> 
> Here is the brief summary of the current situation:
> 
> Before the offending commit (72a9b186292):
> 
> 1) INTx does not work because of the reset_watches path.
> 2) The reset_watches path is only taken if you have Xen > 4.0
> 3) The Linux Kernel by default will use vector inject if the hypervisor
>support. So even INTx does not work no body running the kernel with Xen > 
> 4.0
>would notice. Unless he explicitly disabled this feature either in the 
> kernel
>or in Xen (and this can only be disabled by modifying the code, not
>user-supported way to do it).
> 
> After the offending commit (+ partial revert):
> 
> 1) INTx is no longer support for HVM (only for PV guests).
> 2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have
>vector injection support. Since the only other mode supported is INTx 
> which.
> 
> So based on this summary, I think before commit (72a9b186292) we were in much
> better position from a user point of view.

Thanks for this summary. With this information I agree reverting is the
best option.

>>> For just reverting the two commits: yes, as there would be conflicts
>>> with already applied patches, especially the pv isolation patches by
>>> Vitaly and pvh v1 removal.
>>>
>>> So in case we need a revert I'd ask KarimAllah to send a fixup patch
>>> restoring the state before 72a9b186292 while respecting the new
>>> structure to be found on the for-linus-4.12 branch of xen/tip.
>>
>> Stable trees (4.9 and 4.10) need a pure revert. 4.11 indeed requires some 
>> extra work (and 4.12 is even more involved).
> 
> If we agreed on going forward with the revert, I will take care of sending the
> patches to revert for various trees.

Yes, please go ahead.


Juergen

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Raslan, KarimAllah]

> On Apr 11, 2017, at 4:10 PM, Boris Ostrovsky  
> wrote:
> 
> 
> 
>>> 
>>> I think the right thing is indeed to revert 72a9b186292 (and
>>> therefore da72ff5bfcb02).  Any objections?
>> 
>> For the end result: depends. Is there a real error or not?
>> KarimAllah wrote that his concerns are of a theoretical nature as
>> xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
>> a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?
> 
> 
> Judged by 'BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector))' in 
> xen_hvm_guest_init() this can't boot on 3.4.

Correct.

Here is the brief summary of the current situation:

Before the offending commit (72a9b186292):

1) INTx does not work because of the reset_watches path.
2) The reset_watches path is only taken if you have Xen > 4.0
3) The Linux Kernel by default will use vector inject if the hypervisor
   support. So even INTx does not work no body running the kernel with Xen > 4.0
   would notice. Unless he explicitly disabled this feature either in the kernel
   or in Xen (and this can only be disabled by modifying the code, not
   user-supported way to do it).

After the offending commit (+ partial revert):

1) INTx is no longer support for HVM (only for PV guests).
2) Any HVM guest The kernel will not boot on Xen < 4.0 which does not have
   vector injection support. Since the only other mode supported is INTx which.

So based on this summary, I think before commit (72a9b186292) we were in much
better position from a user point of view.

> 
> 
>> 
>> For just reverting the two commits: yes, as there would be conflicts
>> with already applied patches, especially the pv isolation patches by
>> Vitaly and pvh v1 removal.
>> 
>> So in case we need a revert I'd ask KarimAllah to send a fixup patch
>> restoring the state before 72a9b186292 while respecting the new
>> structure to be found on the for-linus-4.12 branch of xen/tip.
> 
> Stable trees (4.9 and 4.10) need a pure revert. 4.11 indeed requires some 
> extra work (and 4.12 is even more involved).

If we agreed on going forward with the revert, I will take care of sending the
patches to revert for various trees.

> 
> -boris
> 

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

Re: [Xen-devel] [PATCH 02/11] xen/arm: vpl011: Add new hvm params in Xen for ring buffer/event setup

[Bhupinder Thakur]

Hi,

Kindly let me know if my understanding is correct.

Using a domctl API will allow us to keep the vUART configuration
flexible. Currently, we can operate on one ring-buf PFN and an event
channel port only for a single vUART but if we use DOMCTL interface,
then we can effectively get/set multiple event channel ports/multiple
PFNs from/to Xen in a single domctl call.

I am not clear who will be the caller of this domctl API. Is it
xenconsoled or the toolstack? Currently, xenconsoled reads the
ring-buf PFN and event channel from the xenstore, which is populated
by the toolstack.

Regards,
Bhupinder

On 8 March 2017 at 23:52, Stefano Stabellini  wrote:
> On Wed, 8 Mar 2017, Jan Beulich wrote:
>> >>> On 08.03.17 at 15:45,  wrote:
>> > I was looking at the backend code and see it is using DOMCTL command. I
>> > guess it is considered that the console backend will be tied to a
>> > specific Xen version. Am I correct?
>>
>> I don't think I'm qualified to talk about the console backend
>> implementation (and possible quirks it has). Generally I'd expect
>> backends not to use domctl-s, as that would tie them to the tool
>> stack domain.
>>
>> > so maybe we can introduce new domctl command for handling vUART. This
>> > would avoid us to commit on an ABI and allow us to extend it if
>> > necessary in the future to support multiple UARTs.
>>
>> Well, without having the context of who it would be to use such a
>> domctl (and for what purpose) I don#t think I can comment here.
>
> I guess the assumption was that xenconsoled was part of the Xen tools.
> Indeed, it is part of the tools and is installed as such.
>
> I don't have an opinion on this. If introducing a new DOMCTL makes the
> code nicer in xen and xenconsoled, taking away some edges, like the
> changes to evtchn_send, then we should probably just do it.

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Raslan, KarimAllah]

> On Apr 11, 2017, at 10:57 AM, Juergen Gross  wrote:
> 
> On 10/04/17 17:32, Raslan, KarimAllah wrote:
>> 
>> Ahmed, Karim Allah
>> karah...@amazon.de
>> 
>> 
>> 
>>> On Apr 10, 2017, at 3:57 PM, Juergen Gross  wrote:
>>> 
>>> On 10/04/17 15:47, Boris Ostrovsky wrote:
 On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
 On 04/07/2017 07:58 AM, Ian Jackson wrote:
> tl;dr:
> Please apply
> 
>   da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>   partially revert "xen: Remove event channel notification through
> Xen PCI platform device"
> 
> to all stable branches which have a version of the original broken
> commit.  This includes at least 4.9.y.
> 
> Background:
> 
> osstest service owner writes ("[linux-4.9 baseline test] 107238: 
> tolerable FAIL"):
> ...
>> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
> osstest doesn't consider this a regresion because it looks for
> regressions within a branch, and this is the first test of Linux 4.9.
> However, this is a regression from the kernel we are currently using.
> 
> L1 dom0 console log:
> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
> 
> It seems to have got stuck halfway through booting.
> 
> The message
> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
> input to DOM0)
> shows where osstest timed out on this test, and started its log
> capture process (including collecting debug key output).
> 
> Complete logs for this job here:
> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
> 
> Juergen Gross tells me that this is due to the lack of
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
> 
> Thanks,
> Ian.
> 
> PS: Stefano, Boris: did you already request a backport of this commit?
> If not, why not ?
 No, but this should indeed be backported to 4.9+
>>> Boris, are you going to do that?
>> Is there anything that needs to be done beyond just applying it to 4.9
>> (4.10 apparently already has it).
> No, I don't think so. 4.9 already has the offending commit.
 
 
 Looks like there will be a new version of the original patch
 (72a9b186292) so we should hold off with backport request to 4.9:
 
 https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
>>> 
>>> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
>>> reworked: Do we really care for Xen versions < 4.0 and a theoretical
>>> problem (after all the author admitted the bug isn't being hit in
>>> reality due to a short-circuit in the code)?
>> 
>> IMHO, even if 72a9b186292 has not been reworked we should completely revert 
>> it
>> not only partially revert it. Before this commit at least kernel 4.9+ would
>> work on older Xen versions (< 4.0) while now, it will not even boot.
> 
> Just to make sure we understand which Xen versions are to be
> supported: which Xen versions are you at Amazon currently using?

The majority of Amazon fleet is > 4.0 (4.2) but some old generation stuff
is still running Xen 3.4.

> 
> 
> Juergen

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

I think the right thing is indeed to revert 72a9b186292 (and
therefore da72ff5bfcb02).  Any objections?


For the end result: depends. Is there a real error or not?
KarimAllah wrote that his concerns are of a theoretical nature as
xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?



Judged by 'BUG_ON(!xen_feature(XENFEAT_hvm_callback_vector))' in 
xen_hvm_guest_init() this can't boot on 3.4.





For just reverting the two commits: yes, as there would be conflicts
with already applied patches, especially the pv isolation patches by
Vitaly and pvh v1 removal.

So in case we need a revert I'd ask KarimAllah to send a fixup patch
restoring the state before 72a9b186292 while respecting the new
structure to be found on the for-linus-4.12 branch of xen/tip.


Stable trees (4.9 and 4.10) need a pure revert. 4.11 indeed requires 
some extra work (and 4.12 is even more involved).


-boris

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

On 11/04/17 15:22, Boris Ostrovsky wrote:
> 
> 
> On 04/11/2017 05:53 AM, Andrew Cooper wrote:
>> On 10/04/17 19:48, Boris Ostrovsky wrote:
> The following is meant as a real question without any
> prejudice:
> 
> How old a Xen version do we want to support in the Linux
> kernel?
> 
> - Only those being still maintained (meaning getting security
> fixes)
>>> Definitely not this. 4.4 is the oldest version receiving official
>>> XSA patches and it's only 3 years old.
>>> 
> - Versions max. X years after getting last security fixes
> (what value of X?) - From version Y on (what value of Y?) -
> All versions which we can think of
> 
> I think we should answer this question in order to know what
> we can remove in the Linux kernel without breaking
> something.
 Ideally, "All versions which we can think of", unless it
 becomes too difficult. In that case, I would switch to "From
 version Y" where Y is not troublesome to support (and older
 than the oldest supported Xen release).
>>> So Oracle, for example, officially supports its virtualization
>>> product for 8 to 10 years.
>>> 
>>> Which means that 10 years after a product is released it is
>>> possible to see new version of Linux on  such a product (although
>>> realistically vendors may generally support more limited sets of
>>> guests).
>>> 
>>> If we are to follow this line of reasoning Xen 3.4 needs to be
>>> supported --- it was released in 2009.
>> 
>> Citrix XenServer is also 10 years.
>> 
>> From what I understand, SUSE are still supporting Xen 3.2 based 
>> products, which is the same kind of vintage.
> 
> 
> I think the right thing is indeed to revert 72a9b186292 (and
> therefore da72ff5bfcb02).  Any objections?

For the end result: depends. Is there a real error or not?
KarimAllah wrote that his concerns are of a theoretical nature as
xen_strict_xenbus_quirk() would mask the problem. OTOH he tells us
a 4.9 kernel wouldn't even boot on Xen < 4.0. What is correct here?

For just reverting the two commits: yes, as there would be conflicts
with already applied patches, especially the pv isolation patches by
Vitaly and pvh v1 removal.

So in case we need a revert I'd ask KarimAllah to send a fixup patch
restoring the state before 72a9b186292 while respecting the new
structure to be found on the for-linus-4.12 branch of xen/tip.

> The only possible remaining issue is that kernels not using vector 
> callbacks running on post-4.0 Xen won't work. But we always use 
> callbacks if they are available (and they are post 4.0).

I guess this is a non-issue, as it worked until 4.9.


Juergen

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

Re: [Xen-devel] [Outreachy] Interested in Xen Code Review Dashboard

[Jesus M. Gonzalez-Barahona]

On Mon, 2017-04-10 at 14:50 -0700, Candida Haynes wrote:
> Hi,
> 
> I apologize to anyone who receives this twice - I received an
> error/bounce message. I am writing because I am interested in
> applying to Outreachy and contributing to the Xen Code Review
> Dashboard. My most formal experience with open source was in 2014
> when I participated in the Ascend Project. 
> 
> I know I need to make a small code contribution so I am here to find
> out what to do. I have used Mercurial and Git, and have been studying
> JavaScript and Python so I am comfortable switching contexts and
> learning how different software works. I've also been exposed to Go,
> Ruby, Elm, and Swift through tutorials and immersive weekend
> workshops. My JavaScript stack is Node, Express, and PostgreSQL. I've
> interacted with Bugzilla and (briefly) with Try-Server. I enjoy
> working with data and have participated in PyData, but I want to
> learn more. I think this project lends itself to that. Can anyone
> advise on how to get started on the "small contribution" or if there
> is anyone else I need to add to this e-mail? Thanks a lot!

Hi, Candida,

The stack for this project is more like Python and ElasticSearch (I see
you are already familiar with Python, which is great).

A microtask is defined in

http://markmail.org/message/7adkmords3imkswd

And you have some other messages recently posted to this mailing list
with some more info about the project, since some other people
expressed their interest on it. Let me know if you need something else,
please.

Jesus.

> Candida Haynes / Didit
> 
> 
-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


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

[Xen-devel] [distros-debian-snapshot test] 71171: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
71146

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail like 71146
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
71146
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 71146
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71146
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71146
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 71146

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   71146

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

On 04/11/2017 05:53 AM, Andrew Cooper wrote:

On 10/04/17 19:48, Boris Ostrovsky wrote:

The following is meant as a real question without any prejudice:

How old a Xen version do we want to support in the Linux kernel?

- Only those being still maintained (meaning getting security fixes)

Definitely not this. 4.4 is the oldest version receiving official XSA
patches and it's only 3 years old.


- Versions max. X years after getting last security fixes (what value
  of X?)
- From version Y on (what value of Y?)
- All versions which we can think of

I think we should answer this question in order to know what we can
remove in the Linux kernel without breaking something.

Ideally, "All versions which we can think of", unless it becomes too
difficult. In that case, I would switch to "From version Y" where Y is
not troublesome to support (and older than the oldest supported Xen
release).

So Oracle, for example, officially supports its virtualization product
for 8 to 10 years.

Which means that 10 years after a product is released it is possible to
see new version of Linux on  such a product (although realistically
vendors may generally support more limited sets of guests).

If we are to follow this line of reasoning Xen 3.4 needs to be supported
--- it was released in 2009.


Citrix XenServer is also 10 years.

From what I understand, SUSE are still supporting Xen 3.2 based
products, which is the same kind of vintage.



I think the right thing is indeed to revert 72a9b186292 (and therefore 
da72ff5bfcb02).  Any objections?


The only possible remaining issue is that kernels not using vector 
callbacks running on post-4.0 Xen won't work. But we always use 
callbacks if they are available (and they are post 4.0).


-boris

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow216 guest-localmigrate/x10   fail REGR. vs. 107259

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107259
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107259
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107259
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107259
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107259

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

version targeted for testing:
 xen  98e05a3abc0fbab594396f07cf7d6bec0fa109bc
baseline version:
 xen  e1c62cdf782085605ea1186912fc419dd9464027

Last test of basis   107259  2017-04-07 02:45:07 Z4 days
Failing since107294  2017-04-08 05:28:13 Z3 days3 attempts
Testing same since   107357  2017-04-10 17:37:12 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH for-4.9] docs: fix configuration syntax in xl.cfg manpage

[Julien Grall]

Hi Wei,

On 11/04/17 12:03, Wei Liu wrote:

No quote is required when a string is provided as part of a spec string.

Reported-by: Doug Freed 
Signed-off-by: Wei Liu 


Documentation will always improve the release :). Unless there is a 
commit moratorium, consider that release-ack is not necessary.


Cheers,


---
Cc: Ian Jackson 
---
 docs/man/xl.cfg.pod.5.in | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 616dc093b0..13167ff2b6 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -27,7 +27,8 @@ A value C is one of:

 =item B<"STRING">

-A string, surrounded by either single or double quotes.
+A string, surrounded by either single or double quotes. But if the
+STRING is part of a SPEC_STRING, the quotes should be omitted.

 =item B

@@ -569,7 +570,7 @@ settings, from the following list:
 Allow access to the display via the VNC protocol.  This enables the
 other VNC-related settings.  The default is to enable this.

-=item 

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Daniel Kiper]

On Tue, Apr 11, 2017 at 02:45:43PM +0200, Juergen Gross wrote:
> On 03/04/17 14:42, Daniel Kiper wrote:
> > On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
> >> For kdump to work correctly it needs the physical address of
> >> vmcoreinfo_note. When running as dom0 this means the virtual address
> >> has to be translated to the related machine address.
> >>
> >> paddr_vmcoreinfo_note() is meant to do the translation via
> >> __pa_symbol() only, but being attributed "weak" it can be replaced
> >> easily in Xen case.
> >>
> >> Signed-off-by: Juergen Gross 
> >
> > Have you tested this patch with latest crash tool? Do dom0 and Xen
> > hypervisor analysis work without any issue (at least basic commands
> > like dmesg, bt, ps, etc.)? If yes for both you can add:
> >
> > Reviewed-by: Daniel Kiper 
>
> So can I add your R-b: now?

My R-b is still valid. Though, let's wait for Petr's Tested-by. He
did makedumpfile tests but I asked him to do crash tool tests too.
I think it is important.

Daniel

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

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Juergen Gross]

On 03/04/17 14:42, Daniel Kiper wrote:
> On Fri, Mar 31, 2017 at 12:14:38PM +0200, Juergen Gross wrote:
>> For kdump to work correctly it needs the physical address of
>> vmcoreinfo_note. When running as dom0 this means the virtual address
>> has to be translated to the related machine address.
>>
>> paddr_vmcoreinfo_note() is meant to do the translation via
>> __pa_symbol() only, but being attributed "weak" it can be replaced
>> easily in Xen case.
>>
>> Signed-off-by: Juergen Gross 
> 
> Have you tested this patch with latest crash tool? Do dom0 and Xen
> hypervisor analysis work without any issue (at least basic commands
> like dmesg, bt, ps, etc.)? If yes for both you can add:
> 
> Reviewed-by: Daniel Kiper 

So can I add your R-b: now?


Juergen


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

Re: [Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

[Daniel Kiper]

On Tue, Apr 11, 2017 at 06:31:36AM -0600, Jan Beulich wrote:
> >>> On 11.04.17 at 13:24,  wrote:
> > On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >> >>> On 10.04.17 at 21:44,  wrote:
> >> wouldn't it be better to handle this with a static state variable,
> >> which gets checked/set atomically, and which if already set simply
> >> leads to a continuation being arranged for?
> >
> > Do you think about something like that:
> >
> > if ( test_bit(KEXEC_FLAG_IN_PROGRESS, _flags) && 
> > hypercall_preempt_check() )
> > return hypercall_create_continuation(__HYPERVISOR_kexec_op, "h", uarg);
>
> Well, minus the hypercall_preempt_check() call of course. And I'd

OK.

> expect this to be a test_and_set_bit().

Ahhh... Right.

Eric, please try to fix it as Jan suggested.

Daniel

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

Re: [Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

[Jan Beulich]

>>> On 11.04.17 at 13:24,  wrote:
> On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
>> >>> On 10.04.17 at 21:44,  wrote:
>> wouldn't it be better to handle this with a static state variable,
>> which gets checked/set atomically, and which if already set simply
>> leads to a continuation being arranged for?
> 
> Do you think about something like that:
> 
> if ( test_bit(KEXEC_FLAG_IN_PROGRESS, _flags) && 
> hypercall_preempt_check() )
> return hypercall_create_continuation(__HYPERVISOR_kexec_op, "h", uarg);

Well, minus the hypercall_preempt_check() call of course. And I'd
expect this to be a test_and_set_bit().

Jan


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

[Xen-devel] [PATCH v3] xen, input: add xen-kbdfront module parameter for setting resolution

[Juergen Gross]

Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.

While at it remove the pointless second reading of parameters from
Xenstore in the device connection phase: all parameters are available
during device probing already and that is where they should be read.

Signed-off-by: Juergen Gross 
---
V3: - merged the two patches
- read Xenstore parameters during probing of the device only
---
 drivers/input/misc/xen-kbdfront.c | 39 ++-
 1 file changed, 14 insertions(+), 25 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875dec10..2fc7895373ab 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -41,6 +41,12 @@ struct xenkbd_info {
char phys[32];
 };
 
+enum { KPARAM_X, KPARAM_Y, KPARAM_CNT };
+static int ptr_size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(ptr_size, int, NULL, 0444);
+MODULE_PARM_DESC(ptr_size,
+   "Pointing device width, height in pixels (default 800,600)");
+
 static int xenkbd_remove(struct xenbus_device *);
 static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
*);
 static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -128,7 +134,12 @@ static int xenkbd_probe(struct xenbus_device *dev,
if (!info->page)
goto error_nomem;
 
+   /* Set input abs params to match backend screen res */
abs = xenbus_read_unsigned(dev->otherend, "feature-abs-pointer", 0);
+   ptr_size[KPARAM_X] = xenbus_read_unsigned(dev->otherend, "width",
+ ptr_size[KPARAM_X]);
+   ptr_size[KPARAM_Y] = xenbus_read_unsigned(dev->otherend, "height",
+ ptr_size[KPARAM_Y]);
if (abs) {
ret = xenbus_write(XBT_NIL, dev->nodename,
   "request-abs-pointer", "1");
@@ -174,8 +185,8 @@ static int xenkbd_probe(struct xenbus_device *dev,
 
if (abs) {
__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, ptr_size[KPARAM_X], 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, ptr_size[KPARAM_Y], 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);
@@ -309,9 +320,6 @@ static void xenkbd_disconnect_backend(struct xenkbd_info 
*info)
 static void xenkbd_backend_changed(struct xenbus_device *dev,
   enum xenbus_state backend_state)
 {
-   struct xenkbd_info *info = dev_get_drvdata(>dev);
-   int ret, val;
-
switch (backend_state) {
case XenbusStateInitialising:
case XenbusStateInitialised:
@@ -321,15 +329,6 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
break;
 
case XenbusStateInitWait:
-InitWait:
-   if (xenbus_read_unsigned(info->xbdev->otherend,
-"feature-abs-pointer", 0)) {
-   ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
-  "request-abs-pointer", "1");
-   if (ret)
-   pr_warning("xenkbd: can't request abs-pointer");
-   }
-
xenbus_switch_state(dev, XenbusStateConnected);
break;
 
@@ -340,17 +339,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
 * get Connected twice here.
 */
if (dev->state != XenbusStateConnected)
-   goto InitWait; /* no InitWait seen yet, fudge it */
-
-   /* Set input abs params to match backend screen res */
-   if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-"width", "%d", ) > 0)
-   input_set_abs_params(info->ptr, ABS_X, 0, val, 0, 0);
-
-   if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,
-"height", "%d", ) > 0)
-   input_set_abs_params(info->ptr, ABS_Y, 0, val, 0, 0);
-
+   xenbus_switch_state(dev, XenbusStateConnected);
break;
 
case XenbusStateClosed:
-- 
2.12.0


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

Re: [Xen-devel] [PATCH v7 00/34] arm64: Dom0 ITS emulation

[Vijay Kilari]

Hi Andre,

On Sat, Apr 8, 2017 at 3:37 AM, Andre Przywara  wrote:
> Hi,
>
> an only slightly modified repost of the last version.
> I added the Reviewed-by: and Acked-by: tags from Stefano and Julien
> and rebased on top of the latest staging tree:
> commit 89216c7999eb5b8558bfac7d61ae0d5ab844ce3f
> Author: Dario Faggioli 
> Date:   Fri Apr 7 18:57:14 2017 +0200
>
> xen: credit1: treat pCPUs more evenly during balancing.
>
> Other than that and one typo and comment fix the first 10 patches have
> not been changed.
> I dropped the addition of the GIC_IRQ_GUEST_LPI_PENDING bit in patch 12/36
> and followed Stefano's suggestion, which led to the removal of former
> patches 17/36 and 23/36 and some simplification in later patches.
> I haven't been able to address most review comments from the last part of
> v5 yet, but will definitely still fix them.
> Detailed changelog below.
>
> Cheers,
> Andre
>
> --
> This series adds support for emulation of an ARM GICv3 ITS interrupt
> controller. For hardware which relies on the ITS to provide interrupts for
> its peripherals this code is needed to get a machine booted into Dom0 at
> all. ITS emulation for DomUs is only really useful with PCI passthrough,
> which is not yet available for ARM. It is expected that this feature
> will be co-developed with the ITS DomU code. However this code drop here
> considered DomU emulation already, to keep later architectural changes
> to a minimum.
>
> This is technical preview version to allow early testing of the feature.
> Things not (properly) addressed in this release:
> - The MOVALL command is not emulated. In our case there is really nothing
> to do here. We might need to revisit this in the future for DomU support.
> - The INVALL command might need some rework to be more efficient. Currently
> we iterate over all mapped LPIs, which might take a bit longer.
> - Indirect tables are not supported. This affects both the host and the
> virtual side.
> - The command queue locking is currently suboptimal and should be made more
> fine-grained in the future, if possible.
> - We need to properly investigate the possible interaction when devices get
> removed. This requires to properly clean up and remove any associated
> resources like pending or in-flight LPIs, for instance.
>
>
> Some generic design principles:
>
> * The current GIC code statically allocates structures for each supported
> IRQ (both for the host and the guest), which due to the potentially
> millions of LPI interrupts is not feasible to copy for the ITS.
> So we refrain from introducing the ITS as a first class Xen interrupt
> controller, also we don't hold struct irq_desc's or struct pending_irq's
> for each possible LPI.
> Fortunately LPIs are only interesting to guests, so we get away with
> storing only the virtual IRQ number and the guest VCPU for each allocated
> host LPI, which can be stashed into one uint64_t. This data is stored in
> a two-level table, which is both memory efficient and quick to access.
> We hook into the existing IRQ handling and VGIC code to avoid accessing
> the normal structures, providing alternative methods for getting the
> needed information (priority, is enabled?) for LPIs.
> Whenever a guest maps a device, we allocate the maximum required number
> of struct pending_irq's, so that any triggering LPI can find its data
> structure. Upon the guest actually mapping the LPI, this pointer to the
> corresponding pending_irq gets entered into a radix tree, so that it can
> be quickly looked up.
>
> * On the guest side we (later will) have to deal with malicious guests
> trying to hog Xen with mapping requests for a lot of LPIs, for instance.
> As the ITS actually uses system memory for storing status information,
> we use this memory (which the guest has to provide) to naturally limit
> a guest. Whenever we need information from any of the ITS tables, we
> temporarily map them (which is cheap on arm64) and copy the required data.
> * An obvious approach to handling some guest ITS commands would be to
> propagate them to the host, for instance to map devices and LPIs and
> to enable or disable LPIs.
> However this (later with DomU support) will create an attack vector, as
> a malicious guest could try to fill the host command queue with
> propagated commands.
> So we try to avoid this situation: Dom0 sending a device mapping (MAPD)
> command is the only time we allow queuing commands to the host ITS command
> queue, as this seems to be the only reliable way of getting the
> required information at the moment. However at the same time we map all
> events to LPIs already, also enable them. This avoids sending commands
> later at runtime, as we can deal with mappings and LPI enabling/disabling
> internally.
>
> To accomodate the tech preview nature of this feature at the moment, there
> is a Kconfig option to enable it. Also it is supported on arm64 only, 

Re: [Xen-devel] [Outreachy] Interested in contribution: Code Standards Checking using clang-format

[Lars Kurth]

Ishani,

> On 11 Apr 2017, at 12:21, Ishani  wrote:
> 
> Hello,
> 
> I have created a clang-format file for specifications of format for Xen 
> hypervisor and incorporated all of the support which present clang-format 
> could provide. I have seen all the options provided by clang-format and have 
> some discrepancies regarding some of format specifications which are not 
> provided in the doc but is followed. I will commit the code and provide you 
> with full report by today.

Can you post this on any public repo for now (e.g. github gitlab bitbucket, 
whatever) and post an e-mail on this list with title "[RFC] Code Standards 
Checking using clang-format" or something like it with link to the repo. I 
think this is enough for the small task required for this project.

Ideally, because at some point you will need to do this, you would follow 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - but we could 
waive this in this case. But it will make reviewing the output easier.

>> 4: a small script that checks that .clang-format works correctly on these 
>> pieces of code
> 
>> For 4, you probably want to run clang-format with -output-replacements-xml 
>> on the files in 1 >- 3 and then do some grep magic to see whether it does 
>> the right thing.
> 
> Can you elaborate on this a bit. What is the expected end product?

I think this is a stretch goal, given the time-frame. The idea here was to be 
able to verify that the clang-format file works as expected on some code 
snippets that we know adhere to the coding standards. This would in essence 
produce a stand-alone test for the .clang-format file on the coding style 
patterns that we know works. 

> Meanwhile, I have resumed on writing the proposal. I somehow missed previous 
> comments. Please have a look at it.
> https://docs.google.com/document/d/10NJn-QvO1TvyJJJGE2PD6FtElYCT3neBAffIqeWHdiE/edit?usp=sharing

I saw it. Thank you!

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

Re: [Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

[Daniel Kiper]

On Tue, Apr 11, 2017 at 01:46:37AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 21:44,  wrote:
>
> Please don't forget Cc-ing the maintainer(s) of the code being modified.
>
> > @@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op,
> >  XEN_GUEST_HANDLE_PARAM(void) uarg,
> >  bool_t compat)
> >  {
> > +static DEFINE_SPINLOCK(kexec_lock);
> >  int ret = -EINVAL;
> >
> >  ret = xsm_kexec(XSM_PRIV);
> >  if ( ret )
> >  return ret;
> >
> > +/*
> > + * Because we write directly to the reserved memory
> > + * region when loading crash kernels we need a spinlock here to
> > + * prevent multiple crash kernels from attempting to load
> > + * simultaneously, and to prevent a crash kernel from loading
> > + * over the top of a in use crash kernel.
> > + */
> > +spin_lock(_lock);
> > +
> >  switch ( op )
> >  {
> >  case KEXEC_CMD_kexec_get_range:
> > @@ -1227,6 +1232,8 @@ static int do_kexec_op_internal(unsigned long op,
> >  break;
> >  }
> >
> > +spin_unlock(_lock);
> > +
> >  return ret;
> >  }
>
> How long can a kexec-op take? Are you putting systems at risk of
> the watchdog firing? Even if you don't, you put all sorts of
> operations inside a lock now which preferably should run outside
> of atomic context (memory allocation, guest memory accesses).

Facepalm! I forgot about that.

> If such a global locking approach is really necessary (i.e. if we

Potentially no but otherwise we will further complicate sufficiently
complicated code now. So, I would like to have one sync place.

> can't expect the - privileged - caller to synchronize calls properly),
> wouldn't it be better to handle this with a static state variable,
> which gets checked/set atomically, and which if already set simply
> leads to a continuation being arranged for?

Do you think about something like that:

if ( test_bit(KEXEC_FLAG_IN_PROGRESS, _flags) && 
hypercall_preempt_check() )
return hypercall_create_continuation(__HYPERVISOR_kexec_op, "h", uarg);

> Furthermore - are there problems also with e.g. loading a
> default and a crash kernel in parallel? I.e. aren't you doing more

No it should not be any issue there.

> synchronization than really necessary?

I do not think that it is very big issue here but if you wish we can fix it 
that too.

Daniel

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

Re: [Xen-devel] [Outreachy] Interested in contribution: Code Standards Checking using clang-format

[Ishani]

Hello,

I have created a clang-format file for specifications of format for Xen 
hypervisor and incorporated all of the support which present clang-format could 
provide. I have seen all the options provided by clang-format and have some 
discrepancies regarding some of format specifications which are not provided in 
the doc but is followed. I will commit the code and provide you with full 
report by today.

>4: a small script that checks that .clang-format works correctly on these 
>pieces of code

>For 4, you probably want to run clang-format with -output-replacements-xml on 
>the files in 1 >- 3 and then do some grep magic to see whether it does the 
>right thing.

Can you elaborate on this a bit. What is the expected end product?

Meanwhile, I have resumed on writing the proposal. I somehow missed previous 
comments. Please have a look at it.
https://docs.google.com/document/d/10NJn-QvO1TvyJJJGE2PD6FtElYCT3neBAffIqeWHdiE/edit?usp=sharing

Regards,
Ishani

- Original Message -
From: "Lars Kurth" 
To: "Ishani" 
Cc: "cardoe" , "xen-devel" , 
"Andrew Cooper" 
Sent: Monday, April 3, 2017 9:52:38 PM
Subject: Re: [Xen-devel] [Outreachy] Interested in contribution: Code Standards 
Checking using clang-format

Hi Ishani,

> On 3 Apr 2017, at 13:01, Ishani  wrote:
> 
> Thanks for the reply. I started with looking into format of Xen Hypervisor 
> files and creating a clang format file for the same. However, given the 
> present implementation of clang-format, it is not possible to incorporate 
> fine-grained custom coding format requirements. For example, although 
> clang-format provides a custom brace wrapping format specification, it is 
> still not sufficient to incorporate the do while loop exception for braces in 
> Xen Hypervisor format.

OK, this makes this project a lot harder. I don't think we are particularly 
tied to clang-format. 

> The implementations is presently on higher layers of abstraction and needs to 
> be fine grained to allow for different types of loops as well. I figured that 
> there are two ways of doing it, First , by creating a wrapper over 
> clang-format and using regexes to find appropriate partitions of code to 
> follow different format styles.
> However, this will be rather cumbersome with multiple heuristics and we will 
> lose the advantage of clang-format tool using the inbuilt parser.

Indeed.

> Second way is to extend the functionality of clang-format. I have experience 
> working with compilers. Going through the code of clang it seems possible to 
> include kw_do token for do while loop as a functionality for braces wrapping( 
> although it would require a very thorough reading through the codebase 
> first). 

One of the objectives behind using clang was that we wanted to be able to use a 
compiler front-end that has a plug-in model or a library which allows access to 
the AST. Clang-format appeared to fit the bill. 

> At present, I am working on creating a clang format file supporting subset of 
> coding formats for Xen Hypervisor.

I think that would fit with what I suggested.

> Can you provide me with some more insight into the project?

There are really two objectives:

A) A tool which can be run over submissions by new contributors. Right now, 
adherence to coding standards has to be manually checked. Having a tool which 
lists coding standard violations in a git-patch or in the files a patch touches 
would allow contributors to run the tool before submitting the code. Ideally, 
it could be run over a patch, but that may be harder than running it over the 
files the patch touches. In any case, it would improve the work-flow.

B) Be able to run the tool on the entire code base.

We also want to make this as easy to maintain in future as possible, which is 
why we originally suggested clang-format. It might in fact be easier or cleaner 
to use LibTooling rather than clang-format for this as base-line and use 
clang-format as an inspiration (looking at the source of clang-format, there 
does not seem to be that much).  Keeping as close as possibly to the 
clang-format config file. The downside is that we would have to maintain such a 
tool in the long-run (but then we would have to do the same if we used a 
stand-alone tool using script hackery). I don't think either Doug, Andy, or me 
could give you concrete advice on what the best way forward is here without 
further discussion though.

> clang-format formats the tool to specified format. However, there are many 
> standards which include a particular format for a variable name. It is not 
> feasible for a tool to automatically change the name of variable according to 
> given standards because of possible breaking build of the code.

That is not the intention: it is definitely not desirable to do that kind of 
refactoring 

Re: [Xen-devel] ITS emulation race conditions

[Julien Grall]

On 11/04/17 10:24, Julien Grall wrote:

Hi Stefano,

On 04/11/2017 12:01 AM, Stefano Stabellini wrote:

On Mon, 10 Apr 2017, Andre Przywara wrote:

Hi,

On 10/04/17 00:12, André Przywara wrote:

Hi,

I wanted to run some ideas on how to prevent the race conditions we are
facing with the ITS emulation and removing devices and/or LPIs.
I think Stefano's idea of tagging a discarded LPI is the key, but still
some details are left to be solved.
I think we are dealing with two issues:
1) A guest's DISCARD can race with in incoming LPI.
Ideally DISCARD would remove the host LPI -> vLPI connection (in the
host_lpis table), so any new incoming (host) LPI would simply be
discarded very early in gicv3_do_LPI() without ever resolving into a
virtual LPI. Now while this removal is atomic, we could have just
missed
an incoming LPI, so the old virtual LPI would still traverse down the
VGIC with a "doomed" virtual LPI ID.
I wonder if that could be solved by a "crosswise" check:
- The DISCARD handler *first* tags the pending_irq as "UNMAPPED",
*then*
removes the host_lpis connectin.
- do_LPI() reads the host_lpis() array, *then* checks the UNMAPPED tag
in the corresponding pending_irq (or lets vgic_vcpu_inject_irq() do
that).
With this setup the DISCARD handler can assume that no new virtual LPI
instances enter the VGIC afterwards.

2) An unmapped LPI might still be in use by the VGIC, foremost might
still be in an LR.
Tagging the pending_irq should solve this in general. Whenever a VGIC
function finds the UNMAPPED tag, it does not process the vIRQ, but
retires it. For simplicity we might limit this to handling when a VCPU
exists and an LR gets cleaned up: If we hit a tagged pending_irq here,
we clean the LR, remove the pending_irq from all lists and signal the
ITS emulation that this pending_irq is now ready to be removed (by
calling some kind of cleanup_lpi() function, for instance).
The ITS code can then remove the struct pending_irq from the radix
tree.
MAPD(V=0) is now using this to tag all still mapped events as
"UNMAPPED", the counting down the "still alive" pending_irqs in
cleanup_lpi() until they reach zero. At this point it should be safe to
free the pend_irq array.

Does that sound like a plan?
Do I miss something here? Probably yes, hence I am asking ;-)


So there are two issues with this:
- For doing the LPI cleanup, we would need to call a virtual ITS or
virtual LPI specific function directly from gic.c. This looks like bad
coding style, as it breaks the abstraction (calling a virtual LPI/ITS
specific function from within gic.c)


This is just code organization, I am not worried about it. We might have
to register cleanup functions. The real problem to solve is below.



- If we have a "DISCARD; MAPTI" sequence, targeting the same vLPI, while
this vLPI is still in an LR (but not cleaned up until both commands have
been handled), we end up with using the wrong pending_irq struct (the
new one). (I assume the UNMAPPED tag would be cleared upon the new
MAPTI).


It looks like "DISCARD; MAPTI" would be a problem even if we go with
"GIC: Add checks for NULL pointer pending_irq's", because instead of a
NULL pending_irq, we could get the new pending_irq, the one backing the
same vlpi but a different eventid.



Can this create problems?
I see two possibilities:
a) the old vLPI is still pending in the LR: as the new LR would be
pristine, the code in update_one_lr() would just clean the QUEUED bit,
but not do anything further. The LR would be kept as used by this vLPI,
with the state still set to GICH_LR_PENDING. Upon re-entering the VCPU
this would make the new vLPI pending.
b) the old vLPI has been EOIed: the new LR would be pristine, the code
in update_one_lr() would try to clean it up anyway, which should not
hurt, AFAICT.


This cannot be allowed to happen. We have to keep a consistent internal
state at all times: we cannot change the vlpi mapping in pend_lpi_tree
before the old vlpi is completed discarded. We cannot have a vlpi marked
as "UNMAPPED", but still alive in an LR, while vlpi_to_pending already
returns the new vlpi.


Well, in hardware LPI are handled by the re-distributor and ITS is only 
acting as a walker to find the mapping (DeviceID, EventID) -> LPI.


In real hardware, a LPI may be received afterwards if the re-distributor 
already inject it. The OS will receive the LPI and have to deal with it, 
potentially re-directing to the new interrupt handler and not the old.


The problem is the same here, an LPI may be in LR whilst the DISCARD 
happen. I think this is too late and the guest should receive it.




We have a number of possible approaches, I'll mark them with [letter].


[a] On DISCARD we do everything we can to remove the vlpi from
everywhere:

- if pending_irq is in lr_queue, remove it from the list
- if the vlpi is in an LR register as pending (not active, see below),
  remove it from the LR (see the code in gic_restore_pending_irqs, under
  "No more free LRs: find a lower priority