[Xen-devel] [xen-4.9-testing test] 115206: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114833
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114949
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 115018
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 115018
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 115018
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 115018
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115018
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 115018
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  61b6df9d821481ba4e26e5843aa9320345077319
baseline version:
 xen  2040ac14e4cfbae679751796266527d92d11ac78

Last test of basis   115018  2017-10-22 09:59:18 Z3 days
Testing same since   115186  2017-10-24 14:46:59 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Wei Liu 

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

[Xen-devel] How to Hardware performance monitoring from Dom0

[Tejaswini Vibhute]

Hi,

I need some pointers to how to monitor hardware events in a Xen configured
environment.
I am running Xen 4.7 with Linux kernel 4.11 as my Dom0.

-- 
Regards,
Tejaswini Vibhute
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/6] Intel Processor Trace virtulization enabling

[Kang, Luwei]

> > Hi All,
> >
> > Here is a patch-series which adding Processor Trace enabling in XEN guest. 
> > You can get It's software developer manuals from:
> > https://software.intel.com/sites/default/files/managed/c5/15/architect
> > ure-instruction-set-extensions-programming-reference.pdf
> > In Chapter 5 INTEL PROCESSOR TRACE: VMX IMPROVEMENTS.
> >
> > Introduction:
> > Intel Processor Trace (Intel PT) is an extension of Intel Architecture that 
> > captures information about software execution using
> dedicated hardware facilities that cause only minimal performance 
> perturbation to the software being traced. Details on the Intel PT
> infrastructure and trace capabilities can be found in the Intel 64 and IA-32 
> Architectures Software Developer’s Manual, Volume 3C.
> >
> > The suite of architecture changes serve to simplify the process of 
> > virtualizing Intel PT for use by a guest software. There are two
> primary elements to this new architecture support for VMX support 
> improvements made for Intel PT.
> > 1. Addition of a new guest IA32_RTIT_CTL value field to the VMCS.
> >   — This serves to speed and simplify the process of disabling trace on VM 
> > exit, and restoring it on VM entry.
> > 2. Enabling use of EPT to redirect PT output.
> >   — This enables the VMM to elect to virtualize the PT output buffer using 
> > EPT. In this mode, the CPU will treat PT output
> addresses as Guest Physical Addresses (GPAs) and translate them using EPT. 
> This means that Intel PT output reads (of the ToPA
> table) and writes (of trace output) can cause EPT violations, and other 
> output events.
> 
> Hello,
> 
> Having read the new proposed extensions, I've got some architecture questions 
> before diving into the patches themselves.
> 
> First of all, is this technology expected to end up in Icelake, or something 
> later?

Yes, this would be enabled on Icelake.

> 
> In Vol 3, the existing VMX support describes a number of scenarios (system 
> wide, VMM-only, VM-only, guest aware), which require
> the use of MSR load lists to atomically alter the IA32_RTIT_* msrs.

Currently, I just enabling the guest only mode(VM-only) in my patches.

> 
> Obviously, system wide mode is incompatible with also allowing the guest to 
> use PT itself, 

Yes, system mode(collect trace packets of the entire system) can't work with 
guest only mode at the same time.

> but what about Xen wanting to use PT for itself, and for the guest to use PT 
> as well?

I think this can be named by host-guest mode. This may need add new command or 
interface to enable PT in Xen hypervisor. Trace vmm-only and guest simultaneous 
and output to their respective buffer.

> 
> Previously, this appears to be possible using the MSR load lists (albeit with 
> Xen needing to shadow the ToPA records to cause the
> packet stream to end up in the right place).

Yes.

> 
> However, the new VM consistency checks require that using EPT redirection 
> requires clear/load CTL on exit/entry be set, and having
> load on entry set requires the host TraceEn to be clear.

Yes. New bits added in VMCS can make sure PT be disabled before VM exit and 
IA32_RTIT_CTL MSR will be written with the value of the associated Guest State 
field of the VMCS on VM entry. 

Thanks for your response.

Luwei Kang

> 
> Therefore, as far as I can see, allowing a guest to use PT via EPT now 
> prohibits Xen also using PT for its own purposes outside of non-
> root mode.
> 
> Is this intentional and/or expected, or have I misunderstood something in the 
> manuals?
> 
> Thanks,
> 
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682

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

version targeted for testing:
 linuxae59df0349baf44c988b32a3b4dc21363d87df15
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z7 days
Failing since114781  2017-10-20 01:00:47 Z6 days   10 attempts
Testing same since   115203  2017-10-25 04:34:14 Z0 days1 attempts


322 people touched revisions under test,
not listing them all

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

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

version targeted for testing:
 linux4d4a6a3f8a12602ce8dc800123715fe7b5c1c3a1
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z5 days
Testing same since   114845  2017-10-21 16:14:17 Z4 days8 attempts


People who touched revisions under test:
  Alex Deucher 
  Alexandre Belloni 
  Andrew Morton 
  Anoob Soman 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Skeggs 
  Bin Liu 
  Borislav Petkov 
  Christoph Lameter 
  Christophe JAILLET 
  Coly Li 
  Dan Carpenter 
  David Rientjes 
  David S. Miller 
  Dennis Dalessandro 
  Dmitry V. Levin 
  Doug Ledford 
  Easwar Hariharan 
  Emmanuel 

Re: [Xen-devel] [PATCH 12/12] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> The functions to actually populate a list register were accessing
> the VGIC internal pending_irq struct, although they should be abstracting
> from that.
> Break the needed information down to remove the reference to pending_irq
> from gic-v[23].c.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/gic-v2.c | 14 +++---
>  xen/arch/arm/gic-v3.c | 12 ++--
>  xen/arch/arm/gic-vgic.c   |  3 ++-
>  xen/include/asm-arm/gic.h |  4 ++--
>  4 files changed, 17 insertions(+), 16 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 511c8d7294..e5acff8900 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -428,8 +428,8 @@ static void gicv2_disable_interface(void)
>  spin_unlock();
>  }
>  
> -static void gicv2_update_lr(int lr, const struct pending_irq *p,
> -unsigned int state)
> +static void gicv2_update_lr(int lr, unsigned int virq, uint8_t priority,
> +unsigned int hw_irq, unsigned int state)
>  {
>  uint32_t lr_reg;
>  
> @@ -437,12 +437,12 @@ static void gicv2_update_lr(int lr, const struct 
> pending_irq *p,
>  BUG_ON(lr < 0);
>  
>  lr_reg = (((state & GICH_V2_LR_STATE_MASK) << GICH_V2_LR_STATE_SHIFT)  |
> -  ((GIC_PRI_TO_GUEST(p->priority) & GICH_V2_LR_PRIORITY_MASK)
> - << GICH_V2_LR_PRIORITY_SHIFT) |
> -  ((p->irq & GICH_V2_LR_VIRTUAL_MASK) << 
> GICH_V2_LR_VIRTUAL_SHIFT));
> +  ((GIC_PRI_TO_GUEST(priority) & GICH_V2_LR_PRIORITY_MASK)
> +  << GICH_V2_LR_PRIORITY_SHIFT) |
> +  ((virq & GICH_V2_LR_VIRTUAL_MASK) << 
> GICH_V2_LR_VIRTUAL_SHIFT));
>  
> -if ( p->desc != NULL )
> -lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
> +if ( hw_irq != -1 )
> +lr_reg |= GICH_V2_LR_HW | ((hw_irq & GICH_V2_LR_PHYSICAL_MASK )
> << GICH_V2_LR_PHYSICAL_SHIFT);
>  
>  writel_gich(lr_reg, GICH_LR + lr * 4);
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 74d00e0c54..3dec407a02 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -944,8 +944,8 @@ static void gicv3_disable_interface(void)
>  spin_unlock();
>  }
>  
> -static void gicv3_update_lr(int lr, const struct pending_irq *p,
> -unsigned int state)
> +static void gicv3_update_lr(int lr, unsigned int virq, uint8_t priority,
> +unsigned int hw_irq, unsigned int state)
>  {
>  uint64_t val = 0;
>  
> @@ -961,11 +961,11 @@ static void gicv3_update_lr(int lr, const struct 
> pending_irq *p,
>  if ( current->domain->arch.vgic.version == GIC_V3 )
>  val |= GICH_LR_GRP1;
>  
> -val |= ((uint64_t)p->priority & 0xff) << GICH_LR_PRIORITY_SHIFT;
> -val |= ((uint64_t)p->irq & GICH_LR_VIRTUAL_MASK) << 
> GICH_LR_VIRTUAL_SHIFT;
> +val |= (uint64_t)priority << GICH_LR_PRIORITY_SHIFT;
> +val |= ((uint64_t)virq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT;
>  
> -   if ( p->desc != NULL )
> -   val |= GICH_LR_HW | (((uint64_t)p->desc->irq & GICH_LR_PHYSICAL_MASK)
> +   if ( hw_irq != -1 )
> +   val |= GICH_LR_HW | (((uint64_t)hw_irq & GICH_LR_PHYSICAL_MASK)
> << GICH_LR_PHYSICAL_SHIFT);
>  
>  gicv3_ich_write_lr(lr, val);
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> index 7765d83432..e783f3b54b 100644
> --- a/xen/arch/arm/gic-vgic.c
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -52,7 +52,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
>  
>  clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status);
>  
> -gic_hw_ops->update_lr(lr, p, state);
> +gic_hw_ops->update_lr(lr, p->irq, p->priority,
> +  p->desc ? p->desc->irq : -1, state);
>  
>  set_bit(GIC_IRQ_GUEST_VISIBLE, >status);
>  clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index fe14094c0f..66f0957fab 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -339,8 +339,8 @@ struct gic_hw_operations {
>  /* Disable CPU physical and virtual interfaces */
>  void (*disable_interface)(void);
>  /* Update LR register with state and priority */
> -void (*update_lr)(int lr, const struct pending_irq *pending_irq,
> -  unsigned int state);
> +void (*update_lr)(int lr, unsigned int virq, uint8_t priority,
> +  unsigned int hw_irq, unsigned int state);
>  /* Update HCR status register */
>  void (*update_hcr_status)(uint32_t flag, bool set);
>  /* Clear LR register */
> -- 
> 2.14.1
> 

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH 11/12] ARM: VGIC: factor out vgic_get_hw_irq_desc()

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> At the moment we happily access the VGIC internal struct pending_irq
> (which describes a virtual IRQ) in irq.c.
> Factor out the actually needed functionality to learn the associated
> hardware IRQ and move that into gic-vgic.c to improve abstraction.
> 
> Signed-off-by: Andre Przywara 

Acked-by: Stefano Stabellini 


> ---
>  xen/arch/arm/gic-vgic.c| 15 +++
>  xen/arch/arm/irq.c |  7 ++-
>  xen/include/asm-arm/vgic.h |  2 ++
>  3 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> index bf9455a34e..7765d83432 100644
> --- a/xen/arch/arm/gic-vgic.c
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -385,6 +385,21 @@ void gic_inject(struct vcpu *v)
>  gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
>  }
>  
> +struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
> +  unsigned int virq)
> +{
> +struct pending_irq *p;
> +
> +if ( !v )
> +v = d->vcpu[0];
> +
> +p = irq_to_pending(v, virq);
> +if ( !p )
> +return NULL;
> +
> +return p->desc;
> +}
> +
>  int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
>  struct irq_desc *desc)
>  {
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 7f133de549..62103a20e3 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -534,19 +534,16 @@ int release_guest_irq(struct domain *d, unsigned int 
> virq)
>  struct irq_desc *desc;
>  struct irq_guest *info;
>  unsigned long flags;
> -struct pending_irq *p;
>  int ret;
>  
>  /* Only SPIs are supported */
>  if ( virq < NR_LOCAL_IRQS || virq >= vgic_num_irqs(d) )
>  return -EINVAL;
>  
> -p = spi_to_pending(d, virq);
> -if ( !p->desc )
> +desc = vgic_get_hw_irq_desc(d, NULL, virq);
> +if ( !desc )
>  return -EINVAL;
>  
> -desc = p->desc;
> -
>  spin_lock_irqsave(>lock, flags);
>  
>  ret = -EINVAL;
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index cf02dc6394..947950875b 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -220,6 +220,8 @@ int vgic_v2_init(struct domain *d, int *mmio_count);
>  int vgic_v3_init(struct domain *d, int *mmio_count);
>  
>  bool vgic_evtchn_irq_pending(struct vcpu *v);
> +struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
> +  unsigned int virq);
>  int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
>  struct irq_desc *desc);
>  
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH 10/12] ARM: VGIC: factor out vgic_connect_hw_irq()

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> At the moment we happily access VGIC internal data structures like
> the rank and struct pending_irq in gic.c, which should be VGIC agnostic.
> 
> Factor out a new function vgic_connect_hw_irq(), which allows a virtual
> IRQ to be connected to a hardware IRQ (using the hw bit in the LR).
> 
> This removes said accesses to VGIC data structures and improves abstraction.
> 
> Signed-off-by: Andre Przywara 

Acked-by: Stefano Stabellini 


> ---
>  xen/arch/arm/gic-vgic.c| 31 +++
>  xen/arch/arm/gic.c | 42 ++
>  xen/include/asm-arm/vgic.h |  2 ++
>  3 files changed, 39 insertions(+), 36 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> index 66cae21e82..bf9455a34e 100644
> --- a/xen/arch/arm/gic-vgic.c
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -385,6 +385,37 @@ void gic_inject(struct vcpu *v)
>  gic_hw_ops->update_hcr_status(GICH_HCR_UIE, 1);
>  }
>  
> +int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
> +struct irq_desc *desc)
> +{
> +unsigned long flags;
> +/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
> + * route SPIs to guests, it doesn't make any difference. */
> +struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
> +struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
> +struct pending_irq *p = irq_to_pending(v_target, virq);
> +int ret = 0;
> +
> +/* We are taking to rank lock to prevent parallel connections. */
> +vgic_lock_rank(v_target, rank, flags);
> +
> +if ( desc )
> +{
> +/* The VIRQ should not be already enabled by the guest */
> +if ( !p->desc &&
> + !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
> +p->desc = desc;
> +else
> +ret = -EBUSY;
> +}
> +else
> +p->desc = NULL;
> +
> +vgic_unlock_rank(v_target, rank, flags);
> +
> +return ret;
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 4cb74d449e..d46a6d54b3 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -128,27 +128,12 @@ void gic_route_irq_to_xen(struct irq_desc *desc, 
> unsigned int priority)
>  int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
> struct irq_desc *desc, unsigned int priority)
>  {
> -unsigned long flags;
> -/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
> - * route SPIs to guests, it doesn't make any difference. */
> -struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
> -struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
> -struct pending_irq *p = irq_to_pending(v_target, virq);
> -int res = -EBUSY;
> -
>  ASSERT(spin_is_locked(>lock));
>  /* Caller has already checked that the IRQ is an SPI */
>  ASSERT(virq >= 32);
>  ASSERT(virq < vgic_num_irqs(d));
>  ASSERT(!is_lpi(virq));
>  
> -vgic_lock_rank(v_target, rank, flags);
> -
> -if ( p->desc ||
> - /* The VIRQ should not be already enabled by the guest */
> - test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
> -goto out;
> -
>  desc->handler = gic_hw_ops->gic_guest_irq_type;
>  set_bit(_IRQ_GUEST, >status);
>  
> @@ -156,31 +141,19 @@ int gic_route_irq_to_guest(struct domain *d, unsigned 
> int virq,
>  gic_set_irq_type(desc, desc->arch.type);
>  gic_set_irq_priority(desc, priority);
>  
> -p->desc = desc;
> -res = 0;
> -
> -out:
> -vgic_unlock_rank(v_target, rank, flags);
> -
> -return res;
> +return vgic_connect_hw_irq(d, NULL, virq, desc);
>  }
>  
>  /* This function only works with SPIs for now */
>  int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
>struct irq_desc *desc)
>  {
> -struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
> -struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
> -struct pending_irq *p = irq_to_pending(v_target, virq);
> -unsigned long flags;
> +int ret;
>  
>  ASSERT(spin_is_locked(>lock));
>  ASSERT(test_bit(_IRQ_GUEST, >status));
> -ASSERT(p->desc == desc);
>  ASSERT(!is_lpi(virq));
>  
> -vgic_lock_rank(v_target, rank, flags);
> -
>  if ( d->is_dying )
>  {
>  desc->handler->shutdown(desc);
> @@ -198,19 +171,16 @@ int gic_remove_irq_from_guest(struct domain *d, 
> unsigned int virq,
>   */
>  if ( test_bit(_IRQ_INPROGRESS, >status) ||
>   !test_bit(_IRQ_DISABLED, >status) )
> -{
> -vgic_unlock_rank(v_target, rank, flags);
>  return -EBUSY;
> -}
>  }
>  
> +ret = vgic_connect_hw_irq(d, NULL, virq, NULL);
> +if ( ret )
> +return ret;
> 

Re: [Xen-devel] [PATCH 09/12] ARM: VGIC: rework events_need_delivery()

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> In event.h we very deeply dive into the VGIC to learn if an event for
> a guest is pending.
> Rework that function to abstract the VGIC specific part out. Also
> reorder the queries there, as we only actually need to check for the
> event channel if there are no other pending IRQs.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/vgic.c | 11 +++
>  xen/include/asm-arm/event.h | 13 +++--
>  xen/include/asm-arm/vgic.h  |  2 ++
>  3 files changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 37a083e804..f8d0f46e71 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -602,6 +602,17 @@ void arch_evtchn_inject(struct vcpu *v)
>  vgic_vcpu_inject_irq(v, v->domain->arch.evtchn_irq);
>  }
>  
> +bool vgic_evtchn_irq_pending(struct vcpu *v)
> +{
> +struct pending_irq *p;
> +
> +p = irq_to_pending(v, v->domain->arch.evtchn_irq);
> +/* Does not work for LPIs. */
> +ASSERT(!is_lpi(v->domain->arch.evtchn_irq));
> +
> +return list_empty(>inflight);
> +}
> +
>  bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct vcpu *v = current;
> diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
> index caefa506a9..67684e9763 100644
> --- a/xen/include/asm-arm/event.h
> +++ b/xen/include/asm-arm/event.h
> @@ -16,12 +16,6 @@ static inline int vcpu_event_delivery_is_enabled(struct 
> vcpu *v)
>  
>  static inline int local_events_need_delivery_nomask(void)
>  {
> -struct pending_irq *p = irq_to_pending(current,
> -   current->domain->arch.evtchn_irq);
> -
> -/* Does not work for LPIs. */
> -ASSERT(!is_lpi(current->domain->arch.evtchn_irq));
> -
>  /* XXX: if the first interrupt has already been delivered, we should
>   * check whether any other interrupts with priority higher than the
>   * one in GICV_IAR are in the lr_pending queue or in the LR
> @@ -33,11 +27,10 @@ static inline int local_events_need_delivery_nomask(void)
>  if ( gic_events_need_delivery() )
>  return 1;
>  
> -if ( vcpu_info(current, evtchn_upcall_pending) &&
> -list_empty(>inflight) )
> -return 1;
> +if ( !vcpu_info(current, evtchn_upcall_pending) )
> +return 0;
>  
> -return 0;
> +return vgic_evtchn_irq_pending(current);
>  }
>  
>  static inline int local_events_need_delivery(void)
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 49b8a4bec0..dcdb1acaf3 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -219,6 +219,8 @@ 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);
>  
> +bool vgic_evtchn_irq_pending(struct vcpu *v);
> +
>  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.14.1
> 

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

Re: [Xen-devel] [PATCH 08/12] ARM: VGIC: split up gic_dump_info() to cover virtual part separately

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> Currently gic_dump_info() not only dumps the hardware state of the GIC,
> but also the VGIC internal virtual IRQ lists.
> Split the latter off and move it into vgic.c to observe the abstraction.
> 
> Signed-off-by: Andre Przywara 

Same comment on lr_pending belonging to gic.c (or now gic-vgic.c).

vgic.c is not allowed to access lr_pending, but gic.c is allowed to
access inflight, only for reading or removing interrupts at the end of
the cycle (after EOI). vgic.c is expected to manage adding irqs to
inflight and removing them, for any reasons other than "the EOI is
done". I admit it is not clear from the code.


> ---
>  xen/arch/arm/domain.c  |  1 +
>  xen/arch/arm/gic.c | 12 
>  xen/arch/arm/vgic.c| 11 +++
>  xen/include/asm-arm/vgic.h |  2 ++
>  4 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 73f4d4b2b2..5250bc2f88 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -942,6 +942,7 @@ long arch_do_vcpu_op(int cmd, struct vcpu *v, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  void arch_dump_vcpu_info(struct vcpu *v)
>  {
>  gic_dump_info(v);
> +vgic_dump_info(v);
>  }
>  
>  void vcpu_mark_events_pending(struct vcpu *v)
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 04e6d66b69..4cb74d449e 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -443,20 +443,8 @@ static void maintenance_interrupt(int irq, void *dev_id, 
> struct cpu_user_regs *r
>  
>  void gic_dump_info(struct vcpu *v)
>  {
> -struct pending_irq *p;
> -
>  printk("GICH_LRs (vcpu %d) mask=%"PRIx64"\n", v->vcpu_id, 
> v->arch.lr_mask);
>  gic_hw_ops->dump_state(v);
> -
> -list_for_each_entry ( p, >arch.vgic.inflight_irqs, inflight )
> -{
> -printk("Inflight irq=%u lr=%u\n", p->irq, p->lr);
> -}
> -
> -list_for_each_entry( p, >arch.vgic.lr_pending, lr_queue )
> -{
> -printk("Pending irq=%d\n", p->irq);
> -}
>  }
>  
>  void init_maintenance_interrupt(void)
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 2cdaca7480..37a083e804 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -656,6 +656,17 @@ void vgic_free_virq(struct domain *d, unsigned int virq)
>  clear_bit(virq, d->arch.vgic.allocated_irqs);
>  }
>  
> +void vgic_dump_info(struct vcpu *v)
> +{
> +struct pending_irq *p;
> +
> +list_for_each_entry ( p, >arch.vgic.inflight_irqs, inflight )
> +printk("Inflight irq=%u lr=%u\n", p->irq, p->lr);
> +
> +list_for_each_entry( p, >arch.vgic.lr_pending, lr_queue )
> +printk("Pending irq=%d\n", p->irq);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 0d3810e6af..49b8a4bec0 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -226,6 +226,8 @@ extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
>  const struct sgi_target *target);
>  extern bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned 
> int irq);
>  
> +void vgic_dump_info(struct vcpu *v);
> +
>  /* Reserve a specific guest vIRQ */
>  extern bool vgic_reserve_virq(struct domain *d, unsigned int virq);
>  
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH 07/12] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> Currently gic.c holds code to handle hardware IRQs as well as code to
> bridge VGIC requests to the GIC virtualization hardware.

That is true, however, I don't necessarely see "the code to bridge VGIC
requests to the GIC virtualization hardware" as belonging to the VGIC. I
think is a good abstraction to place in the GIC. That said, see below.


> Despite being named gic.c, this file reaches into the VGIC and uses data
> structures describing virtual IRQs.
> To improve abstraction, move the VGIC functions into a separate file,
> so that gic.c does what is says on the tin.

Splitting "the code to bridge VGIC requests to the GIC virtualization
hardware" is harmless, so I am OK with this patch.

One cosmetic comment below.


> Signed-off-by: Andre Przywara 
> ---
>  xen/arch/arm/Makefile   |   1 +
>  xen/arch/arm/gic-vgic.c | 395 
> 
>  xen/arch/arm/gic.c  | 348 +-
>  3 files changed, 398 insertions(+), 346 deletions(-)
>  create mode 100644 xen/arch/arm/gic-vgic.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 30a2a6500a..41d7366527 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -16,6 +16,7 @@ obj-y += domain_build.o
>  obj-y += domctl.o
>  obj-$(EARLY_PRINTK) += early_printk.o
>  obj-y += gic.o
> +obj-y += gic-vgic.o
>  obj-y += gic-v2.o
>  obj-$(CONFIG_HAS_GICV3) += gic-v3.o
>  obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
> new file mode 100644
> index 00..66cae21e82
> --- /dev/null
> +++ b/xen/arch/arm/gic-vgic.c
> @@ -0,0 +1,395 @@
> +/*
> + * xen/arch/arm/gic-vgic.c
> + *
> + * ARM Generic Interrupt Controller virtualization support
> + *
> + * Tim Deegan 
> + * Copyright (c) 2011 Citrix Systems.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +extern uint64_t per_cpu__lr_mask;

This is a bit ugly. Would the macro "get_per_cpu_var" help?


> +extern const struct gic_hw_operations *gic_hw_ops;
> +
> +#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) 
> - 1))
> +
> +#undef GIC_DEBUG
> +
> +static void gic_update_one_lr(struct vcpu *v, int i);
> +
> +static inline void gic_set_lr(int lr, struct pending_irq *p,
> +  unsigned int state)
> +{
> +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);
> +clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
> +p->lr = lr;
> +}
> +
> +static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq 
> *n)
> +{
> +struct pending_irq *iter;
> +
> +ASSERT(spin_is_locked(>arch.vgic.lock));
> +
> +if ( !list_empty(>lr_queue) )
> +return;
> +
> +list_for_each_entry ( iter, >arch.vgic.lr_pending, lr_queue )
> +{
> +if ( iter->priority > n->priority )
> +{
> +list_add_tail(>lr_queue, >lr_queue);
> +return;
> +}
> +}
> +list_add_tail(>lr_queue, >arch.vgic.lr_pending);
> +}
> +
> +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 ( unlikely(!n) )
> +return;
> +
> +ASSERT(spin_is_locked(>arch.vgic.lock));
> +
> +/* Don't try to update the LR if the interrupt is disabled */
> +if ( !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
> +return;
> +
> +if ( list_empty(>lr_queue) )
> +{
> +if ( v == current )
> +gic_update_one_lr(v, n->lr);
> +}
> +#ifdef GIC_DEBUG
> +else
> +gdprintk(XENLOG_DEBUG, "trying to inject irq=%u into d%dv%d, when it 
> is still lr_pending\n",
> + virtual_irq, v->domain->domain_id, v->vcpu_id);
> +#endif
> +}
> +
> +/*
> + * Find an unused LR to insert an IRQ into, starting with the LR given
> + * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
> + * avoid inserting the same 

Re: [Xen-devel] [PATCH 05/12] ARM: VGIC: move gic_remove_from_lr_pending()

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> gic_remove_from_lr_pending() was not only misnamed, it also had the wrong
> abstraction, as it should not live in gic.c.
> Move it into vgic.c and vgic.h, where it belongs, and rename it on the
> way.
> 
> Signed-off-by: Andre Przywara 

Like gic_clear_pending_irqs, gic_remove_from_lr_pending belongs to
gic.c. However, I agree with you that it is misnamed. I would rename it
to something like gic_clear_one_pending.


> ---
>  xen/arch/arm/gic.c |  7 ---
>  xen/arch/arm/vgic-v3-its.c |  2 +-
>  xen/arch/arm/vgic.c| 13 ++---
>  xen/include/asm-arm/gic.h  |  1 -
>  xen/include/asm-arm/vgic.h |  1 +
>  5 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index ef041354ea..59dd255c2c 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -404,13 +404,6 @@ static inline void gic_add_to_lr_pending(struct vcpu *v, 
> struct pending_irq *n)
>  list_add_tail(>lr_queue, >arch.vgic.lr_pending);
>  }
>  
> -void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
> -{
> -ASSERT(spin_is_locked(>arch.vgic.lock));
> -
> -list_del_init(>lr_queue);
> -}
> -
>  void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
>  {
>  struct pending_irq *n = irq_to_pending(v, virtual_irq);
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index d8fa44258d..5b77594723 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -449,7 +449,7 @@ static void update_lpi_vgic_status(struct vcpu *v, struct 
> pending_irq *p)
>  gic_raise_guest_irq(v, p->irq, p->lpi_priority);
>  }
>  else
> -gic_remove_from_lr_pending(v, p);
> +vgic_remove_from_lr_pending(v, p);
>  }
>  
>  static int its_handle_inv(struct virt_its *its, uint64_t *cmdptr)
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index cd50b90d67..2cdaca7480 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -345,7 +345,7 @@ void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n)
>  spin_lock_irqsave(_target->arch.vgic.lock, flags);
>  p = irq_to_pending(v_target, irq);
>  clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
> -gic_remove_from_lr_pending(v_target, p);
> +vgic_remove_from_lr_pending(v_target, p);
>  desc = p->desc;
>  spin_unlock_irqrestore(_target->arch.vgic.lock, flags);
>  
> @@ -505,18 +505,25 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>  list_for_each_entry_safe ( p, t, >arch.vgic.inflight_irqs, inflight )
>  list_del_init(>inflight);
>  list_for_each_entry_safe ( p, t, >arch.vgic.lr_pending, lr_queue )
> -gic_remove_from_lr_pending(v, p);
> +vgic_remove_from_lr_pending(v, p);
>  v->arch.lr_mask = 0;
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  }
>  
> +void vgic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
> +{
> +ASSERT(spin_is_locked(>arch.vgic.lock));
> +
> +list_del_init(>lr_queue);
> +}
> +
>  void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p)
>  {
>  ASSERT(spin_is_locked(>arch.vgic.lock));
>  
>  clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
>  list_del_init(>inflight);
> -gic_remove_from_lr_pending(v, p);
> +vgic_remove_from_lr_pending(v, p);
>  }
>  
>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 030c1d86a7..4b2a60ee64 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -242,7 +242,6 @@ extern void init_maintenance_interrupt(void);
>  extern void gic_raise_guest_irq(struct vcpu *v, unsigned int irq,
>  unsigned int priority);
>  extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
> -extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq 
> *p);
>  
>  /* Accept an interrupt from the GIC and dispatch its handler */
>  extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 8d0ff65708..0d3810e6af 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -205,6 +205,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);
>  void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p);
> +void vgic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p);
>  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);
> -- 
> 2.14.1
> 

Re: [Xen-devel] [PATCH 04/12] ARM: VGIC: move gic_remove_irq_from_queues()

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> gic_remove_irq_from_queues() was not only misnamed, it also has the wrong
> abstraction, as it should not live in gic.c.
> Move it into vgic.c and vgic.h, where it belongs to, and rename it on
> the way.
> 
> Signed-off-by: Andre Przywara 

Yes, gic_remove_irq_from_queues could be in the vgic.

Reviewed-by: Stefano Stabellini 

One comment about cosmetics below.


> ---
>  xen/arch/arm/gic.c |  9 -
>  xen/arch/arm/vgic-v3-its.c |  4 ++--
>  xen/arch/arm/vgic.c| 11 ++-
>  xen/include/asm-arm/gic.h  |  1 -
>  xen/include/asm-arm/vgic.h |  1 +
>  5 files changed, 13 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 75b2e0e0ca..ef041354ea 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -411,15 +411,6 @@ void gic_remove_from_lr_pending(struct vcpu *v, struct 
> pending_irq *p)
>  list_del_init(>lr_queue);
>  }
>  
> -void gic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p)
> -{
> -ASSERT(spin_is_locked(>arch.vgic.lock));
> -
> -clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
> -list_del_init(>inflight);
> -gic_remove_from_lr_pending(v, p);
> -}
> -
>  void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
>  {
>  struct pending_irq *n = irq_to_pending(v, virtual_irq);
> diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
> index 72a5c70656..d8fa44258d 100644
> --- a/xen/arch/arm/vgic-v3-its.c
> +++ b/xen/arch/arm/vgic-v3-its.c
> @@ -381,7 +381,7 @@ static int its_handle_clear(struct virt_its *its, 
> uint64_t *cmdptr)
>   * have no active state, we don't need to care about this here.
>   */
>  if ( !test_bit(GIC_IRQ_GUEST_VISIBLE, >status) )
> -gic_remove_irq_from_queues(vcpu, p);
> +vgic_remove_irq_from_queues(vcpu, p);
>  
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  ret = 0;
> @@ -619,7 +619,7 @@ static int its_discard_event(struct virt_its *its,
>  }
>  
>  /* Cleanup the pending_irq and disconnect it from the LPI. */
> -gic_remove_irq_from_queues(vcpu, p);
> +vgic_remove_irq_from_queues(vcpu, p);
>  vgic_init_pending_irq(p, INVALID_LPI);
>  
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 451a306a98..cd50b90d67 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -281,7 +281,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct vcpu *new, 
> unsigned int irq)
>  /* If the IRQ is still lr_pending, re-inject it to the new vcpu */
>  if ( !list_empty(>lr_queue) )
>  {
> -gic_remove_irq_from_queues(old, p);
> +vgic_remove_irq_from_queues(old, p);
>  irq_set_affinity(p->desc, cpumask_of(new->processor));
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  vgic_vcpu_inject_irq(new, irq);
> @@ -510,6 +510,15 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  }
>  
> +void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p)
> +{
> +ASSERT(spin_is_locked(>arch.vgic.lock));
> +
> +clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
> +list_del_init(>inflight);
> +gic_remove_from_lr_pending(v, p);
> +}
> +
>  void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>  {
>  uint8_t priority;
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 2f248301ce..030c1d86a7 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -243,7 +243,6 @@ extern void gic_raise_guest_irq(struct vcpu *v, unsigned 
> int irq,
>  unsigned int priority);
>  extern void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq);
>  extern void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq 
> *p);
> -extern void gic_remove_irq_from_queues(struct vcpu *v, struct pending_irq 
> *p);
>  
>  /* Accept an interrupt from the GIC and dispatch its handler */
>  extern void gic_interrupt(struct cpu_user_regs *regs, int is_fiq);
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index e489d0bf21..8d0ff65708 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -204,6 +204,7 @@ extern int vcpu_vgic_init(struct vcpu *v);
>  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);
> +void vgic_remove_irq_from_queues(struct vcpu *v, struct pending_irq *p);

cosmetic: you might as well add an extern


>  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);
> -- 
> 2.14.1
> 

Re: [Xen-devel] [PATCH 03/12] ARM: VGIC: remove gic_clear_pending_irqs()

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> gic_clear_pending_irqs() was not only misnamed, but also misplaced, as
> a function solely dealing with the GIC emulation should not live in gic.c.
> Move the functionality of this function into its only caller in vgic.c
> 
> Signed-off-by: Andre Przywara 

The reason why gic_clear_pending_irqs is in gic.c is that lr_mask and
lr_pending are considered part of the gic driver (gic.c). On the other
end, inflight is part of the vgic.

As an example, the idea is that the code outside of gic.c (for example
vgic.c) shouldn't have to know, or have to care, whether a given IRQ is
in the lr_pending queue or actually in a LR register.

lr_mask and lr_pending are only accessed from gic.c. The only exception
is the initialization (INIT_LIST_HEAD(>arch.vgic.lr_pending)).


> ---
>  xen/arch/arm/gic.c| 11 ---
>  xen/arch/arm/vgic.c   |  4 +++-
>  xen/include/asm-arm/gic.h |  1 -
>  3 files changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index ed363f6c37..75b2e0e0ca 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -675,17 +675,6 @@ out:
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  }
>  
> -void gic_clear_pending_irqs(struct vcpu *v)
> -{
> -struct pending_irq *p, *t;
> -
> -ASSERT(spin_is_locked(>arch.vgic.lock));
> -
> -v->arch.lr_mask = 0;
> -list_for_each_entry_safe ( p, t, >arch.vgic.lr_pending, lr_queue )
> -gic_remove_from_lr_pending(v, p);
> -}
> -
>  int gic_events_need_delivery(void)
>  {
>  struct vcpu *v = current;
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index d8acbbeaaa..451a306a98 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -504,7 +504,9 @@ void vgic_clear_pending_irqs(struct vcpu *v)
>  spin_lock_irqsave(>arch.vgic.lock, flags);
>  list_for_each_entry_safe ( p, t, >arch.vgic.inflight_irqs, inflight )
>  list_del_init(>inflight);
> -gic_clear_pending_irqs(v);
> +list_for_each_entry_safe ( p, t, >arch.vgic.lr_pending, lr_queue )
> +gic_remove_from_lr_pending(v, p);
> +v->arch.lr_mask = 0;
>  spin_unlock_irqrestore(>arch.vgic.lock, flags);
>  }
>  
> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index d3d7bda50d..2f248301ce 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -236,7 +236,6 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
> int virq,
>struct irq_desc *desc);
>  
>  extern void gic_inject(void);
> -extern void gic_clear_pending_irqs(struct vcpu *v);
>  extern int gic_events_need_delivery(void);
>  
>  extern void init_maintenance_interrupt(void);
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH 02/12] ARM: vGIC: fix nr_irq definition

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> The global variable "nr_irqs" is used for x86 and some common Xen code.
> To make the latter work easily for ARM, it was #defined to NR_IRQS.
> This not only violated the common habit of capitalizing macros, but
> also caused issues if one wanted to use a rather innocent "nr_irqs" as
> a local variable name or as a function parameter.
> Drop the optimization and make nr_irqs a normal variable for ARM also.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/irq.c| 2 ++
>  xen/include/asm-arm/irq.h | 2 +-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index cbc7e6ebb8..7f133de549 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +unsigned int __read_mostly nr_irqs = NR_IRQS;
> +
>  static unsigned int local_irqs_type[NR_LOCAL_IRQS];
>  static DEFINE_SPINLOCK(local_irqs_type_lock);
>  
> diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
> index 2de76d0f56..abc8f06a13 100644
> --- a/xen/include/asm-arm/irq.h
> +++ b/xen/include/asm-arm/irq.h
> @@ -31,7 +31,7 @@ struct arch_irq_desc {
>  /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */
>  #define INVALID_LPI 0
>  
> -#define nr_irqs NR_IRQS
> +extern unsigned int nr_irqs;
>  #define nr_static_irqs NR_IRQS
>  #define arch_hwdom_irqs(domid) NR_IRQS
>  
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH 01/12] ARM: remove unneeded gic.h inclusions

[Stefano Stabellini]

On Thu, 19 Oct 2017, Andre Przywara wrote:
> gic.h is supposed to hold defines and prototypes for the hardware side
> of the GIC interrupt controller. A lot of parts in Xen should not be
> bothered with that, as they either only care about the VGIC or use
> more generic interfaces.
> Remove unneeded inclusions of gic.h from files where they are actually
> not needed.
> 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/domain_build.c  | 1 -
>  xen/arch/arm/p2m.c   | 1 -
>  xen/arch/arm/platforms/vexpress.c| 1 -
>  xen/arch/arm/platforms/xgene-storm.c | 1 -
>  xen/arch/arm/time.c  | 1 -
>  xen/arch/arm/traps.c | 1 -
>  xen/arch/arm/vpsci.c | 1 -
>  xen/arch/arm/vtimer.c| 1 -
>  8 files changed, 8 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index bf29299707..e7899fbf19 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -21,7 +21,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include "kernel.h"
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 68b488997d..07f5cc4468 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -10,7 +10,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/platforms/vexpress.c 
> b/xen/arch/arm/platforms/vexpress.c
> index 39b6bcc70e..70839d676f 100644
> --- a/xen/arch/arm/platforms/vexpress.c
> +++ b/xen/arch/arm/platforms/vexpress.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #define DCC_SHIFT  26
>  #define FUNCTION_SHIFT 20
> diff --git a/xen/arch/arm/platforms/xgene-storm.c 
> b/xen/arch/arm/platforms/xgene-storm.c
> index 3b007fe5ed..deb8479a49 100644
> --- a/xen/arch/arm/platforms/xgene-storm.c
> +++ b/xen/arch/arm/platforms/xgene-storm.c
> @@ -22,7 +22,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  /* XGENE RESET Specific defines */
>  #define XGENE_RESET_ADDR0x1714UL
> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
> index 105c7410c7..36f640f0c1 100644
> --- a/xen/arch/arm/time.c
> +++ b/xen/arch/arm/time.c
> @@ -31,7 +31,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index f6f6de3691..ff3d6ff2aa 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -43,7 +43,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 0e024f7578..cd724904ef 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -15,7 +15,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 3f84893a74..f52a723a5f 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -24,7 +24,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH v3 2/2] arm/xen: vpl011: Fix SBSA UART interrupt assertion

[Stefano Stabellini]

On Tue, 24 Oct 2017, Andre Przywara wrote:
> From: Bhupinder Thakur 
> 
> With the current SBSA UART emulation, streaming larger amounts of data
> (as caused by "find /", for instance) can lead to character loses.
^ losses


> This is due to the OUT ring buffer getting full, because we change the
> TX interrupt bit only when the FIFO is actually full, and not already
> when it's half-way filled, as the Linux driver expects.
> The SBSA spec does not explicitly state this, but we assume that an
> SBSA compliant UART uses the PL011 default "interrupt FIFO level select
> register" value of "1/2 way". The Linux driver certainly makes this
> assumption, so it expect to be able to write a number of characters
> after the TX interrupt line has been asserted.
> On a similar issue we have the same wrong behaviour on the receive side.
> However changing the RX interrupt to trigger on reaching half of the FIFO
> level will lead to lag, because the guest would not be notified of incoming
> characters until the FIFO is half way filled. This leads to inacceptible
> lags when typing on a terminal.
> Real hardware solves this issue by using the "receive timeout
> interrupt" (RTI), which is triggered when character reception stops for
> 32 baud cycles. As we cannot and do not want to emulate any timing here,
> we slightly abuse the timeout interrupt to notify the guest of new
> characters: when a new character comes in, the RTI is asserted, when
> the FIFO is cleared, the interrupt gets cleared.
> 
> So this patch changes the emulated interrupt trigger behaviour to come
> as close to real hardware as possible: the RX and TX interrupt trigger
> when the FIFO gets half full / half empty, and the RTI interrupt signals
> new incoming characters.
> 
> [Andre: reword commit message, introduce receive timeout interrupt, add
> comments]
> 
> Signed-off-by: Bhupinder Thakur 
> Reviewed-by: Andre Przywara 
> Signed-off-by: Andre Przywara 

This is good, only minor cosmetic comments.

Acked-by: Stefano Stabellini 


Julien, can we have the release-ack?



> ---
>  xen/arch/arm/vpl011.c| 131 
> ++-
>  xen/include/asm-arm/vpl011.h |   2 +
>  2 files changed, 94 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 0b0743679f..6d02406acf 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -18,6 +18,9 @@
>  
>  #define XEN_WANT_FLEX_CONSOLE_RING 1
>  
> +/* We assume the PL011 default of "1/2 way" for the FIFO trigger level. */
> +#define SBSA_UART_FIFO_LEVEL (SBSA_UART_FIFO_SIZE / 2)
> +
>  #include 
>  #include 
>  #include 
> @@ -93,24 +96,37 @@ static uint8_t vpl011_read_data(struct domain *d)
>   */
>  if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) > 0 )
>  {
> +unsigned int fifo_level;
> +
>  data = intf->in[xencons_mask(in_cons, sizeof(intf->in))];
>  in_cons += 1;
>  smp_mb();
>  intf->in_cons = in_cons;
> +
> +fifo_level = xencons_queued(in_prod, in_cons, sizeof(intf->in));

This is only cosmetics but can we call xencons_queued only once? See the `if' 
just above.


> +/* If the FIFO is now empty, we clear the receive timeout interrupt. 
> */
> +if ( fifo_level == 0 )
> +{
> +vpl011->uartfr |= RXFE;
> +vpl011->uartris &= ~RTI;
> +}
> +
> +/* If the FIFO is more than half empty, we clear the RX interrupt. */
> +if ( fifo_level < sizeof(intf->in) - SBSA_UART_FIFO_LEVEL )
> +vpl011->uartris &= ~RXI;
> +
> +vpl011_update_interrupt_status(d);
>  }
>  else
>  gprintk(XENLOG_ERR, "vpl011: Unexpected IN ring buffer empty\n");
>  
> -if ( xencons_queued(in_prod, in_cons, sizeof(intf->in)) == 0 )
> -{
> -vpl011->uartfr |= RXFE;
> -vpl011->uartris &= ~RXI;
> -}
> -
> +/*
> + * We have consumed a character or the FIFO was empty, so clear the
> + * "FIFO full" bit.
> + */
>  vpl011->uartfr &= ~RXFF;
>  
> -vpl011_update_interrupt_status(d);
> -
>  VPL011_UNLOCK(d, flags);
>  
>  /*
> @@ -122,6 +138,24 @@ static uint8_t vpl011_read_data(struct domain *d)
>  return data;
>  }
>  
> +static void vpl011_update_tx_fifo_status(struct vpl011 *vpl011,
> + unsigned int fifo_level)
> +{
> +struct xencons_interface *intf = vpl011->ring_buf;
> +unsigned int fifo_threshold = sizeof(intf->out) - SBSA_UART_FIFO_LEVEL;
> +
> +BUILD_BUG_ON(sizeof (intf->out) < SBSA_UART_FIFO_SIZE);
> +
> +/*
> + * Set the TXI bit only when there is space for fifo_size/2 bytes which
> + * is the trigger level for asserting/de-assterting the TX interrupt.
> + 

Re: [Xen-devel] [PATCH v3 1/2] arm/xen: vpl011: Fix the slow early console SBSA UART output

[Stefano Stabellini]

On Tue, 24 Oct 2017, Andre Przywara wrote:
> From: Bhupinder Thakur 
> 
> The early console output uses pl011_early_write() to write data. This
> function waits for BUSY bit to get cleared before writing the next byte.
> 
> In the SBSA UART emulation logic, the BUSY bit was set as soon one
> byte was written in the FIFO and it remained set until the FIFO was
> emptied. This meant that the output was delayed as each character needed
> the BUSY to get cleared.
> 
> Since the SBSA UART is getting emulated in Xen using ring buffers, it
> ensures that once the data is enqueued in the FIFO, it will be received
> by xenconsole so it is safe to set the BUSY bit only when FIFO becomes
> full. This will ensure that pl011_early_write() is not delayed unduly
> to write the data.
> 
> Signed-off-by: Bhupinder Thakur 
> Reviewed-by: Andre Przywara 
> Signed-off-by: Andre Przywara 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/vpl011.c | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index f7ddccb42a..0b0743679f 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -159,9 +159,15 @@ static void vpl011_write_data(struct domain *d, uint8_t 
> data)
>  {
>  vpl011->uartfr |= TXFF;
>  vpl011->uartris &= ~TXI;
> -}
>  
> -vpl011->uartfr |= BUSY;
> +/*
> + * This bit is set only when FIFO becomes full. This ensures that
> + * the SBSA UART driver can write the early console data as fast as
> + * possible, without waiting for the BUSY bit to get cleared before
> + * writing each byte.
> + */
> +vpl011->uartfr |= BUSY;
> +}
>  
>  vpl011->uartfr &= ~TXFE;
>  
> @@ -371,11 +377,16 @@ static void vpl011_data_avail(struct domain *d)
>  {
>  vpl011->uartfr &= ~TXFF;
>  vpl011->uartris |= TXI;
> +
> +/*
> + * Clear the BUSY bit as soon as space becomes available
> + * so that the SBSA UART driver can start writing more data
> + * without any further delay.
> + */
> +vpl011->uartfr &= ~BUSY;
> +
>  if ( out_ring_qsize == 0 )
> -{
> -vpl011->uartfr &= ~BUSY;
>  vpl011->uartfr |= TXFE;
> -}
>  }
>  
>  vpl011_update_interrupt_status(d);
> -- 
> 2.14.1
> 

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

Re: [Xen-devel] [PATCH v6 02/13] xen/pvcalls: implement frontend disconnect

[Stefano Stabellini]

On Wed, 25 Oct 2017, Boris Ostrovsky wrote:
> On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> > +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> > +  struct sock_mapping *map, bool locked)
> > +{
> > +}
> > +
> >  static const struct xenbus_device_id pvcalls_front_ids[] = {
> > { "pvcalls" },
> > { "" }
> > @@ -27,6 +66,32 @@
> >  
> >  static int pvcalls_front_remove(struct xenbus_device *dev)
> >  {
> > +   struct pvcalls_bedata *bedata;
> > +   struct sock_mapping *map = NULL, *n;
> 
> Your last comment made me look again at sock_mapping definition. And
> then I noticed that it is not defined until patch 4 ;-(

I moved the definition of struct sock_mapping to this patch. Then, I
tested the build patch by patch. I also had to move a few #includes from
patch #5 to #4, but everything builds fine now.


> > +
> > +   bedata = dev_get_drvdata(_front_dev->dev);
> > +   dev_set_drvdata(>dev, NULL);
> > +   pvcalls_front_dev = NULL;
> > +   if (bedata->irq >= 0)
> > +   unbind_from_irqhandler(bedata->irq, dev);
> > +
> > +   smp_mb();
> > +   while (atomic_read(_refcount) > 0)
> > +   cpu_relax();
> > +   list_for_each_entry_safe(map, n, >socket_mappings, list) {
> > +   if (map->active_socket) {
> > +   /* No need to lock, refcount is 0 */
> > +   pvcalls_front_free_map(bedata, map, true);
> > +   } else {
> > +   list_del(>list);
> > +   kfree(map);
> > +   }
> > +   }
> > +   if (bedata->ref >= 0)
> > +   gnttab_end_foreign_access(bedata->ref, 0, 0);
> > +   kfree(bedata->ring.sring);
> > +   kfree(bedata);
> > +   xenbus_switch_state(dev, XenbusStateClosed);
> > return 0;
> >  }
> >  
> 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 114825

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

version targeted for testing:
 libvirt  f4973d1ea88b2e807fc2c52a5fc281a1c289d50e
baseline version:
 libvirt  08d4e16f88f9cb0e078b544f49a0647c8847fe95

Last test of basis   114825  2017-10-21 04:47:31 Z4 days
Failing since115172  2017-10-24 04:20:11 Z1 days2 attempts
Testing same since   115202  2017-10-25 04:30:44 Z0 days1 attempts


People who touched revisions under test:
  Jiri Denemark 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2pass
 test-armhf-armhf-libvirt-raw fail
 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


Not pushing.


commit f4973d1ea88b2e807fc2c52a5fc281a1c289d50e
Author: Peter Krempa 
Date:   Tue Oct 10 17:19:10 2017 +0200

virsh: domain: Fix option handling in domxml-to-native

Commit fdeac7a05fdf85458d72e89efcfa0f444525aaad tried to fix the output
of 'virsh domxml-to-native --help' by switching types around. One of the
changes broke the option parser. VSH_OT_ARGV should be used only for
variable 

Re: [Xen-devel] [PATCH v6 12/13] xen/pvcalls: implement release command

[Stefano Stabellini]

On Wed, 25 Oct 2017, Boris Ostrovsky wrote:
> On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> > Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> > in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> > socket.
> >
> > For passive sockets, check whether we have already pre-allocated an
> > active socket for the purpose of being accepted. If so, free that as
> > well.
> >
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > ---
> >  drivers/xen/pvcalls-front.c | 100 
> > 
> >  drivers/xen/pvcalls-front.h |   1 +
> >  2 files changed, 101 insertions(+)
> >
> > diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> > index 4a413ff..7abc039 100644
> > --- a/drivers/xen/pvcalls-front.c
> > +++ b/drivers/xen/pvcalls-front.c
> > @@ -199,6 +199,23 @@ static irqreturn_t pvcalls_front_event_handler(int 
> > irq, void *dev_id)
> >  static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> >struct sock_mapping *map, bool locked)
> >  {
> > +   int i;
> > +
> > +   unbind_from_irqhandler(map->active.irq, map);
> > +
> > +   if (!locked)
> > +   spin_lock(>socket_lock);
> > +   if (!list_empty(>list))
> > +   list_del_init(>list);
> > +   if (!locked)
> > +   spin_unlock(>socket_lock);
> > +
> > +   for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
> > +   gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
> > +   gnttab_end_foreign_access(map->active.ref, 0, 0);
> > +   free_page((unsigned long)map->active.ring);
> > +
> > +   kfree(map);
> >  }
> >  
> >  static irqreturn_t pvcalls_front_conn_handler(int irq, void *sock_map)
> > @@ -966,6 +983,89 @@ unsigned int pvcalls_front_poll(struct file *file, 
> > struct socket *sock,
> > return ret;
> >  }
> >  
> > +int pvcalls_front_release(struct socket *sock)
> > +{
> > +   struct pvcalls_bedata *bedata;
> > +   struct sock_mapping *map;
> > +   int req_id, notify, ret;
> > +   struct xen_pvcalls_request *req;
> > +
> 
> ..
> 
> > +
> > +   if (map->active_socket) {
> > +   /*
> > +* Set in_error and wake up inflight_conn_req to force
> > +* recvmsg waiters to exit.
> > +*/
> > +   map->active.ring->in_error = -EBADF;
> > +   wake_up_interruptible(>active.inflight_conn_req);
> > +
> > +   /*
> > +* Wait until there are no more waiters on the mutexes.
> > +* We know that no new waiters can be added because sk_send_head
> > +* is set to NULL -- we only need to wait for the existing
> > +* waiters to return.
> > +*/
> > +   while (!mutex_trylock(>active.in_mutex) ||
> > +  !mutex_trylock(>active.out_mutex))
> > +   cpu_relax();
> > +
> > +   pvcalls_front_free_map(bedata, map, false);
> > +   } else {
> > +   spin_lock(>socket_lock);
> > +   if (READ_ONCE(map->passive.inflight_req_id) !=
> > +   PVCALLS_INVALID_ID) {
> > +   pvcalls_front_free_map(bedata,
> > +  map->passive.accept_map, true);
> > +   }
> > +   list_del(>list);
> > +   kfree(map);
> > +   spin_unlock(>socket_lock);
> 
> We have different locking rules in pvcalls_front_free_map() for each of
> those clauses in that in the first case we are doing grant table
> operations and free_page() without the lock and in the second case we
> are holding it. Is it possible to restructure this so that we prune the
> lists under the lock (possibly in this routine) and call
> pvcalls_front_free_map() lock-less?

Yes, it is possible. However, pvcalls_front_free_map is called from a
couple of other places (pvcalls_front_accept and pvcalls_front_remove)
and we would have to add the code to remove the map from the list there
as well. I am not sure it is worth it.

I don't have a strong opinion on this. Let me know which way you prefer.

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

Re: [Xen-devel] [PATCH v6 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Stefano Stabellini]

On Wed, 25 Oct 2017, Boris Ostrovsky wrote:
> On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> > Also add pvcalls-front to the Makefile.
> >
> > Signed-off-by: Stefano Stabellini 
> > CC: boris.ostrov...@oracle.com
> > CC: jgr...@suse.com
> > ---
> >  drivers/xen/Kconfig  | 9 +
> >  drivers/xen/Makefile | 1 +
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> > index 4545561..0b2c828 100644
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -196,6 +196,15 @@ config XEN_PCIDEV_BACKEND
> >  
> >   If in doubt, say m.
> >  
> > +config XEN_PVCALLS_FRONTEND
> > +   tristate "XEN PV Calls frontend driver"
> > +   depends on INET && XEN
> > +   help
> > + Experimental frontend for the Xen PV Calls protocol
> > + (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It
> > + sends a small set of POSIX calls to the backend, which
> > + implements them.
> 
> default n ?
> 
> (and maybe select XEN_XENBUS_FRONTEND)

Yes, good ideas, I'll add


> > +
> >  config XEN_PVCALLS_BACKEND
> > bool "XEN PV Calls backend driver"
> > depends on INET && XEN && XEN_BACKEND
> > diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> > index 480b928..afb9e03 100644
> > --- a/drivers/xen/Makefile
> > +++ b/drivers/xen/Makefile
> > @@ -39,6 +39,7 @@ obj-$(CONFIG_XEN_EFI) += efi.o
> >  obj-$(CONFIG_XEN_SCSI_BACKEND) += xen-scsiback.o
> >  obj-$(CONFIG_XEN_AUTO_XLATE)   += xlate_mmu.o
> >  obj-$(CONFIG_XEN_PVCALLS_BACKEND)  += pvcalls-back.o
> > +obj-$(CONFIG_XEN_PVCALLS_FRONTEND) += pvcalls-front.o
> >  xen-evtchn-y   := evtchn.o
> >  xen-gntdev-y   := gntdev.o
> >  xen-gntalloc-y := gntalloc.o
> 

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

Re: [Xen-devel] Libvirt xl to xml converter only picks up first occurrence of an option

[Jim Fehlig]

On 10/20/2017 08:46 AM, Wei Liu wrote:

Hi Jim


Hi Wei,

Sorry for the delay. Catching up on mail after some days off...


I discovered that libvirt's native config file to xml converter for
libxl only pick up the first occurrence of an option.

For example in a xl cfg file:

extra = "abc"
...
extra = "def"

xl will pick up "def" because that shows up later and takes precedence,
while the converter picks up "abc".

I think this is a bug in the converter and should be fixed.


Thanks for the report. I took a quick peek at libvirt's generic config parser 
and afaict it only searches for the first occurrence of a setting. The parser 
does support flags though, so we could add something like 
VIR_CONF_FLAG_{FIRST,LAST}_DUPLICATE. (Better name suggestions welcomed.)


I've opened a bug report against openSUSE Factory to track this

https://bugzilla.opensuse.org/show_bug.cgi?id=1065118

Regards,
Jim




Thanks
Wei.




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

Re: [Xen-devel] Xen-unstable + dom0 linux-4.14-rc6: bisected pci-passthrough problem to HVM

[Sander Eikelenboom]

On 25/10/17 22:34, Boris Ostrovsky wrote:
> On 10/25/2017 04:05 PM, Sander Eikelenboom wrote:
>> Hi Juergen and Boris,
>>
>> While testing out linux 4.14-rc6 i found some trouble with one of my devices 
>> for which I use pci-passthrough. 
>> It fails to start a HVM when configured to use pci-passthrough on this 
>> particular device (see below for lspci output)
>> Using other pci devices for passthrough still works ok, it seems only this 
>> particular device is affected on my system.
>>
>> libxl: error: libxl_qmp.c:457:qmp_next: Domain 3:Socket read error: 
>> Connection reset by peer
>> libxl: error: libxl_pci.c:1295:libxl__add_pcidevs: Domain 
>> 3:libxl_device_pci_add failed: -3
>> libxl: error: libxl_create.c:1495:domcreate_attach_devices: Domain 3:unable 
>> to add pci devices
>> libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 
>> 3:Non-existant domain
>> libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 3:Unable to 
>> destroy guest
>> libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 3:Destruction of 
>> domain failed
>>
>> I bisected the dom0 kernel and found:
>> ce56a86e2ade45d052b3228cdfebe913a1ae7381 is the first bad commit
>> commit ce56a86e2ade45d052b3228cdfebe913a1ae7381
>> Author: Craig Bergstrom 
>> Date:   Thu Oct 19 13:28:56 2017 -0600
>>
>> x86/mm: Limit mmap() of /dev/mem to valid physical addresses
> 
> Consider yourself lucky, at least you didn't crash ;-)

*lol*

> 
> https://lkml.org/lkml/2017/10/23/652

Can't beat the 0-day-bot ;)
At least nothing Xen specific then, thx for the pointer !

> 
> -boris
> 
--
Sander

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

Re: [Xen-devel] Xen-unstable + dom0 linux-4.14-rc6: bisected pci-passthrough problem to HVM

[Boris Ostrovsky]

On 10/25/2017 04:05 PM, Sander Eikelenboom wrote:
> Hi Juergen and Boris,
>
> While testing out linux 4.14-rc6 i found some trouble with one of my devices 
> for which I use pci-passthrough. 
> It fails to start a HVM when configured to use pci-passthrough on this 
> particular device (see below for lspci output)
> Using other pci devices for passthrough still works ok, it seems only this 
> particular device is affected on my system.
>
> libxl: error: libxl_qmp.c:457:qmp_next: Domain 3:Socket read error: 
> Connection reset by peer
> libxl: error: libxl_pci.c:1295:libxl__add_pcidevs: Domain 
> 3:libxl_device_pci_add failed: -3
> libxl: error: libxl_create.c:1495:domcreate_attach_devices: Domain 3:unable 
> to add pci devices
> libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 3:Non-existant 
> domain
> libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 3:Unable to 
> destroy guest
> libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 3:Destruction of 
> domain failed
>
> I bisected the dom0 kernel and found:
> ce56a86e2ade45d052b3228cdfebe913a1ae7381 is the first bad commit
> commit ce56a86e2ade45d052b3228cdfebe913a1ae7381
> Author: Craig Bergstrom 
> Date:   Thu Oct 19 13:28:56 2017 -0600
>
> x86/mm: Limit mmap() of /dev/mem to valid physical addresses

Consider yourself lucky, at least you didn't crash ;-)

https://lkml.org/lkml/2017/10/23/652


-boris


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

Re: [Xen-devel] [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to not pass a structure by value

[Andrew Cooper]

On 25/10/17 15:55, Ian Jackson wrote:
> I have reordered the quoted text, and my replies, so as to address the
> most technical points first and leave what might be described as
> process arguments and tone complaints for later.

I will keep my reply to the technical points.  I didn't enjoy writing
that email, but it has unblocking things in a more productive direction.

>
>
> Andrew Cooper writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix 
> precopy_policy() to not pass a structure by value"):
>> someone who does understand why hiding a prologue memcpy() is bad for
>> performance.
> To address your actual technical point about the memcpy.
>
> Not all functions in the toolstack are performance critical and not
> all putative tiny performance benefits are worthwhile.  Most are not.
> Code should generally be written to be as clear and simple as
> possible, and clarity and simplicity should be traded off for
> performance only when this will produce a noticeable difference.
>
> Obviously clarity is a matter of opinion, but I would generally say
> that a struct containing plain data is simpler than a pointer to a
> similar struct.  And of course passing as a pointer requires (or, in
> this case, will eventually require) additional complexity in the
> message generator script.
>
> Against that, in this case, the cost of the additional alleged-memcpy
> seems to me, at first glance, to be completely irrelevant.
>
> Of course it probably isn't going to be a memcpy; the struct contents
> will probably be passed in registers (I haven't double-checked ABI
> manuals so this may be wrong on some register-poor architectures).

32bit would pass this as memory.  64bit (I think) will end up in
registers with its current content and location in the parameter list,
but will end up as memory if it grows any further.

> Given the small size of this struct, it might well be slightly faster
> to pass it in a pair of registers rather than a pointer to memory, for
> locality of reference reasons.

This will depend on register pressure in the callee, and whether that
causes it to be spilling to the stack.  I will be spilled to the stack
by the callee if the structures address is ever taken.

> I think the most significant proportional performance impact would be
> the case where there is a callback but only within the migration
> process.  Ie, an out-of-tree provider of the precopy_policy hook.
> (If there is no callback provided, there is no cost; and an in-tree
> consumer will have the IPC cost which will dominate.)

The callback is via function pointer, so can't be inlined.  The default
case puts simple_policy() in the hook if no hook was provided.

After that, it depends how many functions are called between
send_memory_live() and the variable having useful actions performed on it.

>> On 19/10/17 16:17, Ian Jackson wrote:
>>> Andrew Cooper writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix 
>>> precopy_policy() to not pass a structure by value"):
 On 16/10/17 16:07, Ian Jackson wrote:
> This statement is true only if you think "the precopy callback" refers
> to the stub generated by libxl_save_msgs_gen.
 The commit is about save_callbacks.precopy_policy() specifically (and
 IMO, obviously).
 Given this, the statement is true.
>>> I don't agree.
>> Don't agree with what?  The justification for why passing-by-value is
>> supposedly necessary is bogus irrespective of whether you consider just
>> the libxc part of the callback, or the end-to-end path into libxl.
>>
>> No argument concerning address space (separate or otherwise) is a
>> related to how parameter passing needs to happen at this level.
>>
>> FAOD, the actual reason why it was done that way was because no-one
>> wanted to edit libxl_save_msgs_gen.pl to be able to cope with pointers,
>> but "$WE don't want to do it properly" is not a reasonable justification.
> This argument depends on a view of "properly" which I don't share.
> Ie your argument seems circular to me.

My argument is not circular.  The code in tree at the moment reads:

/*  



 * A precopy_policy callback may not be running in the same
address 


 * space as libxc an so precopy_stats is passed by
value.  
 

 */

which is factually incorrect.

If the comment instead read "the libxl code generated by
libxl_save_msgs_gen.pl likes to take its parameters by value", then it
would be a very different matter (but still not a good enough reason IMO
to break from common case and pass by pointer) hence why I adjusted the
code in the way that I did.

>
> However, I hope it is 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 114644
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114644
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114644

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

version targeted for testing:
 xen  be7f60b5a39741eab0a8fea0324f7be0cb724cfb
baseline version:
 xen  24fb44e971a62b345c7b6ca3c03b454a1e150abe

Last test of basis   114644  2017-10-17 10:49:11 Z8 days
Failing since114670  2017-10-18 05:03:38 Z7 days   11 attempts
Testing same since   115195  2017-10-24 19:29:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony PERARD 
  Chao Gao 
  David Esler 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Roger Pau Monné 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 

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

Re: [Xen-devel] [adhoc test] 115230: all pass

[Julien Grall]

(+ Jan and Andrew)

Hi,

Discussing with Ian today, we decided to try reproducing the Windows 
failure on one of the board where the test was passing.


This is still passing so it does not seem to be a random success. I 
would say the bug is somehow related to merlot/pinot hardware.


This also means a force push would not be the right solution as we may 
end up to a success again in the near future.


Cheers,

On 10/25/2017 07:53 PM, i...@xenbits.xen.org wrote:

[adhoc adhoc] 
harness 8f16840: MaxUmask: enforce a maximum umask value
115230: all pass

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

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

jobs:
  test-amd64-amd64-xl-qemuu-ws16-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


2017-10-25 16:12:34 Z flight 115230 nqueued=1
2017-10-25 16:12:34 Z flight 115230 spawning 
test-amd64-amd64-xl-qemuu-ws16-amd64
2017-10-25 16:12:34 Z flight 115230 spawned  
test-amd64-amd64-xl-qemuu-ws16-amd64 [5539]
2017-10-25 16:12:34 Z flight 115230 nrunning=1
2017-10-25 16:12:37 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-build-check  build-check(1)
2017-10-25 16:12:37 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-build-check
2017-10-25 16:12:38 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-build-check  pass
2017-10-25 16:12:38 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-hosts-allocate host 
hosts-allocate
2017-10-25 16:12:39 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-hosts-allocate host
2017-10-25 17:41:16 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-hosts-allocate host pass
2017-10-25 17:41:17 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-syslog-server  syslog-server
2017-10-25 17:41:18 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-install-twice host 
host-install(4)
2017-10-25 17:41:18 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-install-twice host
2017-10-25 17:51:30 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-install-twice host pass
2017-10-25 17:51:31 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host 
host-ping-check-native
2017-10-25 17:51:31 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host
2017-10-25 17:51:52 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host pass
2017-10-25 17:51:53 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-xen-install host xen-install
2017-10-25 17:51:53 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-xen-install host
2017-10-25 17:53:13 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-xen-install host pass
2017-10-25 17:53:13 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-reboot host xen-boot
2017-10-25 17:53:14 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-reboot host
2017-10-25 17:54:25 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-reboot host pass
2017-10-25 17:54:25 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host 
host-ping-check-xen
2017-10-25 17:54:26 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host
2017-10-25 17:54:47 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host pass
2017-10-25 17:54:47 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 

[Xen-devel] [adhoc test] 115230: all pass

[iwj]

[adhoc adhoc] 
harness 8f16840: MaxUmask: enforce a maximum umask value
115230: all pass

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

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

jobs:
 test-amd64-amd64-xl-qemuu-ws16-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


2017-10-25 16:12:34 Z flight 115230 nqueued=1
2017-10-25 16:12:34 Z flight 115230 spawning 
test-amd64-amd64-xl-qemuu-ws16-amd64
2017-10-25 16:12:34 Z flight 115230 spawned  
test-amd64-amd64-xl-qemuu-ws16-amd64 [5539]
2017-10-25 16:12:34 Z flight 115230 nrunning=1
2017-10-25 16:12:37 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-build-check  build-check(1)
2017-10-25 16:12:37 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-build-check 
2017-10-25 16:12:38 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-build-check  pass 
2017-10-25 16:12:38 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-hosts-allocate host 
hosts-allocate
2017-10-25 16:12:39 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-hosts-allocate host
2017-10-25 17:41:16 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-hosts-allocate host pass 
2017-10-25 17:41:17 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-syslog-server  syslog-server
2017-10-25 17:41:18 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-install-twice host 
host-install(4)
2017-10-25 17:41:18 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-install-twice host
2017-10-25 17:51:30 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-install-twice host pass 
2017-10-25 17:51:31 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host 
host-ping-check-native
2017-10-25 17:51:31 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host
2017-10-25 17:51:52 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host pass 
2017-10-25 17:51:53 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-xen-install host xen-install
2017-10-25 17:51:53 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-xen-install host
2017-10-25 17:53:13 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-xen-install host pass 
2017-10-25 17:53:13 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-reboot host xen-boot
2017-10-25 17:53:14 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-reboot host
2017-10-25 17:54:25 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-reboot host pass 
2017-10-25 17:54:25 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host 
host-ping-check-xen
2017-10-25 17:54:26 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host
2017-10-25 17:54:47 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-host-ping-check host pass 
2017-10-25 17:54:47 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-leak-check basis host 
leak-check/basis(9)
2017-10-25 17:54:47 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] awaiting 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-leak-check basis host
2017-10-25 17:54:50 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] finished 
115230.test-amd64-amd64-xl-qemuu-ws16-amd64 ts-leak-check basis host pass 
2017-10-25 17:54:50 Z [test-amd64-amd64-xl-qemuu-ws16-amd64] starting 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-221 xtf/test-hvm32-invlpg~shadow fail REGR. vs. 72239
 test-xtf-amd64-amd64-2 36 xtf/test-hvm32pae-invlpg~shadow fail REGR. vs. 72239
 test-xtf-amd64-amd64-248 xtf/test-hvm64-invlpg~shadow fail REGR. vs. 72239
 test-amd64-i386-freebsd10-amd64 11 guest-startfail REGR. vs. 72239
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 72239
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 72239

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

version targeted for testing:
 xen  9454e3030ae0835c11aa66471238a9e09db5074e
baseline version:
 xen  aad5a67587b493e2478e1e46f71404c3dd41a937

Last test of basis72239  2017-10-16 02:44:01 Z9 days
Testing same since72351  2017-10-25 10:43:49 Z0 days1 attempts

Re: [Xen-devel] [PATCH] xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

[Boris Ostrovsky]

On 10/25/2017 11:08 AM, Juergen Gross wrote:
> In case gntdev_mmap() succeeds only partially in mapping grant pages
> it will leave some vital information uninitialized needed later for
> cleanup. This will lead to an out of bounds array access when unmapping
> the already mapped pages.
>
> So just initialize the data needed for unmapping the pages a little bit
> earlier.
>
> Cc: 
> Reported-by: Arthur Borsboom 
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [BUG] xen_gntdev - gntdev_vma_find_special_page - unable to handle kernel paging request

[Arthur Borsboom]

JG> Can I add you as "Reported-by:" ?

Absolutely.
If I can be of any assistance, please let me know. Keep in mind that I am
an application developer (J2EE) and not a hardware/kernel/hypervisor
hacker. :-)

On 25 October 2017 at 16:13, Juergen Gross  wrote:

> On 25/10/17 13:17, Arthur Borsboom wrote:
> > Since about a month, possibly due to software updates, after a couple of
> > days running several VMs, one of the VM guests crashes and the VM host
> > is not stable anymore. I need to shutdown all the remaining VM guests
> > (if possible) and reboot the server by hardware (sudo reboot hangs).
> >
> > Does anybody have a suggestion how to analyze/resolve this?
>
> Hmm, it seems as if gntdev_mmap() is mapping only some pages and then
> exits with an error. This will leave map->pages_vm_start as 0 leading
> to a problem when the already mapped pages are being unmapped again.
>
> Patch will come soon...
>
> Can I add you as "Reported-by:" ?
>
>
> Juergen
>
> > All help is appreciated!
> >
> > Xen: 4.9.0
> > OS (Dom0): Arch Linux 4.13.7
> > Dmesg:
> >
> > [131395.101610] BUG: unable to handle kernel paging request at
> > 88401920c018
> > [131395.101715] IP: gntdev_vma_find_special_page+0x1d/0x30 [xen_gntdev]
> > [131395.101796] PGD 1a0a067
> > [131395.101797] P4D 1a0a067
> > [131395.101832] PUD 0
> > [131395.101922] Oops:  [#1] PREEMPT SMP
> > [131395.101975] Modules linked in: xt_nat xt_physdev br_netfilter
> > xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> > iptable_nat nf_nat_ipv4 nf_nat tun bridge stp llc ebtable_filter
> > ebtables devlink ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_conntrack_ipv4
> > nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c crc32c_generic
> > ip6table_filter iptable_filter ip6_tables snd_hda_codec_realtek amdkfd
> > snd_hda_codec_generic snd_hda_codec_hdmi amd_iommu_v2 snd_hda_intel
> > radeon joydev snd_hda_codec mousedev evdev input_leds led_class mac_hid
> > ppdev wmi_bmof snd_hda_core i2c_algo_bit ttm snd_hwdep snd_pcm
> > edac_mce_amd drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel
> > ghash_clmulni_intel snd_timer pcbc r8169 aesni_intel psmouse aes_x86_64
> > crypto_simd glue_helper tpm_infineon drm cryptd tpm_tis snd pcspkr
> > [131395.102862]  agpgart sp5100_tco tpm_tis_core mii syscopyarea
> > sysfillrect tpm i2c_piix4 sysimgblt soundcore parport_pc parport
> > fb_sys_fops fam15h_power k10temp wmi shpchp button sch_fq_codel
> > xen_acpi_processor xen_pciback xen_netback xen_blkback xenfs
> > xen_gntalloc xen_gntdev xen_evtchn xen_privcmd ip_tables x_tables ext4
> > crc16 mbcache jbd2 fscrypto hid_generic usbhid hid sd_mod ata_generic
> > pata_acpi ohci_pci pata_atiixp serio_raw atkbd libps2 ahci ehci_pci
> > libahci ehci_hcd ohci_hcd libata usbcore scsi_mod usb_common i8042 serio
> > [131395.103469] CPU: 0 PID: 10887 Comm: qemu-dm Not tainted
> 4.13.7-1-ARCH #1
> > [131395.103554] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD
> > MS-7596/760GM-E51(MS-7596), BIOS V3.6 10/26/2012
> > [131395.103677] task: 8800483b1e00 task.stack: c90046598000
> > [131395.103759] RIP: e030:gntdev_vma_find_special_page+0x1d/0x30
> > [xen_gntdev]
> > [131395.103852] RSP: e02b:c9004659bb60 EFLAGS: 00010212
> > [131395.103927] RAX: 88001ef0a360 RBX: 8800119a0cb8 RCX:
> > 00624684
> > [131395.104018] RDX: 800624684367 RSI: 0007ff460397 RDI:
> > 88003dd7b240
> > [131395.104108] RBP: c9004659bb70 R08: 88003dd7b240 R09:
> > 7ff4603a2000
> > [131395.104198] R10: 0001 R11: 3000 R12:
> > 7ff460397000
> > [131395.104288] R13: 800624684367 R14: 7ff460398000 R15:
> > c9004659bce0
> > [131395.104390] FS:  7ff4605667c0() GS:88005500()
> > knlGS:
> > [131395.104490] CS:  e033 DS:  ES:  CR0: 80050033
> > [131395.104564] CR2: 88401920c018 CR3: 1cb0f000 CR4:
> > 00040660
> > [131395.104655] Call Trace:
> > [131395.104695]  ? vm_normal_page+0x5d/0xa0
> > [131395.104748]  unmap_page_range+0x4e3/0x930
> > [131395.104804]  unmap_single_vma+0x7d/0xf0
> > [131395.104857]  unmap_vmas+0x51/0xb0
> > [131395.104904]  unmap_region+0xbd/0x130
> > [131395.104953]  ? gnttab_map_refs+0xc4/0x160
> > [131395.105009]  ? gntdev_mmap+0x3a4/0x610 [xen_gntdev]
> > [131395.105074]  mmap_region+0x461/0x5f0
> > [131395.105122]  do_mmap+0x2b3/0x400
> > [131395.105167]  vm_mmap_pgoff+0xcc/0x120
> > [131395.105217]  SyS_mmap_pgoff+0x1bc/0x230
> > [131395.105271]  SyS_mmap+0x1b/0x30
> > [131395.108716]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> > [131395.112161] RIP: 0033:0x7ff45dcc3e63
> > [131395.115644] RSP: 002b:7ffdf0c57648 EFLAGS: 0246 ORIG_RAX:
> > 0009
> > [131395.119149] RAX: ffda RBX: a000 RCX:
> > 7ff45dcc3e63
> > [131395.122587] RDX: 0002 RSI: b000 RDI:
> > 
> > [131395.126005] RBP: 1000 R08: 002a R09:
> 

Re: [Xen-devel] [OSSTEST PATCH 00/16] Upgrade to Stretch

[Wei Liu]

On Fri, Oct 20, 2017 at 11:38:24AM +0100, Wei Liu wrote:
> 6. Rumprun doesn't build due to its build system can't cope. This should be
>fixed in rumprun.

There are two bugs:

https://github.com/rumpkernel/rumprun/issues/99 (also numerous
duplicates)
https://github.com/rumpkernel/rumprun/issues/101

I have taken a stab at the first one; the second one really needs Antti
to fix -- the fix needs to be in netbsd first then gets pulled in to
src-netbsd used by rumprun.

No reply from Antti has been made in the past 4 months.  If we don't
hear back from Antti, there is no way we can fix that. I don't have
commit access to src-netbsd. I will try to ask on #rumpkernel.  But if
nothing is going to happen I propose we drop the rumprun tests.

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

[Xen-devel] [PATCH v3 for-4.10] scripts: introduce a script for build test

[Wei Liu]

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

v3:
1. Use git-clean in default rune.
2. Print more friendly message.
3. Restore HEAD automatically.
---
 scripts/build-test.sh | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100755 scripts/build-test.sh

diff --git a/scripts/build-test.sh b/scripts/build-test.sh
new file mode 100755
index 00..f55ec5d4fa
--- /dev/null
+++ b/scripts/build-test.sh
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+# Run command on every commit within the range specified. If no command is
+# provided, use the default one to clean and build the whole tree.
+#
+# The default rune is rather simple. To do a cross-build, please put your usual
+# build rune in a shell script and invoke it with this script.
+
+if ! test -f xen/common/kernel.c; then
+echo "Please run this script from top-level directory"
+exit 1
+fi
+
+if test $# -lt 2 ; then
+echo "Usage: $0   [CMD]"
+exit 1
+fi
+
+status=`git status -s`
+if test -n "$status"; then
+echo "Tree is dirty, aborted"
+exit 1
+fi
+
+BASE=$1; shift
+TIP=$1; shift
+
+ORIG_BRANCH=`git symbolic-ref -q --short HEAD`
+if test $? -ne 0; then
+echo "Detached HEAD, aborted"
+exit 1
+fi
+
+trap "echo Restoring original HEAD ; git checkout $ORIG_BRANCH" EXIT
+
+git rev-list $BASE..$TIP | nl -ba | tac | \
+while read num rev; do
+echo "Testing $num $rev"
+git checkout $rev
+if test $# -eq 0 ; then
+git clean -fdx && ./configure && make -j4
+else
+"$@"
+fi
+if test $? -ne 0; then
+echo "Failed at $num $rev"
+exit 1
+fi
+echo
+done
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Wei Liu]

On Wed, Oct 25, 2017 at 04:47:33PM +0100, George Dunlap wrote:
> On 10/25/2017 04:27 PM, Wei Liu wrote:
> > On Wed, Oct 25, 2017 at 04:25:21PM +0100, Ian Jackson wrote:
> >> Wei Liu writes ("Re: [PATCH v2] scripts: introduce a script for build 
> >> test"):
> >>> On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
>  Anthony PERARD writes ("Re: [PATCH v2] scripts: introduce a script for 
>  build test"):
> > That feels wrong. How do I run the same exact command at the default
> > one, but with -j8 instead of -j4?
> 
>   .../build-test sh -ec make -j4 distclean && ./configure && make -j4
> 
>  But I think Anthony has a point.  The clean should 1. be git-clean,
>  not make distclean 2. be run anyway.
> >>>
> >>> I don't think we should call git-clean unconditionally -- imagine
> >>> someone knew for sure they only needed to build part of the tools or the
> >>> hypervisor.
> >>
> >> If you are worried about this you should check that there are no
> >> uncommitted files before starting.
> > 
> > This is already done in this version.
> > 
> > I don't worry if there is uncommitted file, I just don't want to stop
> > developers from being smarter than the script when they know git-clean
> > is not necessary.
> 

> What kind of "smarter" did you have in mind?
> 
> This script sounds like an aid to developers who don't have the
> motivation / experience / whatever to write their own script (or do
> something fancier, like git rebase --exec).  If people want to be
> smarter they can write their own script, using this as a starting point.

Exactly. If they want to supply their script, then fine. We shouldn't do
a git-clean for them.

I'm fine with using 'git clean' in the default rune but I don't want to
use it unconditionally.


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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Wei Liu]

On Wed, Oct 25, 2017 at 04:42:44PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2] scripts: introduce a script for build test"):
> > On Wed, Oct 25, 2017 at 04:25:21PM +0100, Ian Jackson wrote:
> > > If you are worried about this you should check that there are no
> > > uncommitted files before starting.
> > 
> > This is already done in this version.
> > 
> > I don't worry if there is uncommitted file, I just don't want to stop
> > developers from being smarter than the script when they know git-clean
> > is not necessary.
> 
> I don't understand your point.  If there are no uncommitted files at
> the start of the run, then git clean is certainly safe later, since
> everything that will be deleted was made by `make'.  Therefore doing
> it unconditionally is fine.

I mean I don't want git-clean to delete all the object files so that they
don't need to be rebuilt.

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2] scripts: introduce a script for build test"):
> On Wed, Oct 25, 2017 at 04:25:21PM +0100, Ian Jackson wrote:
> > If you are worried about this you should check that there are no
> > uncommitted files before starting.
> 
> This is already done in this version.
> 
> I don't worry if there is uncommitted file, I just don't want to stop
> developers from being smarter than the script when they know git-clean
> is not necessary.

I don't understand your point.  If there are no uncommitted files at
the start of the run, then git clean is certainly safe later, since
everything that will be deleted was made by `make'.  Therefore doing
it unconditionally is fine.

Ian.

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

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Zhongze Liu]

2017-10-25 17:37 GMT+08:00 Zhongze Liu :
> Hi,
>
> My current plan is to add the following new MAPSPACE to public/memory.h:
>
> +#define XENMEMSPACE_gmfn_foreign_share 6 /* Same as *_gmfn_foreign, but this 
> is
> +for a privileged dom to
> +shared pages between two doms. */

s/shared/share

>
> and create a corresponding  entry xsm_map_gmfn_foreign_share to the
> xsm structure, which will be filled with
> the proposed policy.
>
> Does this look good to you?
>
> Cheers,
>
> Zhongze Liu

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[George Dunlap]

On 10/25/2017 04:27 PM, Wei Liu wrote:
> On Wed, Oct 25, 2017 at 04:25:21PM +0100, Ian Jackson wrote:
>> Wei Liu writes ("Re: [PATCH v2] scripts: introduce a script for build test"):
>>> On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
 Anthony PERARD writes ("Re: [PATCH v2] scripts: introduce a script for 
 build test"):
> That feels wrong. How do I run the same exact command at the default
> one, but with -j8 instead of -j4?

  .../build-test sh -ec make -j4 distclean && ./configure && make -j4

 But I think Anthony has a point.  The clean should 1. be git-clean,
 not make distclean 2. be run anyway.
>>>
>>> I don't think we should call git-clean unconditionally -- imagine
>>> someone knew for sure they only needed to build part of the tools or the
>>> hypervisor.
>>
>> If you are worried about this you should check that there are no
>> uncommitted files before starting.
> 
> This is already done in this version.
> 
> I don't worry if there is uncommitted file, I just don't want to stop
> developers from being smarter than the script when they know git-clean
> is not necessary.

What kind of "smarter" did you have in mind?

This script sounds like an aid to developers who don't have the
motivation / experience / whatever to write their own script (or do
something fancier, like git rebase --exec).  If people want to be
smarter they can write their own script, using this as a starting point.

FWIW in xsatool I use 'git clean' extensively.

 -George

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Wei Liu]

On Wed, Oct 25, 2017 at 04:25:21PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH v2] scripts: introduce a script for build test"):
> > On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
> > > Anthony PERARD writes ("Re: [PATCH v2] scripts: introduce a script for 
> > > build test"):
> > > > That feels wrong. How do I run the same exact command at the default
> > > > one, but with -j8 instead of -j4?
> > > 
> > >  .../build-test sh -ec make -j4 distclean && ./configure && make -j4
> > > 
> > > But I think Anthony has a point.  The clean should 1. be git-clean,
> > > not make distclean 2. be run anyway.
> > 
> > I don't think we should call git-clean unconditionally -- imagine
> > someone knew for sure they only needed to build part of the tools or the
> > hypervisor.
> 
> If you are worried about this you should check that there are no
> uncommitted files before starting.

This is already done in this version.

I don't worry if there is uncommitted file, I just don't want to stop
developers from being smarter than the script when they know git-clean
is not necessary.

> 
> I have a visceral loathing of clean targets.  They are often flaky,
> and ours are no exception.
> 
> > > > > +echo "Restoring original HEAD"
> > > > > +git checkout $ORIG_BRANCH
> > > > 
> > > > Also, what a developper should do when the build fail?  She can't modify
> > > > the current code, because changes are going to be losts.  Maybe we could
> > > > trap failures, restore original HEAD and point out which commit fails to
> > > > build.
> > > 
> > > IWBNI it would at least print the branch to checkout.  Tools like "git
> > > bisect" record the information in .git and allow "git bisect reset".
> > 
> > Not sure I follow. Do you want the script to trap SIGCHLD, test the
> > return value and act accordingly?
> 
> I don't mean you should trap SIGCHLD.
> 
> But you should probably trap '' and use it to print a helpful message
> containing ORIG_BRANCH.  On success you would disable the trap before
> exiting.
> 
> Alternatively you could defuse `set -e' around the invocation of the
> build command, and handle $? explicitly.
> 

OK, that sounds easy enough.

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Wei Liu]

On Wed, Oct 25, 2017 at 04:23:35PM +0100, Anthony PERARD wrote:
> On Wed, Oct 25, 2017 at 04:17:26PM +0100, Wei Liu wrote:
> > On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
> > > > Also, what a developper should do when the build fail?  She can't modify
> > > > the current code, because changes are going to be losts.  Maybe we could
> > > > trap failures, restore original HEAD and point out which commit fails to
> > > > build.
> > > 
> > > IWBNI it would at least print the branch to checkout.  Tools like "git
> > > bisect" record the information in .git and allow "git bisect reset".
> > 
> > Not sure I follow. Do you want the script to trap SIGCHLD, test the
> > return value and act accordingly?
> 
> In scripts with `set -e`, `trap 'echo something failed' EXIT` is enough.
> But that is probably not necessary here, you could just check the return
> value of the build command, then start printing imformation about
> what/where it went wrong, and how to go back.

Either is fine. Thanks for the suggestion.

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Anthony PERARD]

On Wed, Oct 25, 2017 at 04:17:26PM +0100, Wei Liu wrote:
> On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
> > > Also, what a developper should do when the build fail?  She can't modify
> > > the current code, because changes are going to be losts.  Maybe we could
> > > trap failures, restore original HEAD and point out which commit fails to
> > > build.
> > 
> > IWBNI it would at least print the branch to checkout.  Tools like "git
> > bisect" record the information in .git and allow "git bisect reset".
> 
> Not sure I follow. Do you want the script to trap SIGCHLD, test the
> return value and act accordingly?

In scripts with `set -e`, `trap 'echo something failed' EXIT` is enough.
But that is probably not necessary here, you could just check the return
value of the build command, then start printing imformation about
what/where it went wrong, and how to go back.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2] scripts: introduce a script for build test"):
> On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
> > Anthony PERARD writes ("Re: [PATCH v2] scripts: introduce a script for 
> > build test"):
> > > That feels wrong. How do I run the same exact command at the default
> > > one, but with -j8 instead of -j4?
> > 
> >  .../build-test sh -ec make -j4 distclean && ./configure && make -j4
> > 
> > But I think Anthony has a point.  The clean should 1. be git-clean,
> > not make distclean 2. be run anyway.
> 
> I don't think we should call git-clean unconditionally -- imagine
> someone knew for sure they only needed to build part of the tools or the
> hypervisor.

If you are worried about this you should check that there are no
uncommitted files before starting.

I have a visceral loathing of clean targets.  They are often flaky,
and ours are no exception.

> > > > +echo "Restoring original HEAD"
> > > > +git checkout $ORIG_BRANCH
> > > 
> > > Also, what a developper should do when the build fail?  She can't modify
> > > the current code, because changes are going to be losts.  Maybe we could
> > > trap failures, restore original HEAD and point out which commit fails to
> > > build.
> > 
> > IWBNI it would at least print the branch to checkout.  Tools like "git
> > bisect" record the information in .git and allow "git bisect reset".
> 
> Not sure I follow. Do you want the script to trap SIGCHLD, test the
> return value and act accordingly?

I don't mean you should trap SIGCHLD.

But you should probably trap '' and use it to print a helpful message
containing ORIG_BRANCH.  On success you would disable the trap before
exiting.

Alternatively you could defuse `set -e' around the invocation of the
build command, and handle $? explicitly.

Ian.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507

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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Wei Liu]

On Tue, Oct 24, 2017 at 02:38:39PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("Re: [PATCH v2] scripts: introduce a script for build 
> test"):
> > That feels wrong. How do I run the same exact command at the default
> > one, but with -j8 instead of -j4?
> 
>  .../build-test sh -ec make -j4 distclean && ./configure && make -j4
> 
> But I think Anthony has a point.  The clean should 1. be git-clean,
> not make distclean 2. be run anyway.
> 

I don't think we should call git-clean unconditionally -- imagine
someone knew for sure they only needed to build part of the tools or the
hypervisor.

> > > +echo "Restoring original HEAD"
> > > +git checkout $ORIG_BRANCH
> > 
> > Also, what a developper should do when the build fail?  She can't modify
> > the current code, because changes are going to be losts.  Maybe we could
> > trap failures, restore original HEAD and point out which commit fails to
> > build.
> 
> IWBNI it would at least print the branch to checkout.  Tools like "git
> bisect" record the information in .git and allow "git bisect reset".

Not sure I follow. Do you want the script to trap SIGCHLD, test the
return value and act accordingly?

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

Re: [Xen-devel] [PATCH RFC 05/14] xen: vmx: Disable the 2M/1G superpage when SPP enabled

[Tamas K Lengyel]

On Wed, Oct 25, 2017 at 9:32 AM, Yi Zhang  wrote:
> On 2017-10-24 at 11:43:45 -0600, Tamas K Lengyel wrote:
>> On Fri, Oct 20, 2017 at 2:44 AM, Yi Zhang  wrote:
>> > On 2017-10-19 at 12:17:12 -0600, Tamas K Lengyel wrote:
>> >> On Thu, Oct 19, 2017 at 2:11 AM, Zhang Yi  
>> >> wrote:
>> >> > From: Zhang Yi Z 
>> >> >
>> >> > Current we only support Sub-page Protection on the 4k
>> >> > page table.
>> >> >
>> >> > Signed-off-by: Zhang Yi Z 
>> >> > ---
>> >> >  xen/arch/x86/hvm/vmx/vmx.c | 6 ++
>> >> >  1 file changed, 6 insertions(+)
>> >> >
>> >> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
>> >> > index 04ae0d6..a4c24bb 100644
>> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >> > @@ -2497,6 +2497,12 @@ const struct hvm_function_table * __init 
>> >> > start_vmx(void)
>> >> >  vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs;
>> >> >  }
>> >> >
>> >> > +if ( cpu_has_vmx_ept_spp )
>> >>
>> >> I think this really only ought to happen if the command-line option
>> >> has also been enabled.
>> >
>> > Sorry, didn't catch your point, the command line option opt_hap_2m and
>> > opt_hap_1G was enable by default, I need to  disable the supper page
>> > when spp feature enabled. Did you mean that if we enable 2M/1G by
>> > command-line we couldn't disable it here? yes, it is, I will improve
>> > this logic. Thank you Tamas.
>>
>> I meant that right now "cpu_has_vmx_ept_spp" looks like just checks
>> whether the CPU supports SPP, not whether the command-line option was
>> set to enable it. If the command line option is not set (or
>> specifically disables SPP) then the large pages shouldn't get
>> disabled.
>>
>
> In patch 02/14, if we didn't set spp_enable, we will not set the spp cap
> in vmx_secondary_exec_control, so cp_has_vmx_ept_spp flag will set when
> hardware has spp cap and xen cmdlline passed the parameter "spp_enable=1"

OK, thanks, I missed that.

>
>> >
>> >>
>> >> > +{
>> >> > +vmx_function_table.hap_capabilities &= ~HVM_HAP_SUPERPAGE_2MB;
>> >> > +vmx_function_table.hap_capabilities &= ~HVM_HAP_SUPERPAGE_1GB;
>> >> > +}
>> >> > +
>> >> >  setup_vmcs_dump();
>> >> >
>> >> >  lbr_tsx_fixup_check();
>> >> > --
>> >> > 2.7.4

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

Re: [Xen-devel] [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

[Boris Ostrovsky]

On 10/25/2017 02:45 AM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_clock().
>
> For instance, steal time of each vcpu is 335 before live migration.
>
> cpu  198 0 368 200064 1962 0 0 1340 0 0
> cpu0 38 0 81 50063 492 0 0 335 0 0
> cpu1 65 0 97 49763 634 0 0 335 0 0
> cpu2 38 0 81 50098 462 0 0 335 0 0
> cpu3 56 0 107 50138 374 0 0 335 0 0
>
> After live migration, steal time is reduced to 312.
>
> cpu  200 0 370 200330 1971 0 0 1248 0 0
> cpu0 38 0 82 50123 500 0 0 312 0 0
> cpu1 65 0 97 49832 634 0 0 312 0 0
> cpu2 39 0 82 50167 462 0 0 312 0 0
> cpu3 56 0 107 50207 374 0 0 312 0 0
>
> Since runstate times are cumulative and cleared during xen live migration
> by xen hypervisor, the idea of this patch is to accumulate runstate times
> to global percpu variables before live migration suspend. Once guest VM is
> resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
> runstate times and previously accumulated times stored in global percpu
> variables.
>
> Similar and more severe issue would impact prior linux 4.8-4.10 as
> discussed by Michael Las at
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
> which would overflow steal time and lead to 100% st usage in top command
> for linux 4.8-4.10. A backport of this patch would fix that issue.
>
> References: 
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
> Signed-off-by: Dongli Zhang 
>
> ---
> Changed since v1:
>   * relocate modification to xen_get_runstate_snapshot_cpu
>
> Changed since v2:
>   * accumulate runstate times before live migration
>
> ---
>  drivers/xen/manage.c  |  1 +
>  drivers/xen/time.c| 19 +++
>  include/xen/xen-ops.h |  1 +
>  3 files changed, 21 insertions(+)
>
> diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
> index c425d03..9aa2955 100644
> --- a/drivers/xen/manage.c
> +++ b/drivers/xen/manage.c
> @@ -72,6 +72,7 @@ static int xen_suspend(void *data)
>   }
>  
>   gnttab_suspend();
> + xen_accumulate_runstate_time();
>   xen_arch_pre_suspend();
>  
>   /*
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index ac5f23f..6df3f82 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -19,6 +19,8 @@
>  /* runstate info updated by Xen */
>  static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
>  
> +static DEFINE_PER_CPU(u64[4], old_runstate_time);
> +
>  /* return an consistent snapshot of 64-bit time/counter value */
>  static u64 get64(const u64 *p)
>  {
> @@ -52,6 +54,7 @@ static void xen_get_runstate_snapshot_cpu(struct 
> vcpu_runstate_info *res,
>  {
>   u64 state_time;
>   struct vcpu_runstate_info *state;
> + int i;
>  
>   BUG_ON(preemptible());
>  
> @@ -64,6 +67,22 @@ static void xen_get_runstate_snapshot_cpu(struct 
> vcpu_runstate_info *res,
>   rmb();  /* Hypervisor might update data. */
>   } while (get64(>state_entry_time) != state_time ||
>(state_time & XEN_RUNSTATE_UPDATE));
> +
> + for (i = 0; i < 4; i++)
> + res->time[i] += per_cpu(old_runstate_time, cpu)[i];
> +}
> +
> +void xen_accumulate_runstate_time(void)
> +{
> + struct vcpu_runstate_info state;
> + int cpu;
> +
> + for_each_possible_cpu(cpu) {
> + xen_get_runstate_snapshot_cpu(, cpu);
> + memcpy(per_cpu(old_runstate_time, cpu),
> + state.time,
> + 4 * sizeof(u64));

sizeof(old_runstate_time). (I think this should work for per_cpu variables)

> + }

Hmm.. This may not perform as intended if we are merely checkpointing
(or pausing) the guest (i.e. if HYPERVISOR_suspend() returns 1). We will
double-account for the last interval that the guest has run.

I'd rather not have yet another per-cpu variable but I can't think of
anything else. Perhaps you or others can come up with something better.

-boris

>  }
>  
>  /*
> diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
> index 218e6aa..5680059 100644
> --- a/include/xen/xen-ops.h
> +++ b/include/xen/xen-ops.h
> @@ -32,6 +32,7 @@ void xen_resume_notifier_unregister(struct notifier_block 
> *nb);
>  bool xen_vcpu_stolen(int vcpu);
>  void xen_setup_runstate_info(int cpu);
>  void xen_time_setup_guest(void);
> +void xen_accumulate_runstate_time(void);
>  void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
>  u64 xen_steal_clock(int cpu);
>  


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

[Xen-devel] [PATCH] xen/gntdev: avoid out of bounds access in case of partial gntdev_mmap()

[Juergen Gross]

In case gntdev_mmap() succeeds only partially in mapping grant pages
it will leave some vital information uninitialized needed later for
cleanup. This will lead to an out of bounds array access when unmapping
the already mapped pages.

So just initialize the data needed for unmapping the pages a little bit
earlier.

Cc: 
Reported-by: Arthur Borsboom 
Signed-off-by: Juergen Gross 
---
 drivers/xen/gntdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index 82360594fa8e..57efbd3b053b 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -1024,6 +1024,7 @@ static int gntdev_mmap(struct file *flip, struct 
vm_area_struct *vma)
mutex_unlock(>lock);
 
if (use_ptemod) {
+   map->pages_vm_start = vma->vm_start;
err = apply_to_page_range(vma->vm_mm, vma->vm_start,
  vma->vm_end - vma->vm_start,
  find_grant_ptes, map);
@@ -1061,7 +1062,6 @@ static int gntdev_mmap(struct file *flip, struct 
vm_area_struct *vma)
set_grant_ptes_as_special, NULL);
}
 #endif
-   map->pages_vm_start = vma->vm_start;
}
 
return 0;
-- 
2.12.3


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

Re: [Xen-devel] [PATCH v2] scripts: introduce a script for build test

[Wei Liu]

On Tue, Oct 24, 2017 at 12:29:32PM +0100, Anthony PERARD wrote:
> On Mon, Oct 23, 2017 at 05:56:33PM +0100, Wei Liu wrote:
> > +
> > +if test $# -lt 2 ; then
> > +echo "Usage: $0   [CMD]"
> > +exit 1
> > +fi
> [...]
> > +git rev-list $BASE..$TIP | nl -ba | tac | \
> > +while read num rev; do
> > +echo "Testing $num $rev"
> > +git checkout $rev
> > +if test $# -eq 0 ; then
> > +make -j4 distclean && ./configure && make -j4
> > +else
> > +"$@"
> 
> That feels wrong. How do I run the same exact command at the default
> one, but with -j8 instead of -j4?
> 
> I can see only two options, but I'm not sure if it is what you had in
> mind:
> - Option #1: a script
> $ echo 'make -j8 distclean && ./configure && make -j8' > tmp-script.sh
> $ ./script/build-test.sh master my-feature bash tmp-script.sh

This is what I had in mind.

> 
> - Option #2: with eval!
> $ ./script/build-test.sh master my-feature eval make -j8 distclean '&&' 
> ./configure '&&' make -j8
> # notice the eval ... here  :-)
> 
> > +fi
> > +echo
> > +done
> > +
> > +echo "Restoring original HEAD"
> > +git checkout $ORIG_BRANCH
> 
> 
> Also, what a developper should do when the build fail?  She can't modify
> the current code, because changes are going to be losts.  Maybe we could
> trap failures, restore original HEAD and point out which commit fails to
> build.
> 
> 
> Another thing that can be done is do the build test in a temporary
> checkout, but I'm not sure if it is a good idea.
> 
> (I'm still trying to find out how a script can do a better job than a
> plain `git rebase --interactive --exec 'blah'`, it is maybe just because
> I know what to do if there is an issue.)
> 

Frankly I myself would probably use git-rebase so that I can fix things
on the fly, but I want to point contributors to something safer. And I'm
tired of typing the same "ICYMI git-rebase can do this this this to
build test your branch".

> -- 
> Anthony PERARD

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

Re: [Xen-devel] [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to not pass a structure by value

[Ian Jackson]

I have reordered the quoted text, and my replies, so as to address the
most technical points first and leave what might be described as
process arguments and tone complaints for later.


Andrew Cooper writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix 
precopy_policy() to not pass a structure by value"):
> someone who does understand why hiding a prologue memcpy() is bad for
> performance.

To address your actual technical point about the memcpy.

Not all functions in the toolstack are performance critical and not
all putative tiny performance benefits are worthwhile.  Most are not.
Code should generally be written to be as clear and simple as
possible, and clarity and simplicity should be traded off for
performance only when this will produce a noticeable difference.

Obviously clarity is a matter of opinion, but I would generally say
that a struct containing plain data is simpler than a pointer to a
similar struct.  And of course passing as a pointer requires (or, in
this case, will eventually require) additional complexity in the
message generator script.

Against that, in this case, the cost of the additional alleged-memcpy
seems to me, at first glance, to be completely irrelevant.

Of course it probably isn't going to be a memcpy; the struct contents
will probably be passed in registers (I haven't double-checked ABI
manuals so this may be wrong on some register-poor architectures).
Given the small size of this struct, it might well be slightly faster
to pass it in a pair of registers rather than a pointer to memory, for
locality of reference reasons.

But ISTM that all of this is going to be swamped by the other costs of
making a function call (at least where the callback is provided -
where it isn't provided, it doesn't matter).  And for in-tree
consumers, the cost of the copy-by-value is going to be dwarfed by the
IPC costs (as indeed you notice).

If you have a better argument than "passing a struct by value should
be avoided in all cases for performance reasons" you need to make it.


> Having an IPC call in the middle of the live loop it is bad, and will
> increase the downtime of the VM. However, the IPC call is optional
> which means the common case doesn't need to suffer the overhead.
> Passing by value even in the common case is an entirely unnecessary
> overhead, and this fact alone is justification enough to not do it.

At last, we're starting to get towards a technical argument here.

I think the most significant proportional performance impact would be
the case where there is a callback but only within the migration
process.  Ie, an out-of-tree provider of the precopy_policy hook.
(If there is no callback provided, there is no cost; and an in-tree
consumer will have the IPC cost which will dominate.)

Would you care to hazard a guess at the quantifiable peformance loss
from passing this by value, in that case ?  Perhaps you would like to
exhibit some assembly snippets, or show a benchmark result.



> However, what is really irritating me is that, not only am I having to
> divert time from more important tasks to try and fix this code before we
> ship a release with it in, but that I'm having to fight you for the
> privilege of maintaining that the migration code doesn't regress back
> into the cesspit that was the legacy code.

Since we are still talking about a libxc interface, there is no
concern from an ABI/API stability point of view.  If we decide, later,
that the pointer is better (whether because we have changed our mind,
or because of changed circumstances such as the struct growing
significantly) we can just change it.  Of course it's better to get it
right first time so if there is a good reason.


> On 19/10/17 16:17, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix 
> > precopy_policy() to not pass a structure by value"):
> >> On 16/10/17 16:07, Ian Jackson wrote:
> >>> This statement is true only if you think "the precopy callback" refers
> >>> to the stub generated by libxl_save_msgs_gen.
> >> The commit is about save_callbacks.precopy_policy() specifically (and
> >> IMO, obviously).
> >> Given this, the statement is true.
> > I don't agree.
> 
> Don't agree with what?  The justification for why passing-by-value is
> supposedly necessary is bogus irrespective of whether you consider just
> the libxc part of the callback, or the end-to-end path into libxl.
>
> No argument concerning address space (separate or otherwise) is a
> related to how parameter passing needs to happen at this level.
> 
> FAOD, the actual reason why it was done that way was because no-one
> wanted to edit libxl_save_msgs_gen.pl to be able to cope with pointers,
> but "$WE don't want to do it properly" is not a reasonable justification.

This argument depends on a view of "properly" which I don't share.
Ie your argument seems circular to me.

However, I hope it is not necessary to resolve our disagreement over
whether your proposed the commit message wording is 

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Mark Rutland]

On Wed, Oct 25, 2017 at 04:21:48PM +0200, Jiri Slaby wrote:
> Hi,
> 
> On 10/06/2017, 03:21 PM, Mark Rutland wrote:
> > If the aim of this series is to introduce something that architectures
> > use consistently, then can we please actually poke other architectures
> > about it? e.g. send this to linux-arch, with a cover letter explaining
> > the idea and asking maintainers to take a look.
> 
> Sure, with v5, I will.

Thanks; that's much appreciated, and I look forward to it!

Mark.

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

Re: [Xen-devel] [PATCH v6 13/13] xen: introduce a Kconfig option to enable the pvcalls frontend

[Boris Ostrovsky]

On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> Also add pvcalls-front to the Makefile.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/Kconfig  | 9 +
>  drivers/xen/Makefile | 1 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
> index 4545561..0b2c828 100644
> --- a/drivers/xen/Kconfig
> +++ b/drivers/xen/Kconfig
> @@ -196,6 +196,15 @@ config XEN_PCIDEV_BACKEND
>  
> If in doubt, say m.
>  
> +config XEN_PVCALLS_FRONTEND
> + tristate "XEN PV Calls frontend driver"
> + depends on INET && XEN
> + help
> +   Experimental frontend for the Xen PV Calls protocol
> +   (https://xenbits.xen.org/docs/unstable/misc/pvcalls.html). It
> +   sends a small set of POSIX calls to the backend, which
> +   implements them.

default n ?

(and maybe select XEN_XENBUS_FRONTEND)

-boris

> +
>  config XEN_PVCALLS_BACKEND
>   bool "XEN PV Calls backend driver"
>   depends on INET && XEN && XEN_BACKEND
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 480b928..afb9e03 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_XEN_EFI)   += efi.o
>  obj-$(CONFIG_XEN_SCSI_BACKEND)   += xen-scsiback.o
>  obj-$(CONFIG_XEN_AUTO_XLATE) += xlate_mmu.o
>  obj-$(CONFIG_XEN_PVCALLS_BACKEND)+= pvcalls-back.o
> +obj-$(CONFIG_XEN_PVCALLS_FRONTEND)   += pvcalls-front.o
>  xen-evtchn-y := evtchn.o
>  xen-gntdev-y := gntdev.o
>  xen-gntalloc-y   := gntalloc.o


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

Re: [Xen-devel] [PATCH v4 4/5] xentrace: enable per-VCPU extratime flag for RTDS

[Wei Liu]

On Mon, Oct 23, 2017 at 02:50:31PM -0400, Meng Xu wrote:
> On Tue, Oct 17, 2017 at 4:10 AM, Dario Faggioli  wrote:
> > On Wed, 2017-10-11 at 14:02 -0400, Meng Xu wrote:
> >> Change repl_budget event output for xentrace formats and xenalyze
> >>
> >> Signed-off-by: Meng Xu 
> >>
> > I'd say:
> >
> > Reviewed-by: Dario Faggioli 
> 
> Hi guys,
> 
> Just a reminder, we may need this patch for the work-conserving RTDS
> scheduler in Xen 4.10.
> 
> I say Julien sent out the rc2 today which does not include this patch.
> 
> Thanks and best regards,
> 

I'm waiting for George's ack.

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

Re: [Xen-devel] [PATCH v6 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> Send PVCALLS_RELEASE to the backend and wait for a reply. Take both
> in_mutex and out_mutex to avoid concurrent accesses. Then, free the
> socket.
>
> For passive sockets, check whether we have already pre-allocated an
> active socket for the purpose of being accepted. If so, free that as
> well.
>
> Signed-off-by: Stefano Stabellini 
> CC: boris.ostrov...@oracle.com
> CC: jgr...@suse.com
> ---
>  drivers/xen/pvcalls-front.c | 100 
> 
>  drivers/xen/pvcalls-front.h |   1 +
>  2 files changed, 101 insertions(+)
>
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 4a413ff..7abc039 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -199,6 +199,23 @@ static irqreturn_t pvcalls_front_event_handler(int irq, 
> void *dev_id)
>  static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
>  struct sock_mapping *map, bool locked)
>  {
> + int i;
> +
> + unbind_from_irqhandler(map->active.irq, map);
> +
> + if (!locked)
> + spin_lock(>socket_lock);
> + if (!list_empty(>list))
> + list_del_init(>list);
> + if (!locked)
> + spin_unlock(>socket_lock);
> +
> + for (i = 0; i < (1 << PVCALLS_RING_ORDER); i++)
> + gnttab_end_foreign_access(map->active.ring->ref[i], 0, 0);
> + gnttab_end_foreign_access(map->active.ref, 0, 0);
> + free_page((unsigned long)map->active.ring);
> +
> + kfree(map);
>  }
>  
>  static irqreturn_t pvcalls_front_conn_handler(int irq, void *sock_map)
> @@ -966,6 +983,89 @@ unsigned int pvcalls_front_poll(struct file *file, 
> struct socket *sock,
>   return ret;
>  }
>  
> +int pvcalls_front_release(struct socket *sock)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> + int req_id, notify, ret;
> + struct xen_pvcalls_request *req;
> +

..

> +
> + if (map->active_socket) {
> + /*
> +  * Set in_error and wake up inflight_conn_req to force
> +  * recvmsg waiters to exit.
> +  */
> + map->active.ring->in_error = -EBADF;
> + wake_up_interruptible(>active.inflight_conn_req);
> +
> + /*
> +  * Wait until there are no more waiters on the mutexes.
> +  * We know that no new waiters can be added because sk_send_head
> +  * is set to NULL -- we only need to wait for the existing
> +  * waiters to return.
> +  */
> + while (!mutex_trylock(>active.in_mutex) ||
> +!mutex_trylock(>active.out_mutex))
> + cpu_relax();
> +
> + pvcalls_front_free_map(bedata, map, false);
> + } else {
> + spin_lock(>socket_lock);
> + if (READ_ONCE(map->passive.inflight_req_id) !=
> + PVCALLS_INVALID_ID) {
> + pvcalls_front_free_map(bedata,
> +map->passive.accept_map, true);
> + }
> + list_del(>list);
> + kfree(map);
> + spin_unlock(>socket_lock);

We have different locking rules in pvcalls_front_free_map() for each of
those clauses in that in the first case we are doing grant table
operations and free_page() without the lock and in the second case we
are holding it. Is it possible to restructure this so that we prune the
lists under the lock (possibly in this routine) and call
pvcalls_front_free_map() lock-less?

-boris


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

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

Hi,

On 10/06/2017, 03:21 PM, Mark Rutland wrote:
> If the aim of this series is to introduce something that architectures
> use consistently, then can we please actually poke other architectures
> about it? e.g. send this to linux-arch, with a cover letter explaining
> the idea and asking maintainers to take a look.

Sure, with v5, I will.

thanks,
-- 
js
suse labs

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

Re: [Xen-devel] [PATCH v4 01/27] linkage: new macros for assembler symbols

[Jiri Slaby]

On 10/06/2017, 05:23 PM, Josh Poimboeuf wrote:
> On Mon, Oct 02, 2017 at 11:12:20AM +0200, Jiri Slaby wrote:
>>SYM_CODE_INNER_LABEL -- only for labels in the middle of code
>>SYM_CODE_INNER_LABEL_NOALIGN -- only for labels in the middle of code
> 
> Why are the inner labels aligned by default?  Seems like unaligned would
> be the most common case.

Correct:
$ git grep -w SYM_CODE_INNER_LABEL_NOALIGN arch/|wc -l
20
$ git grep -w SYM_CODE_INNER_LABEL arch/|wc -l
3

Will switch them.

>> d) For data
>>SYM_DATA_START -- global data symbol
>>SYM_DATA_END -- the end of the SYM_DATA_START symbol
>>SYM_DATA_END_LABEL -- the labeled end of SYM_DATA_START symbol
>>SYM_DATA_SIMPLE -- start+end wrapper around simple global data
>>SYM_DATA_SIMPLE_LOCAL -- start+end wrapper around simple local data
> 
> "SIMPLE" seems superfluous, how about s/SYM_DATA_SIMPLE/SYM_DATA/ ?

Yup, makes sense, will do.

thanks,
-- 
js
suse labs

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

Re: [Xen-devel] [PATCH v4 19/27] x86: assembly, make some functions local

[Jiri Slaby]

On 10/06/2017, 04:01 PM, Ard Biesheuvel wrote:
> On 6 October 2017 at 13:53, Jiri Slaby  wrote:
>> On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote:
>>> In arm64, we use ENTRY/ENDPROC for functions with external linkage,
>>> and the bare symbol name/ENDPROC for functions with local linkage. I
>>> guess we could add ENDOBJECT if we wanted to, but we never really felt
>>> the need.
>>
>> Yes and this is exactly the reason for the new macros. Now, it's a
>> complete mess. One arch does this, another does that. And we are in a
>> state to have reliable stacktraces, let objtool check functions, let
>> objtool generate annotations (e.g. for ORC unwinder), etc.
>>
> 
> You are implying that ENTRY/ENDPROC and 'bare symbol name'/ENDPROC
> prevent you from doing any of this, but this is simply not true.

If I understand correctly, you have not read the discussion behind the
link I sent you... So in sum:
Initially, I only used the current ENTRY/ENDPROC approach and augmented
it to fix up the mess in x86. But it was concluded that these old macros
are terrible and we rather want to avoid them. It was especially the bad
naming of these old macros. So we discussed what the new naming scheme
could be and this is what we ended up with.

>> Without knowing what is start, where is its end, what is function, what
>> is object (data) etc., it can barely check or even generate anything
>> automatically. Not speaking about impaired macros like your name/ENDPROC
>> above.
>>
> 
> What is the problem with impaired macros?

Obviously that they are impaired. That is the tools do not know where to
stop with reading of code or data.

This is quite usual:

foo:
  mov data,a
  call bar
  ret

data: .string "hello"

This makes the tools to choke on the data while thinking it is still code.

> So what is preventing people from using these new macros in the wrong way?

The tools. It is quite easy to check this during build by a linker and I
have such a patch here. It was not yet concluded (I think) whether we
are going to check this via objtool or by something like my patch.
Noteworthy, objtool can check much more in this respect, obviously.

thanks,
-- 
js
suse labs

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

Re: [Xen-devel] [BUG] xen_gntdev - gntdev_vma_find_special_page - unable to handle kernel paging request

[Juergen Gross]

On 25/10/17 13:17, Arthur Borsboom wrote:
> Since about a month, possibly due to software updates, after a couple of
> days running several VMs, one of the VM guests crashes and the VM host
> is not stable anymore. I need to shutdown all the remaining VM guests
> (if possible) and reboot the server by hardware (sudo reboot hangs).
> 
> Does anybody have a suggestion how to analyze/resolve this?

Hmm, it seems as if gntdev_mmap() is mapping only some pages and then
exits with an error. This will leave map->pages_vm_start as 0 leading
to a problem when the already mapped pages are being unmapped again.

Patch will come soon...

Can I add you as "Reported-by:" ?


Juergen

> All help is appreciated!
> 
> Xen: 4.9.0
> OS (Dom0): Arch Linux 4.13.7
> Dmesg:
> 
> [131395.101610] BUG: unable to handle kernel paging request at
> 88401920c018
> [131395.101715] IP: gntdev_vma_find_special_page+0x1d/0x30 [xen_gntdev]
> [131395.101796] PGD 1a0a067 
> [131395.101797] P4D 1a0a067 
> [131395.101832] PUD 0 
> [131395.101922] Oops:  [#1] PREEMPT SMP
> [131395.101975] Modules linked in: xt_nat xt_physdev br_netfilter
> xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> iptable_nat nf_nat_ipv4 nf_nat tun bridge stp llc ebtable_filter
> ebtables devlink ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_conntrack_ipv4
> nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c crc32c_generic
> ip6table_filter iptable_filter ip6_tables snd_hda_codec_realtek amdkfd
> snd_hda_codec_generic snd_hda_codec_hdmi amd_iommu_v2 snd_hda_intel
> radeon joydev snd_hda_codec mousedev evdev input_leds led_class mac_hid
> ppdev wmi_bmof snd_hda_core i2c_algo_bit ttm snd_hwdep snd_pcm
> edac_mce_amd drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel
> ghash_clmulni_intel snd_timer pcbc r8169 aesni_intel psmouse aes_x86_64
> crypto_simd glue_helper tpm_infineon drm cryptd tpm_tis snd pcspkr
> [131395.102862]  agpgart sp5100_tco tpm_tis_core mii syscopyarea
> sysfillrect tpm i2c_piix4 sysimgblt soundcore parport_pc parport
> fb_sys_fops fam15h_power k10temp wmi shpchp button sch_fq_codel
> xen_acpi_processor xen_pciback xen_netback xen_blkback xenfs
> xen_gntalloc xen_gntdev xen_evtchn xen_privcmd ip_tables x_tables ext4
> crc16 mbcache jbd2 fscrypto hid_generic usbhid hid sd_mod ata_generic
> pata_acpi ohci_pci pata_atiixp serio_raw atkbd libps2 ahci ehci_pci
> libahci ehci_hcd ohci_hcd libata usbcore scsi_mod usb_common i8042 serio
> [131395.103469] CPU: 0 PID: 10887 Comm: qemu-dm Not tainted 4.13.7-1-ARCH #1
> [131395.103554] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD
> MS-7596/760GM-E51(MS-7596), BIOS V3.6 10/26/2012
> [131395.103677] task: 8800483b1e00 task.stack: c90046598000
> [131395.103759] RIP: e030:gntdev_vma_find_special_page+0x1d/0x30
> [xen_gntdev]
> [131395.103852] RSP: e02b:c9004659bb60 EFLAGS: 00010212
> [131395.103927] RAX: 88001ef0a360 RBX: 8800119a0cb8 RCX:
> 00624684
> [131395.104018] RDX: 800624684367 RSI: 0007ff460397 RDI:
> 88003dd7b240
> [131395.104108] RBP: c9004659bb70 R08: 88003dd7b240 R09:
> 7ff4603a2000
> [131395.104198] R10: 0001 R11: 3000 R12:
> 7ff460397000
> [131395.104288] R13: 800624684367 R14: 7ff460398000 R15:
> c9004659bce0
> [131395.104390] FS:  7ff4605667c0() GS:88005500()
> knlGS:
> [131395.104490] CS:  e033 DS:  ES:  CR0: 80050033
> [131395.104564] CR2: 88401920c018 CR3: 1cb0f000 CR4:
> 00040660
> [131395.104655] Call Trace:
> [131395.104695]  ? vm_normal_page+0x5d/0xa0
> [131395.104748]  unmap_page_range+0x4e3/0x930
> [131395.104804]  unmap_single_vma+0x7d/0xf0
> [131395.104857]  unmap_vmas+0x51/0xb0
> [131395.104904]  unmap_region+0xbd/0x130
> [131395.104953]  ? gnttab_map_refs+0xc4/0x160
> [131395.105009]  ? gntdev_mmap+0x3a4/0x610 [xen_gntdev]
> [131395.105074]  mmap_region+0x461/0x5f0
> [131395.105122]  do_mmap+0x2b3/0x400
> [131395.105167]  vm_mmap_pgoff+0xcc/0x120
> [131395.105217]  SyS_mmap_pgoff+0x1bc/0x230
> [131395.105271]  SyS_mmap+0x1b/0x30
> [131395.108716]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> [131395.112161] RIP: 0033:0x7ff45dcc3e63
> [131395.115644] RSP: 002b:7ffdf0c57648 EFLAGS: 0246 ORIG_RAX:
> 0009
> [131395.119149] RAX: ffda RBX: a000 RCX:
> 7ff45dcc3e63
> [131395.122587] RDX: 0002 RSI: b000 RDI:
> 
> [131395.126005] RBP: 1000 R08: 002a R09:
> c000
> [131395.129509] R10: 0001 R11: 0246 R12:
> 0001
> [131395.132989] R13: 560471ae8e00 R14: 560471a66290 R15:
> 
> [131395.136568] Code: 5b 5d c3 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44
> 00 00 48 8b 87 a8 00 00 00 55 48 89 e5 48 2b 70 68 48 8b 40 60 5d 48 c1
> ee 0c <48> 8b 04 f0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 
> [131395.143798] RIP: 

Re: [Xen-devel] [Qemu-devel] [PATCH] pci-assign: Remove

[Philippe Mathieu-Daudé]

> On Fri, Oct 20, 2017 at 10:25:38AM +0200, Paolo Bonzini wrote:
>> Legacy PCI device assignment has been removed from Linux in 4.12,
>> and had been deprecated 2 years ago there.  We can remove it from
>> QEMU as well.
>>
>> The ROM loading code was shared with Xen PCI passthrough, so move
>> it to hw/xen.
>>
>> Cc: Stefano Stabellini 
>> Cc: Anthony Perard 
>> Cc: xen-de...@lists.xenproject.org
>> Signed-off-by: Paolo Bonzini 
>> ---
>> Xen parts only compile-tested.
>>
>>  docs/qdev-device-use.txt   |   12 +-
>>  hw/i386/Makefile.objs  |1 -
>>  hw/i386/kvm/Makefile.objs  |2 +-
>>  hw/i386/kvm/pci-assign.c   | 1883 
>> 

nice cleanup <3

>>  hw/xen/Makefile.objs   |1 +
>>  .../xen_pt_load_rom.c} |4 +-
>>  include/hw/pci/pci-assign.h|   27 -
>>  qdev-monitor.c |1 -
>>  scripts/device-crash-test  |2 -
>>  9 files changed, 6 insertions(+), 1927 deletions(-)
>>  delete mode 100644 hw/i386/kvm/pci-assign.c
>>  rename hw/{i386/pci-assign-load-rom.c => xen/xen_pt_load_rom.c} (96%)
>>  delete mode 100644 include/hw/pci/pci-assign.h
>>
>> diff --git a/hw/i386/pci-assign-load-rom.c b/hw/xen/xen_pt_load_rom.c
>> similarity index 96%
>> rename from hw/i386/pci-assign-load-rom.c
>> rename to hw/xen/xen_pt_load_rom.c
>> index 43429b66be..2bc3b6c092 100644
>> --- a/hw/i386/pci-assign-load-rom.c
>> +++ b/hw/xen/xen_pt_load_rom.c
>> @@ -12,7 +12,7 @@
>>  #include "qemu/range.h"
>>  #include "sysemu/sysemu.h"
>>  #include "hw/pci/pci.h"
>> -#include "hw/pci/pci-assign.h"
>> +#include "xen_pt.h"
>>  
>>  /*
>>   * Scan the assigned devices for the devices that have an option ROM, and 
>> then
>> @@ -80,7 +80,7 @@ close_rom:
>>  fseek(fp, 0, SEEK_SET);
>>  val = 0;
>>  if (!fwrite(, 1, 1, fp)) {
>> -DEBUG("%s\n", "Failed to disable pci-sysfs rom file");
>> +XEN_PT_WARN("%s\n", "Failed to disable pci-sysfs rom file");
> 
> XEN_PT_WARN takes an extra argument, it should read:
> XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");
> 
> With that fixed:
> Acked-by: Anthony PERARD 

Reviewed-by: Philippe Mathieu-Daudé 


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

Re: [Xen-devel] [PATCH] x86/boot: fix MB2 header to require EFI BS

[Doug Goldstein]

On 10/24/17 5:20 PM, Daniel Kiper wrote:
> On Tue, Oct 24, 2017 at 10:40:26PM +0100, Andrew Cooper wrote:
>> On 24/10/2017 22:11, Daniel Kiper wrote:
>>> On Tue, Oct 24, 2017 at 09:22:20PM +0100, Andrew Cooper wrote:
 On 24/10/17 21:08, Daniel Kiper wrote:
> On Tue, Oct 24, 2017 at 02:40:41PM -0500, Doug Goldstein wrote:
>> The EFI multiboot2 entry point currently requires EFI BootServices to
>> not have been exited however the header currently tells the boot
>> loader that Xen optionally supports EFI BootServices having been exited.
>> With this change Xen properly advertises that EFI must not be exited
>> allowing the boot loader to report an error that it cannot boot Xen if
>> it is unable to meet its needs.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>>
>> This should likely be applied against Xen 4.9 and Xen 4.10 as well as
>> staging. I am trying to get multiboot2 support for iPXE and upstream
>> is concerned that leaving EFI BootServices enabled will not be
>> compatible with their aims to support Secure Boot. So when I build
> Hmmm... What are exact arguments for that? How do they implement e.g.
> chain loading then? What about the shim support?
>
>> my iPXE without support for passing on Boot Services, Xen will be
>> loaded by iPXE but then it will fall down with "ERR: Bootloader
>> shutdown EFI x64 boot services!" implying that this is required. By
>> having Xen expose in its header that its required it allows me to
>> handle the situation gracefully in iPXE.
>>
>> To quote the multiboot2 spec exact:
>>
>> "This tag indicates that payload supports starting without terminating
>> boot services."
>>
>> Unfortunately the spec is a bit vague and how I am reading it is:
>> - no tag = exit boot services in the boot loader
>> - tag present marked optional = boot loader can or cannot exit boot 
>> services
>> - tag present marked required = boot loader cannot exit boot services
> NACK, please take a look at section 3.1.4, Multiboot2 information request
> in Multiboot2 spec. OPTIONAL/REQUIRED has different meaning for the 
> bootloader
> than you think.
 The meaning of tag, if understood by Grub, is "don't exit boot services
 before passing control".
>>> Yep.
>>>
 The tag is currently marked as optional, which means Grub is free to
 ignore it if it doesn't understand it, resulting in EBS being called
 before passing control.
>>> Yep, but you are forgetting about legacy BIOS platforms with old GRUB2.
>>> Right now it is possible to boot Xen via Multiboot2 in such configs.
>>> If you set this flag to REQUIRED then old GRUB2 on BIOS platforms will
>>> not boot Xen in such cases. If we do not care about that then OK. However,
>>> then I would request additional line or so to the commit message saying
>>> that such configs are broken deliberately because...
>>
>> Such older cases wouldn't boot either, because Xen would bail out saying
>> "I didn't retain BS like I need".
> 
> Nope, you should remember that legacy entry point (__start) will be used then.

But based on what you said the spec says the boot loader only has to
understand the tag and not actually do anything with it. So marking it
required wouldn't affect anything cause Grub would understand the tag in
the BIOS boot case and not do anything with it.


-- 
Doug Goldstein

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

Re: [Xen-devel] [PATCH v6 02/13] xen/pvcalls: implement frontend disconnect

[Boris Ostrovsky]

On 10/24/2017 01:33 PM, Stefano Stabellini wrote:
> +static void pvcalls_front_free_map(struct pvcalls_bedata *bedata,
> +struct sock_mapping *map, bool locked)
> +{
> +}
> +
>  static const struct xenbus_device_id pvcalls_front_ids[] = {
>   { "pvcalls" },
>   { "" }
> @@ -27,6 +66,32 @@
>  
>  static int pvcalls_front_remove(struct xenbus_device *dev)
>  {
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map = NULL, *n;

Your last comment made me look again at sock_mapping definition. And
then I noticed that it is not defined until patch 4 ;-(

-boris

> +
> + bedata = dev_get_drvdata(_front_dev->dev);
> + dev_set_drvdata(>dev, NULL);
> + pvcalls_front_dev = NULL;
> + if (bedata->irq >= 0)
> + unbind_from_irqhandler(bedata->irq, dev);
> +
> + smp_mb();
> + while (atomic_read(_refcount) > 0)
> + cpu_relax();
> + list_for_each_entry_safe(map, n, >socket_mappings, list) {
> + if (map->active_socket) {
> + /* No need to lock, refcount is 0 */
> + pvcalls_front_free_map(bedata, map, true);
> + } else {
> + list_del(>list);
> + kfree(map);
> + }
> + }
> + if (bedata->ref >= 0)
> + gnttab_end_foreign_access(bedata->ref, 0, 0);
> + kfree(bedata->ring.sring);
> + kfree(bedata);
> + xenbus_switch_state(dev, XenbusStateClosed);
>   return 0;
>  }
>  


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

Re: [Xen-devel] [OSSTEST PATCH 00/16] Upgrade to Stretch

[Wei Liu]

On Fri, Oct 20, 2017 at 11:38:24AM +0100, Wei Liu wrote:
> 3. The unstability with Arndale boards' nic is more prominent. Or worse -- 
> they
>have become completely unusable. I don't have enough data yet. We might
>need to work around this, but I'm not sure how to do that yet.

It appears arndale board network dongles are completely unusable with
stretch. Luckily it is not the first time we have this sort of problem.
There is already facility in osstest to force assigning a mac address.
I'm testing a patch now.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
baseline version:
 xen  be7f60b5a39741eab0a8fea0324f7be0cb724cfb

Last test of basis   115192  2017-10-24 17:03:14 Z0 days
Testing same since   115217  2017-10-25 12:05:00 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 xen-unstable-smoke 
03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
+ branch=xen-unstable-smoke
+ revision=03dd1e2a5414faf86f743ae96c2b63dbc81f27f6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x03dd1e2a5414faf86f743ae96c2b63dbc81f27f6 = 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
++ : 

[Xen-devel] [xen-4.5-testing test] 115191: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 
114423
 test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-localmigrate/x10 fail REGR. vs. 
114423
 test-armhf-armhf-xl-vhd  10 debian-di-installfail REGR. vs. 114423

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 114423
 test-amd64-amd64-xl-rtds  7 xen-boot fail  like 114423
 test-xtf-amd64-amd64-2   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-3   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-4   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-5   60 leak-check/check fail  like 114423
 test-xtf-amd64-amd64-1   60 leak-check/check fail  like 114423
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114423
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 114423
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114423
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114423
 test-xtf-amd64-amd64-2   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   19 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 34 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 41 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1   45 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-3   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-5   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   59 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 11 guest-start  fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Andrew Cooper]

On 25/10/17 11:59, George Dunlap wrote:
>>> +Limit, x86 HVM: 128
>>> +Limit, ARM32: 8
>>> +Limit, ARM64: 128
>>> +
>>> +[XXX Andrew Cooper: Do want to add "Limit-Security" here for some of 
>>> these?]
>> 32 for each.  64 vcpu HVM guests can excerpt enough p2m lock pressure to
>> trigger a 5 second host watchdog timeout.
> Is that "32 for x86 PV and x86 HVM", or "32 for x86 HVM and ARM64"?  Or
> something else?
 The former.  I'm not qualified to comment on any of the ARM limits.

 There are several non-trivial for_each_vcpu() loops in the domain_kill
 path which aren't handled by continuations.  ISTR 128 vcpus is enough to
 trip a watchdog timeout when freeing pagetables.
>>> I don't think 32 is a really practical limit.
>> What do you mean by practical here, and what evidence are you basing
>> this on?
>>
>> Amongst other things, there is an ABI boundary in Xen at 32 vcpus, and
>> given how often it is broken in Linux, its clear that there isn't
>> regular testing happening beyond this limit.
> Is that true for dom0 as well?

Yes.  The problem is:

struct shared_info {
    struct vcpu_info vcpu_info[XEN_LEGACY_MAX_VCPUS];
...

and while there are ways to make a larger number of vcpus work, it
requires additional hypercalls to make alternate arrangements for the
vcpus beyond the 32 boundary, and these arrangements appear to be broken
more often than not around suspend/resume.

>
>>> I'm inclined to say that if a rogue guest can crash a host with 33 vcpus, 
>>> we should issue an XSA
>>> and fix it.
>> The reason XenServer limits at 32 vcpus is that I can crash Xen with a
>> 64 vcpu HVM domain.  The reason it hasn't been my top priority to fix
>> this is because there is very little customer interest in pushing this
>> limit higher.
>>
>> Obviously, we should fix issues as and when they are discovered, and
>> work towards increasing the limits in the longterm, but saying "this
>> limit seems too low, so lets provisionally set it higher" is short
>> sighted and a recipe for more XSAs.
> OK -- I'll set this to 32 for now and see if anyone else wants to
> argue for a different value.

Sounds good to me.

>
>>> +
>>> +### x86 PV/Event Channels
>>> +
>>> +Limit: 131072
>> Why do we call out event channel limits but not grant table limits?
>> Also, why is this x86?  The 2l and fifo ABIs are arch agnostic, as far
>> as I am aware.
> Sure, but I'm pretty sure that ARM guests don't (perhaps cannot?) use PV
> event channels.
 This is mixing the hypervisor API/ABI capabilities with the actual
 abilities of guests (which is also different to what Linux would use in
 the guests).
>>> I'd say rather that you are mixing up the technical abilities of a
>>> system with user-facing features.  :-)  At the moment there is no reason
>>> for any ARM user to even think about event channels, so there's no
>>> reason to bother them with the technical details.  If at some point that
>>> changes, we can modify the document.
>> You do realise that receiving an event is entirely asymmetric with
>> sending an event?
>>
>> Even on ARM, {net,blk}front needs to speak event_{2l,fifo} with Xen to
>> bind and use its interdomain event channel(s) with {net,blk}back.
> I guess I didn't realize that (and just noticed Stefano's comment
> saying ARM uses event channels).
>
 ARM guests, as well as x86 HVM with APICV (configured properly) will
 actively want to avoid the guest event channel interface, because its
 slower.

 This solitary evtchn limit serves no useful purpose IMO.
>>> There may be a point to what you're saying: The event channel limit
>>> normally manifests itself as a limit on the number of guests / total
>>> devices.
>>>
>>> On the other hand, having these kinds of limits around does make sense.
>>>
>>> Let me give it some thoughts.  (If anyone else has any opinions...)
>> The event_fifo limit is per-domain, not system-wide.
>>
>> In general this only matters for a monolithic dom0, as it is one end of
>> each event channel in the system.
> Sure -- and that's why the limit used to matter.  It doesn't seem to
> matter at the moment because you now hit other resource bottlenecks
> before you hit the event channel limit.

This point highlights why conjoining the information is misleading.

A dom0 which (for whatever reason) chooses to use event_2l will still
hit the event channel bottlekneck before other resource bottleknecks.

I'd expect the information to look a little more like this (formatting
subject to improvement)

## Event channels

### Event Channel 2-level ABI
Limit-theoretical (per guest): 1024 (32bit guest), 4096 (64bit guest)
Supported

### Event Channel FIFO ABI
Limit-theoretical (per guest): 131072
Supported

(We may want a shorthand for "this is the theoretical limit, and we
support it all the way up to the limit").

>
>  * Guest serial console
 Which consoles?  A qemu 

[Xen-devel] [BUG] xen_gntdev - gntdev_vma_find_special_page - unable to handle kernel paging request

[Arthur Borsboom]

Since about a month, possibly due to software updates, after a couple of
days running several VMs, one of the VM guests crashes and the VM host is
not stable anymore. I need to shutdown all the remaining VM guests (if
possible) and reboot the server by hardware (sudo reboot hangs).

Does anybody have a suggestion how to analyze/resolve this?
All help is appreciated!

Xen: 4.9.0
OS (Dom0): Arch Linux 4.13.7
Dmesg:

[131395.101610] BUG: unable to handle kernel paging request at
88401920c018
[131395.101715] IP: gntdev_vma_find_special_page+0x1d/0x30 [xen_gntdev]
[131395.101796] PGD 1a0a067
[131395.101797] P4D 1a0a067
[131395.101832] PUD 0
[131395.101922] Oops:  [#1] PREEMPT SMP
[131395.101975] Modules linked in: xt_nat xt_physdev br_netfilter
xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_nat_ipv4 nf_nat tun bridge stp llc ebtable_filter ebtables
devlink ipt_REJECT nf_reject_ipv4 xt_tcpudp nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c crc32c_generic
ip6table_filter iptable_filter ip6_tables snd_hda_codec_realtek amdkfd
snd_hda_codec_generic snd_hda_codec_hdmi amd_iommu_v2 snd_hda_intel radeon
joydev snd_hda_codec mousedev evdev input_leds led_class mac_hid ppdev
wmi_bmof snd_hda_core i2c_algo_bit ttm snd_hwdep snd_pcm edac_mce_amd
drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel snd_timer pcbc r8169 aesni_intel psmouse aes_x86_64
crypto_simd glue_helper tpm_infineon drm cryptd tpm_tis snd pcspkr
[131395.102862]  agpgart sp5100_tco tpm_tis_core mii syscopyarea
sysfillrect tpm i2c_piix4 sysimgblt soundcore parport_pc parport
fb_sys_fops fam15h_power k10temp wmi shpchp button sch_fq_codel
xen_acpi_processor xen_pciback xen_netback xen_blkback xenfs xen_gntalloc
xen_gntdev xen_evtchn xen_privcmd ip_tables x_tables ext4 crc16 mbcache
jbd2 fscrypto hid_generic usbhid hid sd_mod ata_generic pata_acpi ohci_pci
pata_atiixp serio_raw atkbd libps2 ahci ehci_pci libahci ehci_hcd ohci_hcd
libata usbcore scsi_mod usb_common i8042 serio
[131395.103469] CPU: 0 PID: 10887 Comm: qemu-dm Not tainted 4.13.7-1-ARCH #1
[131395.103554] Hardware name: MICRO-STAR INTERNATIONAL CO.,LTD
MS-7596/760GM-E51(MS-7596), BIOS V3.6 10/26/2012
[131395.103677] task: 8800483b1e00 task.stack: c90046598000
[131395.103759] RIP: e030:gntdev_vma_find_special_page+0x1d/0x30
[xen_gntdev]
[131395.103852] RSP: e02b:c9004659bb60 EFLAGS: 00010212
[131395.103927] RAX: 88001ef0a360 RBX: 8800119a0cb8 RCX:
00624684
[131395.104018] RDX: 800624684367 RSI: 0007ff460397 RDI:
88003dd7b240
[131395.104108] RBP: c9004659bb70 R08: 88003dd7b240 R09:
7ff4603a2000
[131395.104198] R10: 0001 R11: 3000 R12:
7ff460397000
[131395.104288] R13: 800624684367 R14: 7ff460398000 R15:
c9004659bce0
[131395.104390] FS:  7ff4605667c0() GS:88005500()
knlGS:
[131395.104490] CS:  e033 DS:  ES:  CR0: 80050033
[131395.104564] CR2: 88401920c018 CR3: 1cb0f000 CR4:
00040660
[131395.104655] Call Trace:
[131395.104695]  ? vm_normal_page+0x5d/0xa0
[131395.104748]  unmap_page_range+0x4e3/0x930
[131395.104804]  unmap_single_vma+0x7d/0xf0
[131395.104857]  unmap_vmas+0x51/0xb0
[131395.104904]  unmap_region+0xbd/0x130
[131395.104953]  ? gnttab_map_refs+0xc4/0x160
[131395.105009]  ? gntdev_mmap+0x3a4/0x610 [xen_gntdev]
[131395.105074]  mmap_region+0x461/0x5f0
[131395.105122]  do_mmap+0x2b3/0x400
[131395.105167]  vm_mmap_pgoff+0xcc/0x120
[131395.105217]  SyS_mmap_pgoff+0x1bc/0x230
[131395.105271]  SyS_mmap+0x1b/0x30
[131395.108716]  entry_SYSCALL_64_fastpath+0x1a/0xa5
[131395.112161] RIP: 0033:0x7ff45dcc3e63
[131395.115644] RSP: 002b:7ffdf0c57648 EFLAGS: 0246 ORIG_RAX:
0009
[131395.119149] RAX: ffda RBX: a000 RCX:
7ff45dcc3e63
[131395.122587] RDX: 0002 RSI: b000 RDI:

[131395.126005] RBP: 1000 R08: 002a R09:
c000
[131395.129509] R10: 0001 R11: 0246 R12:
0001
[131395.132989] R13: 560471ae8e00 R14: 560471a66290 R15:

[131395.136568] Code: 5b 5d c3 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
00 48 8b 87 a8 00 00 00 55 48 89 e5 48 2b 70 68 48 8b 40 60 5d 48 c1 ee 0c
<48> 8b 04 f0 c3 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
[131395.143798] RIP: gntdev_vma_find_special_page+0x1d/0x30 [xen_gntdev]
RSP: c9004659bb60
[131395.147367] CR2: 88401920c018
[131395.150844] ---[ end trace bf61e71da2f22d1c ]---

xl info:

host   : orion1695
release: 4.13.7-1-ARCH
version: #1 SMP PREEMPT Sat Oct 14 20:13:26 CEST 2017
machine: x86_64
nr_cpus: 8
max_cpu_id : 23
nr_nodes   : 1
cores_per_socket   : 4
threads_per_core   : 2
cpu_mhz: 2300
hw_caps  

Re: [Xen-devel] [PATCH 10/13] x86/alternative: Support indirect call replacement

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> Add alternative patching support for replacing an instruction with an
> indirect call.  This will be needed for the paravirt alternatives.
> 
> Signed-off-by: Josh Poimboeuf 
> ---
>  arch/x86/kernel/alternative.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 3344d3382e91..81c577c7deba 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -410,20 +410,28 @@ void __init_or_module noinline 
> apply_alternatives(struct alt_instr *start,
>   insnbuf_sz = a->replacementlen;
>  
>   /*
> -  * 0xe8 is a relative jump; fix the offset.
> -  *
> -  * Instruction length is checked before the opcode to avoid
> -  * accessing uninitialized bytes for zero-length replacements.
> +  * Fix the address offsets for call and jump instructions which
> +  * use PC-relative addressing.
>*/
>   if (a->replacementlen == 5 && *insnbuf == 0xe8) {
> + /* direct call */
>   *(s32 *)(insnbuf + 1) += replacement - instr;
> - DPRINTK("Fix CALL offset: 0x%x, CALL 0x%lx",
> + DPRINTK("Fix direct CALL offset: 0x%x, CALL 0x%lx",
>   *(s32 *)(insnbuf + 1),
>   (unsigned long)instr + *(s32 *)(insnbuf + 1) + 
> 5);
> - }
>  
> - if (a->replacementlen && is_jmp(replacement[0]))
> + } else if (a->replacementlen == 6 && *insnbuf == 0xff &&
> +*(insnbuf+1) == 0x15) {
> + /* indirect call */
> + *(s32 *)(insnbuf + 2) += replacement - instr;
> + DPRINTK("Fix indirect CALL offset: 0x%x, CALL *0x%lx",
> + *(s32 *)(insnbuf + 2),
> + (unsigned long)instr + *(s32 *)(insnbuf + 2) + 
> 6);
> +
> + } else if (a->replacementlen && is_jmp(replacement[0])) {

Is this correct? Without your patch this was:

if (*insnbuf == 0xe8) ...
if (is_jmp(replacement[0])) ...

Now you have:

if (*insnbuf == 0xe8) ...
else if (*insnbuf == 0xff15) ...
else if (is_jmp(replacement[0])) ...

So only one or none of the three variants will be executed. In the past
it could be none, one or both.


Juergen

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

Re: [Xen-devel] [PATCH 09/13] x86/asm: Convert ALTERNATIVE*() assembler macros to preprocessor macros

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> The ALTERNATIVE() and ALTERNATIVE_2() macros are GNU assembler macros,
> which makes them quite inflexible for future changes.  Convert them to
> preprocessor macros.
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 08/13] x86/paravirt: Clean up paravirt_types.h

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> Make paravirt_types.h more understandable:
> 
> - Use more consistent and logical naming
> - Simplify interfaces
> - Put related macros together
> - Improve whitespace
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 07/13] x86/paravirt: Simplify ____PVOP_CALL()

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> Remove the inline asm duplication in PVOP_CALL().
> 
> Also add 'IS_ENABLED(CONFIG_X86_32)' to the return variable logic,
> making the code clearer and rendering the comment unnecessary.
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[George Dunlap]

On Tue, Oct 24, 2017 at 12:42 PM, Andrew Cooper
 wrote:
> On 24/10/17 11:27, George Dunlap wrote:
>> On 10/23/2017 06:55 PM, Andrew Cooper wrote:
>>> On 23/10/17 17:22, George Dunlap wrote:
 On 09/11/2017 06:53 PM, Andrew Cooper wrote:
> On 11/09/17 18:01, George Dunlap wrote:
>> +### x86/RAM
>> +
>> +Limit, x86: 16TiB
>> +Limit, ARM32: 16GiB
>> +Limit, ARM64: 5TiB
>> +
>> +[XXX: Andy to suggest what this should say for x86]
> The limit for x86 is either 16TiB or 123TiB, depending on
> CONFIG_BIGMEM.  CONFIG_BIGMEM is exposed via menuconfig without
> XEN_CONFIG_EXPERT, so falls into at least some kind of support statement.
>
> As for practical limits, I don't think its reasonable to claim anything
> which we can't test.  What are the specs in the MA colo?
 At the moment the "Limit" tag specifically says that it's theoretical
 and may not work.

 We could add another tag, "Limit-tested", or something like that.

 Or, we could simply have the Limit-security be equal to the highest
 amount which has been tested (either by osstest or downstreams).

 For simplicity's sake I'd go with the second one.
>>> It think it would be very helpful to distinguish the upper limits from
>>> the supported limits.  There will be a large difference between the two.
>>>
>>> Limit-Theoretical and Limit-Supported ?
>> Well "supported" without any modifiers implies "security supported".  So
>> perhaps we could just `s/Limit-security/Limit-supported/;` ?
>
> By this, you mean use Limit-Supported throughout this document?  That
> sounds like a good plan.

Yes, that's basically what I meant.

>> +Limit, x86 HVM: 128
>> +Limit, ARM32: 8
>> +Limit, ARM64: 128
>> +
>> +[XXX Andrew Cooper: Do want to add "Limit-Security" here for some of 
>> these?]
> 32 for each.  64 vcpu HVM guests can excerpt enough p2m lock pressure to
> trigger a 5 second host watchdog timeout.
 Is that "32 for x86 PV and x86 HVM", or "32 for x86 HVM and ARM64"?  Or
 something else?
>>> The former.  I'm not qualified to comment on any of the ARM limits.
>>>
>>> There are several non-trivial for_each_vcpu() loops in the domain_kill
>>> path which aren't handled by continuations.  ISTR 128 vcpus is enough to
>>> trip a watchdog timeout when freeing pagetables.
>> I don't think 32 is a really practical limit.
>
> What do you mean by practical here, and what evidence are you basing
> this on?
>
> Amongst other things, there is an ABI boundary in Xen at 32 vcpus, and
> given how often it is broken in Linux, its clear that there isn't
> regular testing happening beyond this limit.

Is that true for dom0 as well?

>> I'm inclined to say that if a rogue guest can crash a host with 33 vcpus, we 
>> should issue an XSA
>> and fix it.
>
> The reason XenServer limits at 32 vcpus is that I can crash Xen with a
> 64 vcpu HVM domain.  The reason it hasn't been my top priority to fix
> this is because there is very little customer interest in pushing this
> limit higher.
>
> Obviously, we should fix issues as and when they are discovered, and
> work towards increasing the limits in the longterm, but saying "this
> limit seems too low, so lets provisionally set it higher" is short
> sighted and a recipe for more XSAs.

OK -- I'll set this to 32 for now and see if anyone else wants to
argue for a different value.

>> +
>> +### x86 PV/Event Channels
>> +
>> +Limit: 131072
> Why do we call out event channel limits but not grant table limits?
> Also, why is this x86?  The 2l and fifo ABIs are arch agnostic, as far
> as I am aware.
 Sure, but I'm pretty sure that ARM guests don't (perhaps cannot?) use PV
 event channels.
>>> This is mixing the hypervisor API/ABI capabilities with the actual
>>> abilities of guests (which is also different to what Linux would use in
>>> the guests).
>> I'd say rather that you are mixing up the technical abilities of a
>> system with user-facing features.  :-)  At the moment there is no reason
>> for any ARM user to even think about event channels, so there's no
>> reason to bother them with the technical details.  If at some point that
>> changes, we can modify the document.
>
> You do realise that receiving an event is entirely asymmetric with
> sending an event?
>
> Even on ARM, {net,blk}front needs to speak event_{2l,fifo} with Xen to
> bind and use its interdomain event channel(s) with {net,blk}back.

I guess I didn't realize that (and just noticed Stefano's comment
saying ARM uses event channels).

>>> ARM guests, as well as x86 HVM with APICV (configured properly) will
>>> actively want to avoid the guest event channel interface, because its
>>> slower.
>>>
>>> This solitary evtchn limit serves no useful purpose IMO.
>> There may be a point to what you're saying: The event channel limit
>> normally manifests itself as a limit 

Re: [Xen-devel] [PATCH 06/13] x86/paravirt: Clean up paravirt-asm.h

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> Some cleanup to make the code easier to read and understand:
> 
> - Use the common "PV_" prefix
> - Simplify the PV_SITE macro interface
> - Improve whitespace
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH] pci-assign: Remove

[Anthony PERARD]

On Fri, Oct 20, 2017 at 10:25:38AM +0200, Paolo Bonzini wrote:
> Legacy PCI device assignment has been removed from Linux in 4.12,
> and had been deprecated 2 years ago there.  We can remove it from
> QEMU as well.
> 
> The ROM loading code was shared with Xen PCI passthrough, so move
> it to hw/xen.
> 
> Cc: Stefano Stabellini 
> Cc: Anthony Perard 
> Cc: xen-de...@lists.xenproject.org
> Signed-off-by: Paolo Bonzini 
> ---
> Xen parts only compile-tested.
> 
>  docs/qdev-device-use.txt   |   12 +-
>  hw/i386/Makefile.objs  |1 -
>  hw/i386/kvm/Makefile.objs  |2 +-
>  hw/i386/kvm/pci-assign.c   | 1883 
> 
>  hw/xen/Makefile.objs   |1 +
>  .../xen_pt_load_rom.c} |4 +-
>  include/hw/pci/pci-assign.h|   27 -
>  qdev-monitor.c |1 -
>  scripts/device-crash-test  |2 -
>  9 files changed, 6 insertions(+), 1927 deletions(-)
>  delete mode 100644 hw/i386/kvm/pci-assign.c
>  rename hw/{i386/pci-assign-load-rom.c => xen/xen_pt_load_rom.c} (96%)
>  delete mode 100644 include/hw/pci/pci-assign.h
> 
> diff --git a/hw/i386/pci-assign-load-rom.c b/hw/xen/xen_pt_load_rom.c
> similarity index 96%
> rename from hw/i386/pci-assign-load-rom.c
> rename to hw/xen/xen_pt_load_rom.c
> index 43429b66be..2bc3b6c092 100644
> --- a/hw/i386/pci-assign-load-rom.c
> +++ b/hw/xen/xen_pt_load_rom.c
> @@ -12,7 +12,7 @@
>  #include "qemu/range.h"
>  #include "sysemu/sysemu.h"
>  #include "hw/pci/pci.h"
> -#include "hw/pci/pci-assign.h"
> +#include "xen_pt.h"
>  
>  /*
>   * Scan the assigned devices for the devices that have an option ROM, and 
> then
> @@ -80,7 +80,7 @@ close_rom:
>  fseek(fp, 0, SEEK_SET);
>  val = 0;
>  if (!fwrite(, 1, 1, fp)) {
> -DEBUG("%s\n", "Failed to disable pci-sysfs rom file");
> +XEN_PT_WARN("%s\n", "Failed to disable pci-sysfs rom file");

XEN_PT_WARN takes an extra argument, it should read:
XEN_PT_WARN(dev, "%s\n", "Failed to disable pci-sysfs rom file");

With that fixed:
Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

[Xen-devel] [xen-unstable-coverity test] 115212: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  be7f60b5a39741eab0a8fea0324f7be0cb724cfb
baseline version:
 xen  8e77dabc58c4b6c747dfb4b948551147905a7840

Last test of basis   115014  2017-10-22 09:19:04 Z3 days
Testing same since   115212  2017-10-25 09:23:49 Z0 days1 attempts


People who touched revisions under test:
  Chao Gao 
  Ian Jackson 
  Jan Beulich 
  Wei Liu 

jobs:
 coverity-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=xen-unstable-coverity
+ revision=be7f60b5a39741eab0a8fea0324f7be0cb724cfb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
xen-unstable-coverity be7f60b5a39741eab0a8fea0324f7be0cb724cfb
+ branch=xen-unstable-coverity
+ revision=be7f60b5a39741eab0a8fea0324f7be0cb724cfb
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ 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
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.9-testing
+ '[' xbe7f60b5a39741eab0a8fea0324f7be0cb724cfb = 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-4.9
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : 

Re: [Xen-devel] [PATCH 05/13] x86/paravirt: Move paravirt asm macros to paravirt-asm.h

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> The paravirt.h file is quite big and the asm interfaces for paravirt
> don't need to be in the same file as the C interfaces.  Move the asm
> interfaces to a dedicated header file.
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 


Juergen

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

[Xen-devel] [PATCH] osstest: fix examine job in generic flight

[Roger Pau Monne]

Previous patches only added the FreeBSD runvars to the jobs in the
examine flight, but failed to also add them to the examine job in the
generic flight.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
---
 make-flight | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index ecce3c0a..d595101c 100755
--- a/make-flight
+++ b/make-flight
@@ -675,9 +675,11 @@ do_examine_one () {
 linux-*)   ;; # often seems to regress
 *) return  ;; # stuff used for guests is irrelevant
   esac
+  local freebsd_runvars
+  set_freebsd_runvars
   job_create_test test-$xenarch$kern-$dom0arch-examine \
   host-examine-xen xl $xenarch $dom0arch \
-  all_hostflags=$most_hostflags
+  all_hostflags=$most_hostflags $freebsd_runvars
 }
 
 test_matrix_do_one () {
-- 
2.13.5 (Apple Git-94)


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

Re: [Xen-devel] [PATCH] x86/vpmu: Remove unnecessary call to do_interrupt()

[Andrew Cooper]

On 25/10/17 00:30, Boris Ostrovsky wrote:
> This call was left during PVHv1 removal (commit 33e5c32559e1 ("x86:
> remove PVHv1 code")):
>
> -if ( is_pvh_vcpu(sampling) &&
> - !(vpmu_mode & XENPMU_MODE_ALL) &&
> +if ( !(vpmu_mode & XENPMU_MODE_ALL) &&
>   !vpmu->arch_vpmu_ops->do_interrupt(regs) )
>  return;
>
> As result of this extra call VPMU no longer works for PV guests on Intel
> because we effectively lose value of MSR_CORE_PERF_GLOBAL_STATUS.
>
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Andrew Cooper 

> ---
> This should also go into 4.9

Agreed, and therefore makes it a 4.10 candidate at this point.

~Andrew

>
>  xen/arch/x86/cpu/vpmu.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> index fd2fcac..7baf461 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -227,10 +227,6 @@ void vpmu_do_interrupt(struct cpu_user_regs *regs)
>  if ( !vpmu->xenpmu_data )
>  return;
>  
> -if ( !(vpmu_mode & XENPMU_MODE_ALL) &&
> - !vpmu->arch_vpmu_ops->do_interrupt(regs) )
> -return;
> -
>  if ( vpmu_is_set(vpmu, VPMU_CACHED) )
>  return;
>  


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

[Xen-devel] [xen-4.6-testing test] 115190: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-2  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 114488
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114488
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 114514
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114514
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114514
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114514
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114514
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114514
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114514
 test-xtf-amd64-amd64-4   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-2   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  9454e3030ae0835c11aa66471238a9e09db5074e
baseline version:
 xen  aad5a67587b493e2478e1e46f71404c3dd41a937

Last test of basis   114514  2017-10-15 08:19:24 Z   10 days
Testing same since   115190  2017-10-24 15:13:45 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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

Re: [Xen-devel] [PATCH for-4.10 1/2] tools/libxc: Fix precopy_policy() to not pass a structure by value

[Andrew Cooper]

On 19/10/17 16:17, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH for-4.10 1/2] tools/libxc: Fix 
> precopy_policy() to not pass a structure by value"):
>> On 16/10/17 16:07, Ian Jackson wrote:
>>> This statement is true only if you think "the precopy callback" refers
>>> to the stub generated by libxl_save_msgs_gen.
>> The commit is about save_callbacks.precopy_policy() specifically (and
>> IMO, obviously).
>>
>> Given this, the statement is true.
> I don't agree.

Don't agree with what?  The justification for why passing-by-value is
supposedly necessary is bogus irrespective of whether you consider just
the libxc part of the callback, or the end-to-end path into libxl.

No argument concerning address space (separate or otherwise) is a
related to how parameter passing needs to happen at this level.

FAOD, the actual reason why it was done that way was because no-one
wanted to edit libxl_save_msgs_gen.pl to be able to cope with pointers,
but "$WE don't want to do it properly" is not a reasonable justification.

>
>>>   But a more natural
>>> reading is that "the precopy callback" refers to the actual code which
>>> implements whatever logic is required.
>>>
>>> In a system using libxl, that code definitely _is_ executing in a
>>> separate address space.  And passing the stats by value rather than
>>> reference does make it marginally easier.
>> There is no libxl code for any of this.
> That is of course a deficiency which we hope will be remedied,
> surely.  We should expect there to be libxl code.

All the more reason to fix this nonsense before a libxl gains a
production use.

>
 Switch the callback to passing by pointer which is far more efficient, and
 drop the typedef (because none of the other callback have this oddity).
>>> I would like you to expand on this efficiency argument.
>> The two most common mechanisms are either to pass the object split
>> across pre-agreed registers, or the compiler rearranges things to have a
>> local stack object, pass by pointer, and have the prologue memcpy() it
>> into local scope.
>>
>> The resulting change in calling convention is implementation defined,
>> and subject to several different code-gen options in GCC or Clang.
>>
>> Therefore it is inappropriate for such an interface to exist in the
>> libxenguest ABI.
> I asked you to expand on an efficiency argument and instead

If you don't understand the explanation in the first paragraph, then say
so and I will try to explain it in more simple temrs, or defer to
someone who does understand why hiding a prologue memcpy() is bad for
performance.

Frankly, I'm annoyed that the first patch got committed, as the code is
not in a fit state and it had obvious open objections.

However, what is really irritating me is that, not only am I having to
divert time from more important tasks to try and fix this code before we
ship a release with it in, but that I'm having to fight you for the
privilege of maintaining that the migration code doesn't regress back
into the cesspit that was the legacy code.

The live migration algorithm is the most performance-critical part of
libxenguest.

Having an IPC call in the middle of the live loop it is bad, and will
increase the downtime of the VM.  However, the IPC call is optional
which means the common case doesn't need to suffer the overhead.   
Passing by value even in the common case is an entirely unnecessary
overhead, and this fact alone is justification enough to not do it.

~Andrew

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

Re: [Xen-devel] [PATCH 04/13] x86/paravirt: Convert DEF_NATIVE macro to GCC extended asm syntax

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> In a future patch, the NATIVE_* instruction string macros will be used
> in GCC extended inline asm, which requires registers to have two '%'
> instead of one in the asm template string.  Convert the DEF_NATIVE macro
> to the GCC extended asm syntax so the NATIVE_* macros can be shared more
> broadly.
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 03/13] x86/paravirt: Convert native patch assembly code strings to macros

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> Convert the hard-coded native patch assembly code strings to macros to
> facilitate sharing common code between 32-bit and 64-bit.
> 
> These macros will also be used by a future patch which requires the GCC
> extended asm syntax of two '%' characters instead of one when specifying
> a register name.
> 
> Signed-off-by: Josh Poimboeuf 

Reviewed-by: Juergen Gross 

Mind adding another patch to merge the now nearly identical
paravirt_patch_32.c and paravirt_patch_64.c either into paravirt.c
or paravirt_patch.c? This would require only very few #ifdef.


Juergen

> ---
>  arch/x86/include/asm/special_insns.h | 24 
>  arch/x86/kernel/paravirt_patch_32.c  | 21 +++--
>  arch/x86/kernel/paravirt_patch_64.c  | 29 +++--
>  3 files changed, 50 insertions(+), 24 deletions(-)
> 
> diff --git a/arch/x86/include/asm/special_insns.h 
> b/arch/x86/include/asm/special_insns.h
> index ac402c6fc24b..0549c5f2c1b3 100644
> --- a/arch/x86/include/asm/special_insns.h
> +++ b/arch/x86/include/asm/special_insns.h
> @@ -6,6 +6,30 @@
>  
>  #include 
>  
> +#ifdef CONFIG_X86_64
> +# define _REG_ARG1   "%rdi"
> +# define NATIVE_IDENTITY_32  "mov %edi, %eax"
> +# define NATIVE_USERGS_SYSRET64  "swapgs; sysretq"
> +#else
> +# define _REG_ARG1   "%eax"
> +#endif
> +
> +#define _REG_RET "%" _ASM_AX
> +
> +#define NATIVE_ZERO  "xor " _REG_ARG1 ", " _REG_ARG1
> +#define NATIVE_IDENTITY  "mov " _REG_ARG1 ", " _REG_RET
> +#define NATIVE_SAVE_FL   "pushf; pop " _REG_RET
> +#define NATIVE_RESTORE_FL"push " _REG_ARG1 "; popf"
> +#define NATIVE_IRQ_DISABLE   "cli"
> +#define NATIVE_IRQ_ENABLE"sti"
> +#define NATIVE_READ_CR2  "mov %cr2, " _REG_RET
> +#define NATIVE_READ_CR3  "mov %cr3, " _REG_RET
> +#define NATIVE_WRITE_CR3 "mov " _REG_ARG1 ", %cr3"
> +#define NATIVE_FLUSH_TLB_SINGLE  "invlpg (" _REG_ARG1 ")"
> +#define NATIVE_SWAPGS"swapgs"
> +#define NATIVE_IRET  "iret"
> +#define NATIVE_QUEUED_SPIN_UNLOCK"movb $0, (" _REG_ARG1 ")"
> +
>  /*
>   * Volatile isn't enough to prevent the compiler from reordering the
>   * read/write functions for the control registers and messing everything up.
> diff --git a/arch/x86/kernel/paravirt_patch_32.c 
> b/arch/x86/kernel/paravirt_patch_32.c
> index 553acbbb4d32..c9c6106ae714 100644
> --- a/arch/x86/kernel/paravirt_patch_32.c
> +++ b/arch/x86/kernel/paravirt_patch_32.c
> @@ -1,17 +1,18 @@
>  #include 
> +#include 
>  
> -DEF_NATIVE(pv_irq_ops, irq_disable, "cli");
> -DEF_NATIVE(pv_irq_ops, irq_enable, "sti");
> -DEF_NATIVE(pv_irq_ops, restore_fl, "push %eax; popf");
> -DEF_NATIVE(pv_irq_ops, save_fl, "pushf; pop %eax");
> -DEF_NATIVE(pv_cpu_ops, iret, "iret");
> -DEF_NATIVE(pv_mmu_ops, read_cr2, "mov %cr2, %eax");
> -DEF_NATIVE(pv_mmu_ops, write_cr3, "mov %eax, %cr3");
> -DEF_NATIVE(pv_mmu_ops, read_cr3, "mov %cr3, %eax");
> +DEF_NATIVE(pv_irq_ops,   save_fl,NATIVE_SAVE_FL);
> +DEF_NATIVE(pv_irq_ops,   restore_fl, NATIVE_RESTORE_FL);
> +DEF_NATIVE(pv_irq_ops,   irq_disable,NATIVE_IRQ_DISABLE);
> +DEF_NATIVE(pv_irq_ops,   irq_enable, NATIVE_IRQ_ENABLE);
> +DEF_NATIVE(pv_cpu_ops,   iret,   NATIVE_IRET);
> +DEF_NATIVE(pv_mmu_ops,   read_cr2,   NATIVE_READ_CR2);
> +DEF_NATIVE(pv_mmu_ops,   read_cr3,   NATIVE_READ_CR3);
> +DEF_NATIVE(pv_mmu_ops,   write_cr3,  NATIVE_WRITE_CR3);
>  
>  #if defined(CONFIG_PARAVIRT_SPINLOCKS)
> -DEF_NATIVE(pv_lock_ops, queued_spin_unlock, "movb $0, (%eax)");
> -DEF_NATIVE(pv_lock_ops, vcpu_is_preempted, "xor %eax, %eax");
> +DEF_NATIVE(pv_lock_ops,  queued_spin_unlock, 
> NATIVE_QUEUED_SPIN_UNLOCK);
> +DEF_NATIVE(pv_lock_ops,  vcpu_is_preempted,  NATIVE_ZERO);
>  #endif
>  
>  unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len)
> diff --git a/arch/x86/kernel/paravirt_patch_64.c 
> b/arch/x86/kernel/paravirt_patch_64.c
> index 0a1ba3f80cbf..0aa232edd670 100644
> --- a/arch/x86/kernel/paravirt_patch_64.c
> +++ b/arch/x86/kernel/paravirt_patch_64.c
> @@ -1,25 +1,26 @@
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -DEF_NATIVE(pv_irq_ops, irq_disable, "cli");
> -DEF_NATIVE(pv_irq_ops, irq_enable, "sti");
> -DEF_NATIVE(pv_irq_ops, restore_fl, "pushq %rdi; popfq");
> -DEF_NATIVE(pv_irq_ops, save_fl, "pushfq; popq %rax");
> -DEF_NATIVE(pv_mmu_ops, read_cr2, "movq %cr2, %rax");
> -DEF_NATIVE(pv_mmu_ops, read_cr3, "movq %cr3, %rax");
> -DEF_NATIVE(pv_mmu_ops, write_cr3, "movq %rdi, %cr3");
> -DEF_NATIVE(pv_mmu_ops, flush_tlb_single, "invlpg (%rdi)");
> +DEF_NATIVE(pv_irq_ops,   save_fl,

Re: [Xen-devel] [PATCH v3 2/7] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

[Zhongze Liu]

Hi,

My current plan is to add the following new MAPSPACE to public/memory.h:

+#define XENMEMSPACE_gmfn_foreign_share 6 /* Same as *_gmfn_foreign, but this is
+for a privileged dom to
+shared pages between two doms. */

and create a corresponding  entry xsm_map_gmfn_foreign_share to the
xsm structure, which will be filled with
the proposed policy.

Does this look good to you?

Cheers,

Zhongze Liu

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

Re: [Xen-devel] [PATCH 02/13] x86/paravirt: Fix output constraint macro names

[Juergen Gross]

On 04/10/17 17:58, Josh Poimboeuf wrote:
> Some of the paravirt '*_CLOBBERS' macros refer to output constraints
> instead of clobbers, which makes the code extra confusing.  Rename the
> output constraint related macros to '*_OUTPUTS'.
> 
> Signed-off-by: Josh Poimboeuf 

I'm fine with the changes, but you might want to rename the "call_clbr"
parameter of PVOP_[V]CALL, too, e.g. to "outputs".

You could then drop the "CALL_" from the macros, too.


Juergen

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

[Xen-devel] [PATCH 2/5 v2] libxl: Change the type of console_mfn to xen_pfn_t

[Bhupinder Thakur]

Currently the type of console mfn is unsigned long in libxl. This may be
an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are
64 bit. To ensure that console_mfn can hold any valid 64-bit pfn, the
type of console_mfn is changed to xen_pfn_t.

Signed-off-by: Bhupinder Thakur 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/libxl/libxl_console.c  | 2 +-
 tools/libxl/libxl_dom.c  | 2 +-
 tools/libxl/libxl_internal.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 6bfc0e5..f2ca689 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
 flexarray_append(ro_front, "port");
 flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->console_port));
 flexarray_append(ro_front, "ring-ref");
-flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
+flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, 
state->console_mfn));
 } else {
 flexarray_append(front, "state");
 flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index ef834e6..a58e74f 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -869,7 +869,7 @@ out:
 static int hvm_build_set_params(xc_interface *handle, uint32_t domid,
 libxl_domain_build_info *info,
 int store_evtchn, unsigned long *store_mfn,
-int console_evtchn, unsigned long *console_mfn,
+int console_evtchn, xen_pfn_t *console_mfn,
 domid_t store_domid, domid_t console_domid)
 {
 struct hvm_info_table *va_hvm;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 45e6df6..f52aeb3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1128,7 +1128,7 @@ typedef struct {
 
 uint32_t console_port;
 uint32_t console_domid;
-unsigned long console_mfn;
+xen_pfn_t console_mfn;
 char *console_tty;
 
 char *saved_state;
-- 
2.7.4


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

[Xen-devel] [PATCH 3/5 v2] libxc: Fix the data type of mfn parameter passed to xc_map_foreign_range()

[Bhupinder Thakur]

Currently the data type of mfn parameter passed to xc_map_foreign_range() is 
unsigned
long. This could be problem for 32-bit arm architectures where the lengh of 
long is
32 bits while mfn happens to be a 64-bit value.

To avoid truncating a 64-bit value, the type of mfn is changed from "unsigned 
long" to
xen_pfn_t. Also the parameter name "mfn" is changed to "pfn" which is a more 
accurate
indication of what this parameter represents.

Signed-off-by: Bhupinder Thakur 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/libxc/include/xenctrl_compat.h | 2 +-
 tools/libxc/xc_foreign_memory.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/include/xenctrl_compat.h 
b/tools/libxc/include/xenctrl_compat.h
index a655e47..5ee72bf 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -26,7 +26,7 @@
  */
 void *xc_map_foreign_range(xc_interface *xch, uint32_t dom,
 int size, int prot,
-unsigned long mfn );
+xen_pfn_t pfn);
 
 void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, int prot,
const xen_pfn_t *arr, int num );
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 4053d26..c1f114a 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -33,7 +33,7 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
 
 void *xc_map_foreign_range(xc_interface *xch,
uint32_t dom, int size, int prot,
-   unsigned long mfn)
+   xen_pfn_t pfn)
 {
 xen_pfn_t *arr;
 int num;
@@ -46,7 +46,7 @@ void *xc_map_foreign_range(xc_interface *xch,
 return NULL;
 
 for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
+arr[i] = pfn + i;
 
 ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
 free(arr);
-- 
2.7.4


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

[Xen-devel] [PATCH 5/5 v2] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

[Bhupinder Thakur]

xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for initializing 
ring-ref.

Signed-off-by: Bhupinder Thakur 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/console/daemon/io.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 1839973..aa291db 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -62,6 +62,8 @@
 /* Duration of each time period in ms */
 #define RATE_LIMIT_PERIOD 200
 
+#define XEN_INVALID_PFN (~(xen_pfn_t)0)
+
 extern int log_reload;
 extern int log_guest;
 extern int log_hv;
@@ -658,12 +660,12 @@ static void console_unmap_interface(struct console *con)
 {
if (con->interface == NULL)
return;
-   if (xgt_handle && con->ring_ref == -1)
+   if (xgt_handle && con->ring_ref == XEN_INVALID_PFN)
xengnttab_unmap(xgt_handle, con->interface, 1);
else
munmap(con->interface, XC_PAGE_SIZE);
con->interface = NULL;
-   con->ring_ref = -1;
+   con->ring_ref = XEN_INVALID_PFN;
 }
  
 static int console_create_ring(struct console *con)
@@ -698,7 +700,7 @@ static int console_create_ring(struct console *con)
free(type);
 
/* If using ring_ref and it has changed, remap */
-   if (ring_ref != con->ring_ref && con->ring_ref != -1)
+   if (ring_ref != con->ring_ref && con->ring_ref != XEN_INVALID_PFN)
console_unmap_interface(con);
 
if (!con->interface && xgt_handle && con->use_gnttab) {
@@ -706,7 +708,7 @@ static int console_create_ring(struct console *con)
con->interface = xengnttab_map_grant_ref(xgt_handle,
dom->domid, GNTTAB_RESERVED_CONSOLE,
PROT_READ|PROT_WRITE);
-   con->ring_ref = -1;
+   con->ring_ref = XEN_INVALID_PFN;
}
if (!con->interface) {
/* Fall back to xc_map_foreign_range */
@@ -812,7 +814,7 @@ static int console_init(struct console *con, struct domain 
*dom, void **data)
con->master_pollfd_idx = -1;
con->slave_fd = -1;
con->log_fd = -1;
-   con->ring_ref = -1;
+   con->ring_ref = XEN_INVALID_PFN;
con->local_port = -1;
con->remote_port = -1;
con->xce_pollfd_idx = -1;
-- 
2.7.4


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

[Xen-devel] [PATCH 1/5 v2] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"

[Bhupinder Thakur]

In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:

> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));

However, xenstore reads this value as a decimal value and tries to map the
wrong address and fails.

This patch introduces a new format specifier "PRIu_xen_pfn" which formats the 
value as a
decimal value.

Signed-off-by: Bhupinder Thakur 
Acked-by: Wei Liu 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 

 tools/libxl/libxl_console.c   | 2 +-
 xen/include/public/arch-arm.h | 1 +
 xen/include/public/arch-x86/xen.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index c05dc28..6bfc0e5 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
 flexarray_append(ro_front, "port");
 flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
 flexarray_append(ro_front, "ring-ref");
-flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
+flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, state->vuart_gfn));
 flexarray_append(ro_front, "limit");
 flexarray_append(ro_front, GCSPRINTF("%d", LIBXL_XENCONSOLE_LIMIT));
 flexarray_append(ro_front, "type");
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 5708cd2..05fd11c 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -274,6 +274,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
+#define PRIu_xen_pfn PRIu64
 
 /* Maximum number of virtual CPUs in legacy multi-processor guests. */
 /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index ff91831..3b0b1d6 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -75,6 +75,7 @@ __DeFiNe__ __DECL_REG_LO16(name) e ## name
 #ifndef __ASSEMBLY__
 typedef unsigned long xen_pfn_t;
 #define PRI_xen_pfn "lx"
+#define PRIu_xen_pfn "lu"
 #endif
 
 #define XEN_HAVE_PV_GUEST_ENTRY 1
-- 
2.7.4


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

[Xen-devel] [PATCH 4/5 v2] xenconsole: Change the type of ring_ref to xen_pfn_t in console_create_ring

[Bhupinder Thakur]

Currently, ring_ref is read as an integer in console_create_ring which could 
lead to
truncation of the value as it is reading a 64-bit value.

The fix is to modify the type of ring_ref to xen_pfn_t and use the correct 
format
specifier to read the value correctly for all architectures.

Signed-off-by: Bhupinder Thakur 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/console/daemon/io.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e22009a..1839973 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -19,6 +19,7 @@
 
 #define _GNU_SOURCE
 
+#include 
 #include "utils.h"
 #include "io.h"
 #include 
@@ -81,6 +82,12 @@ static unsigned int nr_fds;
 
 #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
+#if defined(CONFIG_ARM)
+# define SCNi_xen_pfn SCNi64
+#else
+# define SCNi_xen_pfn "li"
+#endif
+
 struct buffer {
char *data;
size_t consumed;
@@ -98,7 +105,7 @@ struct console {
struct buffer buffer;
char *xspath;
char *log_suffix;
-   int ring_ref;
+   xen_pfn_t ring_ref;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
int event_count;
@@ -661,12 +668,13 @@ static void console_unmap_interface(struct console *con)
  
 static int console_create_ring(struct console *con)
 {
-   int err, remote_port, ring_ref, rc;
+   int err, remote_port, rc;
+   xen_pfn_t ring_ref;
char *type, path[PATH_MAX];
struct domain *dom = con->d;
 
err = xs_gather(xs, con->xspath,
-   "ring-ref", "%u", _ref,
+   "ring-ref", "%"SCNi_xen_pfn, _ref,
"port", "%i", _port,
NULL);
 
@@ -705,7 +713,7 @@ static int console_create_ring(struct console *con)
con->interface = xc_map_foreign_range(
xc, dom->domid, XC_PAGE_SIZE,
PROT_READ|PROT_WRITE,
-   (unsigned long)ring_ref);
+   ring_ref);
if (con->interface == NULL) {
err = EINVAL;
goto out;
-- 
2.7.4


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 114790
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
114790
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
114790

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

version targeted for testing:
 xen  830224431b67fd2afad9bdc532dc1bede20032d5
baseline version:
 xen  df0949d197cc753871f5df1a0358b43edd2fd365

Last test of basis   114790  2017-10-20 07:58:26 Z5 days
Testing same since   115189  2017-10-24 15:12:30 Z0 days1 attempts


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

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

Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Paul Durrant]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@linaro.org]
> Sent: 23 October 2017 20:04
> To: Paul Durrant ; 'Jan Beulich'
> 
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger
> Pau Monne ; Wei Liu ; Stefano
> Stabellini ; xen-de...@lists.xenproject.org; Konrad
> Rzeszutek Wilk ; Daniel De Graaf
> ; Tim (Xen.org) 
> Subject: Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add
> HYPERVISOR_memory_op to acquire guest resources
> 
> 
> 
> On 20/10/17 11:10, Paul Durrant wrote:
> >> -Original Message-
> >> From: Julien Grall [mailto:julien.gr...@linaro.org]
> >> Sent: 20 October 2017 11:00
> >> To: Paul Durrant ; 'Jan Beulich'
> >> 
> >> Cc: Julien Grall ; Andrew Cooper
> >> ; George Dunlap
> >> ; Ian Jackson ;
> Roger
> >> Pau Monne ; Wei Liu ;
> Stefano
> >> Stabellini ; xen-de...@lists.xenproject.org;
> Konrad
> >> Rzeszutek Wilk ; Daniel De Graaf
> >> ; Tim (Xen.org) 
> >> Subject: Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add
> >> HYPERVISOR_memory_op to acquire guest resources
> >>
> >> Hi Paul,
> >>
> >> On 20/10/17 09:26, Paul Durrant wrote:
>  -Original Message-
>  From: Jan Beulich [mailto:jbeul...@suse.com]
>  Sent: 20 October 2017 07:25
>  To: Julien Grall 
>  Cc: Julien Grall ; Andrew Cooper
>  ; George Dunlap
>  ; Ian Jackson ;
> Paul
>  Durrant ; Roger Pau Monne
>  ; Wei Liu ; Stefano
> Stabellini
>  ; xen-de...@lists.xenproject.org; Konrad
> >> Rzeszutek
>  Wilk ; Daniel De Graaf
> >> ;
>  Tim (Xen.org) 
>  Subject: Re: [Xen-devel] [PATCH v12 05/11] x86/mm: add
>  HYPERVISOR_memory_op to acquire guest resources
> 
> >>> On 19.10.17 at 18:21,  wrote:
> > Looking a bit more at the resource you can acquire from this hypercall.
> > Some of them are allocated using alloc_xenheap_page() so not
> assigned
> >> to
> > a domain.
> >
> > So I am not sure how you can expect a function
> set_foreign_p2m_entry
> >> to
> > take reference in that case.
> 
>  Hmm, with the domain parameter added, DOMID_XEN there (for
>  Xen heap pages) could identify no references to be taken, if that
>  was really the intended behavior in that case. However, even for
>  Xen heap pages life time tracking ought to be done - it is for a
>  reason that share_xen_page_with_guest() assigns the target
>  domain as the owner of such pages, as that allows get_page() to
>  succeed for them.
> 
> >>>
> >
> > Hi Julien,
> >
> >>> So, nothing I'm doing here is making anything worse, right? Grant tables
> are
> >> assigned to the guest, and IOREQ server pages are allocated with
> >> alloc_domheap_page() so nothing is anonymous.
> >>
> >> I don't think grant tables is assigned to the guest today. They are
> >> allocated using xenheap_pages() and I can't find
> >> share_xen_page_with_guest().
> >
> > The guest would not be able to map them if they were not assigned in
> some way!
> 
> Do you mean for PV? For HVM/PVH, we don't check whether the page is
> assigned (see gnttab_map_frame).

Not there, but I though there were checks in guest_physmap_add_page() where the 
mfn passed back from gnttab_map_frame() is actually consumed. It's all quite 
convoluted though so I'm not sure.

> 
> > See the code block at
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/common/grant_tab
> le.c;hb=HEAD#l1716
> > It calls gnttab_create_shared_page() which is what calls through to
> share_xen_page_with_guest().
> 
> Thank you for the link, I will have a look.
> 
> >
> >>
> >> Anyway, I discussed with Stefano about it. set_foreign_p2m_entry is
> >> going to be left unimplemented on Arm until someone as time to
> implement
> >> correctly the function.
> >>
> >
> > That makes sense. Do you still have any issues with this patch apart from
> the cosmetic ones you spotted in the header?
> 
> No. Although, may I request to add a comment in the ARM helpers about
> the reference counting?
> 

Sure. Thanks,

  Paul

> Cheers,
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 10/23/2017 8:26 PM, Julien Grall wrote:

Hi,

On 23/10/17 14:57, Andre Przywara wrote:

On 12/10/17 22:03, Manish Jaggi wrote:

It is proposed that the idrange of PCIRC and ITS group be constant for
domUs.


"constant" is a bit confusing here. Maybe "arbitrary", "from scratch" or
"independent from the actual h/w"?


I don't think we should tie to anything here. IORT for DomU will get 
some input, it could be same as the host or something generated (not 
necessarily constant). That's implementation details and might be up 
to the user.





In case if PCI PT,using a domctl toolstack can communicate
physical RID: virtual RID, deviceID: virtual deviceID to xen.

It is assumed that domU PCI Config access would be trapped in Xen. The
RID at which assigned device is enumerated would be the one provided 
by the

domctl, domctl_set_deviceid_mapping

TODO: device assign domctl i/f.
Note: This should suffice the virtual deviceID support pointed by 
Andre.

[4]


Well, there's more to it. First thing: while I tried to include virtual
ITS deviceIDs to be different from physical ones, in the moment there
are fixed to being mapped 1:1 in the code.

So the first step would be to go over the ITS code and identify where
"devid" refers to a virtual deviceID and where to a physical one
(probably renaming them accordingly). Then we would need a function to
translate between the two. At the moment this would be a dummy function
(just return the input value). Later we would loop in the actual table.


We might not need this domctl if assign_device hypercall is extended to
provide this information.


Do we actually need a new interface or even extend the existing one?
If I got Julien correctly, the existing interface is just fine?


In the first place, I am not sure to understand why Domctl is 
mentioned in this document.

I have answered this in reply to Andres mail. Please refer to that.
(Just avoiding duplication)
I can understand why you want to describe the information used for 
DomU IORT. But it does not matter at how this is tying to the rest of 
the passthrough work.



Passthrough could be PCI Device PT or platform device passthrough.


[...]



6. IORT Generation
---
There would be a common code to generate IORT table from 
iort_table_struct.


That sounds useful, but we would need to be careful with sharing code
between Xen and the tool stack. Has this actually been done before?


Yes, see libelf for instance. But I think there is a terminology 
problem here.


Skimming the rest of the e-mail I see: "populate a basic IORT in a 
buffer passed by toolstack (using a domctl : domctl_prepare_dom_iort)".
By sharing code, I meant creating a library that would be compiled in 
both the hypervisor and the toolstack.
It might need more work. I have answered this in reply to Andres mail. 
Please refer to that.


But as I said before, this is not the purpose now. The purpose is 
finally getting support of IORT in the hypervisor with the generation 
of the IORT for Dom0 fully separated from the parsing.


Thats not the only purpose, I have described the tasks in reply to 
Andres mail. Please refer to that.

a. For Dom0
 the structure (iort_table_struct) be modified to remove smmu nodes
 and update id_mappings.
 PCIRC idmap -> output refrence to ITS group.
 (RID -> DeviceID).

 TODO: Describe algo in update_id_mapping function to map RID ->
DeviceID used
 in my earlier patch [3]


If the above approach works, this would become a simple list iteration,
creating PCI rc nodes with the appropriate pointer to the ITS nodes.


b. For DomU
 - iort_table_struct would have minimal 2 nodes (1 PCIRC and 1 ITS
group)
 - populate a basic IORT in a buffer passed by toolstack( using a
domctl : domctl_prepare_dom_iort)


I think we should reduce this to iterating the same data structure as
for Dom0. Each pass-through-ed PCI device would possibly create one
struct instance, and later on we do the same iteration as we do for
Dom0. If that proves to be simple enough, we might even live with the
code duplication between Xen and the toolstack.


I think you summarize quite what I have been saying in the previous 
thread. Thank you :).


Cheers,




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

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 10/23/2017 7:27 PM, Andre Przywara wrote:

Hi Manish,

On 12/10/17 22:03, Manish Jaggi wrote:

ACPI/IORT Support in Xen.
--

I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending
the scope
and including all that is required to support ACPI/IORT in Xen.
Presenting for review
first _draft_ of design of ACPI/IORT support in Xen. Not complete though.

Discussed is the parsing and generation of IORT table for Dom0 and DomUs.
It is proposed that IORT be parsed and the information in saved into xen
data-structure
say host_iort_struct and is reused by all xen subsystems like ITS / SMMU
etc.

Since this is first draft is open to technical comments, modifications
and suggestions. Please be open and feel free to add any missing points
/ additions.

1. What is IORT. What are its components ?
2. Current Support in Xen
3. IORT for Dom0
4. IORT for DomU
5. Parsing of IORT in Xen
6. Generation of IORT
7. Future Work and TODOs

1. What is IORT. What are its components ?

IORT refers to Input Output remapping table. It is essentially used to find
information about the IO topology (PCIRC-SMMU-ITS) and relationships
between
devices.

A general structure of IORT is has nodes which have information about
PCI RC,
SMMU, ITS and Platform devices. Using an IORT table relationship between
RID -> StreamID -> DeviceId can be obtained. More specifically which
device is
behind which SMMU and which interrupt controller, this topology is
described in
IORT Table.

RID is a requester ID in PCI context,
StreamID is the ID of the device in SMMU context,
DeviceID is the ID programmed in ITS.

For a non-pci device RID could be simply an ID.

Each iort_node contains an ID map array to translate from one ID into
another.
IDmap Entry {input_range, output_range, output_node_ref, id_count}
This array is present in PCI RC node,SMMU node, Named component node etc
and can reference to a SMMU or ITS node.

2. Current Support of IORT
---
Currently Xen passes host IORT table to dom0 without any modifications.
For DomU no IORT table is passed.

3. IORT for Dom0
-
IORT for Dom0 is prepared by xen and it is fairly similar to the host iort.
However few nodes could be removed removed or modified. For instance
- host SMMU nodes should not be present
- ITS group nodes are same as host iort but, no stage2 mapping is done
for them.

What do you mean with stage2 mapping?

Please ignore this line. Copy paste error. Read it as follows

- ITS group nodes are same as host iort.
(though I would modify the same as in next draft)




- platform nodes (named components) may be selectively present depending
on the case where xen is using some. This could be controlled by  xen command
line.

Mmh, I am not so sure platform devices described in the IORT (those
which use MSIs!) are so much different from PCI devices here. My
understanding is those platform devices are network adapters, for
instance, for which Xen has no use.

ok.

So I would translate "Named Components" or "platform devices" as devices
just not using the PCIe bus (so no config space and no (S)BDF), but
being otherwise the same from an ITS or SMMU point of view.

Correct.

- More items : TODO

I think we agreed upon rewriting the IORT table instead of patching it?
yes. In fact if you look at my patch v2 on IORT SMMU hiding, it was 
_rewriting_ most of Dom0 IORT and not patching it.

We can have a IRC discussion on this.

I think apart from rewriting, the other tasks which were required that 
are handled in this epic task

- parse IORT and save in xen internal data structures
- common code to generate IORT for dom0/domU
- All xen code that parses IORT multiple times use now the xen internal 
data structures.

(I have explained this in this mail below)

So to some degree your statements are true, but when we rewrite the IORT
table without SMMUs (and possibly without other components like the
PMUs), it would be kind of a stretch to call it "fairly similar to the
host IORT". I think "based on the host IORT" would be more precise.

Yes. Based on host IORT is better,thanks.



4. IORT for DomU
-
IORT for DomU is generated by the toolstack. IORT topology is different
when DomU supports device passthrough.

Can you elaborate on that? Different compared to what? My understanding
is that without device passthrough there would be no IORT in the first
place?

I was exploring the possibility of having virtual devices for DomU.
So if a virtual is assigned to guest there needs to be some mapping in 
IORT as well.

This virtual device can be on a PCI bus / or as a platform device.

Device Pass-through can be split into two parts
a. platform device passthrough (not on PCI bus)
b. PCI device PT

=> If we discount the possibility of a virtual device for domU and 
platform device passthrough

 then you are correct no IORT is required.

When PCI device passthrough is 

[Xen-devel] [distros-debian-squeeze test] 72350: tolerable trouble: broken/fail/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64-pvops 2 hosts-allocate   broken like 72228
 build-arm64   2 hosts-allocate   broken like 72228
 build-arm64-pvops 3 capture-logs broken like 72228
 build-arm64   3 capture-logs broken like 72228
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
72228
 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
72228
 test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
72228
 test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
72228

baseline version:
 flight   72228

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-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-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] [PATCH V3 20/29] VIOMMU: Add get irq info callback to convert irq remapping request

[Lan Tianyu]

On 2017年10月25日 15:43, Roger Pau Monné wrote:
> On Wed, Oct 25, 2017 at 03:30:39PM +0800, Lan Tianyu wrote:
>> On 2017年10月19日 23:42, Roger Pau Monné wrote:
>>> On Thu, Sep 21, 2017 at 11:02:01PM -0400, Lan Tianyu wrote:
>>>
  
  struct viommu_ops {
 @@ -28,6 +29,9 @@ struct viommu_ops {
  int (*destroy)(struct viommu *viommu);
  int (*handle_irq_request)(struct domain *d,
struct arch_irq_remapping_request *request);
 +int (*get_irq_info)(struct domain *d,
 +struct arch_irq_remapping_request *request,
>>>
>>> AFAICT d and request should be constified.
>>
>> Did you mean to keep d and request in the same line? This will exceed 80
>> chars.
> 
> No, I meant that the parameters of the function should be "const struct
> domain *d" and "const struct arch_irq_remapping_request *request".
> AFAICT you should never modify them inside of get_irq_info.
> 

OK. I got it. This makes sense and will update.

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH V3 20/29] VIOMMU: Add get irq info callback to convert irq remapping request

[Roger Pau Monné]

On Wed, Oct 25, 2017 at 03:30:39PM +0800, Lan Tianyu wrote:
> On 2017年10月19日 23:42, Roger Pau Monné wrote:
> > On Thu, Sep 21, 2017 at 11:02:01PM -0400, Lan Tianyu wrote:
> > 
> >>  
> >>  struct viommu_ops {
> >> @@ -28,6 +29,9 @@ struct viommu_ops {
> >>  int (*destroy)(struct viommu *viommu);
> >>  int (*handle_irq_request)(struct domain *d,
> >>struct arch_irq_remapping_request *request);
> >> +int (*get_irq_info)(struct domain *d,
> >> +struct arch_irq_remapping_request *request,
> > 
> > AFAICT d and request should be constified.
> 
> Did you mean to keep d and request in the same line? This will exceed 80
> chars.

No, I meant that the parameters of the function should be "const struct
domain *d" and "const struct arch_irq_remapping_request *request".
AFAICT you should never modify them inside of get_irq_info.

Roger.

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

Re: [Xen-devel] [PATCH RFC 05/14] xen: vmx: Disable the 2M/1G superpage when SPP enabled

[Yi Zhang]

On 2017-10-24 at 11:43:45 -0600, Tamas K Lengyel wrote:
> On Fri, Oct 20, 2017 at 2:44 AM, Yi Zhang  wrote:
> > On 2017-10-19 at 12:17:12 -0600, Tamas K Lengyel wrote:
> >> On Thu, Oct 19, 2017 at 2:11 AM, Zhang Yi  
> >> wrote:
> >> > From: Zhang Yi Z 
> >> >
> >> > Current we only support Sub-page Protection on the 4k
> >> > page table.
> >> >
> >> > Signed-off-by: Zhang Yi Z 
> >> > ---
> >> >  xen/arch/x86/hvm/vmx/vmx.c | 6 ++
> >> >  1 file changed, 6 insertions(+)
> >> >
> >> > diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> >> > index 04ae0d6..a4c24bb 100644
> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> > @@ -2497,6 +2497,12 @@ const struct hvm_function_table * __init 
> >> > start_vmx(void)
> >> >  vmx_function_table.get_guest_bndcfgs = vmx_get_guest_bndcfgs;
> >> >  }
> >> >
> >> > +if ( cpu_has_vmx_ept_spp )
> >>
> >> I think this really only ought to happen if the command-line option
> >> has also been enabled.
> >
> > Sorry, didn't catch your point, the command line option opt_hap_2m and
> > opt_hap_1G was enable by default, I need to  disable the supper page
> > when spp feature enabled. Did you mean that if we enable 2M/1G by
> > command-line we couldn't disable it here? yes, it is, I will improve
> > this logic. Thank you Tamas.
> 
> I meant that right now "cpu_has_vmx_ept_spp" looks like just checks
> whether the CPU supports SPP, not whether the command-line option was
> set to enable it. If the command line option is not set (or
> specifically disables SPP) then the large pages shouldn't get
> disabled.
> 

In patch 02/14, if we didn't set spp_enable, we will not set the spp cap 
in vmx_secondary_exec_control, so cp_has_vmx_ept_spp flag will set when 
hardware has spp cap and xen cmdlline passed the parameter "spp_enable=1"

> >
> >>
> >> > +{
> >> > +vmx_function_table.hap_capabilities &= ~HVM_HAP_SUPERPAGE_2MB;
> >> > +vmx_function_table.hap_capabilities &= ~HVM_HAP_SUPERPAGE_1GB;
> >> > +}
> >> > +
> >> >  setup_vmcs_dump();
> >> >
> >> >  lbr_tsx_fixup_check();
> >> > --
> >> > 2.7.4

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

Re: [Xen-devel] [PATCH V3 20/29] VIOMMU: Add get irq info callback to convert irq remapping request

[Lan Tianyu]

On 2017年10月19日 23:42, Roger Pau Monné wrote:
> On Thu, Sep 21, 2017 at 11:02:01PM -0400, Lan Tianyu wrote:
>> This patch is to add get_irq_info callback for platform implementation
>> to convert irq remapping request to irq info (E,G vector, dest, dest_mode
>> and so on).
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  xen/common/viommu.c  | 16 
>>  xen/include/asm-x86/viommu.h |  8 
>>  xen/include/xen/viommu.h | 14 ++
>>  3 files changed, 38 insertions(+)
>>
>> diff --git a/xen/common/viommu.c b/xen/common/viommu.c
>> index b517158..0708e43 100644
>> --- a/xen/common/viommu.c
>> +++ b/xen/common/viommu.c
>> @@ -178,6 +178,22 @@ int viommu_handle_irq_request(struct domain *d,
>>  return viommu->ops->handle_irq_request(d, request);
>>  }
>>  
>> +int viommu_get_irq_info(struct domain *d,
>> +struct arch_irq_remapping_request *request,
>> +struct arch_irq_remapping_info *irq_info)
>> +{
>> +struct viommu *viommu = d->viommu;
>> +
>> +if ( !viommu )
>> +return -EINVAL;
> 
> OK, here there's a check for !viommu. Can we please have this written
> down in the header? (ie: which functions are safe/expected to be
> called without a viommu)

Sure. I will add some comments.

> 
>> +
>> +ASSERT(viommu->ops);
>> +if ( !viommu->ops->get_irq_info )
>> +return -EINVAL;
>> +
>> +return viommu->ops->get_irq_info(d, request, irq_info);
>> +}
>> +
>>  /*
>>   * Local variables:
>>   * mode: C
>> diff --git a/xen/include/asm-x86/viommu.h b/xen/include/asm-x86/viommu.h
>> index 366fbb6..586b6bd 100644
>> --- a/xen/include/asm-x86/viommu.h
>> +++ b/xen/include/asm-x86/viommu.h
>> @@ -24,6 +24,14 @@
>>  #define VIOMMU_REQUEST_IRQ_MSI  0
>>  #define VIOMMU_REQUEST_IRQ_APIC 1
>>  
>> +struct arch_irq_remapping_info
>> +{
>> +uint8_t  vector;
>> +uint32_t dest;
>> +uint32_t dest_mode:1;
>> +uint32_t delivery_mode:3;
> 
> Why uint32_t for this two last fields? Also please sort them so that
> the padding is limited at the end of the structure.

Yes, this makes sense.

> 
>> +};
>> +
>>  struct arch_irq_remapping_request
>>  {
>>  union {
>> diff --git a/xen/include/xen/viommu.h b/xen/include/xen/viommu.h
>> index 230f6b1..beb40cd 100644
>> --- a/xen/include/xen/viommu.h
>> +++ b/xen/include/xen/viommu.h
>> @@ -21,6 +21,7 @@
>>  #define __XEN_VIOMMU_H__
>>  
>>  struct viommu;
>> +struct arch_irq_remapping_info;
>>  struct arch_irq_remapping_request;
> 
> If you include asm/viommu.h in viommu.h you don't need to forward
> declarations.

Will update.

> 
>>  
>>  struct viommu_ops {
>> @@ -28,6 +29,9 @@ struct viommu_ops {
>>  int (*destroy)(struct viommu *viommu);
>>  int (*handle_irq_request)(struct domain *d,
>>struct arch_irq_remapping_request *request);
>> +int (*get_irq_info)(struct domain *d,
>> +struct arch_irq_remapping_request *request,
> 
> AFAICT d and request should be constified.

Did you mean to keep d and request in the same line? This will exceed 80
chars.


-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [PATCH for-4.10 v2 0/5] tools/dombuilder: Fixes and improvements to grant handling

[Juergen Gross]

On 24/10/17 18:06, Julien Grall wrote:
> Hi,
> 
> I think this is 4.10 material (particularly patch #5). Juergen, would it
> be possible get the some feedback on this series?

Patch 5: Reviewed-by: Juergen Gross 


Juergen

> 
> Cheers,
> 
> On 12/10/17 20:19, Andrew Cooper wrote:
>> A git tree version is available:
>>
>> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/dombuilder-gnt-v2
>>
>>
>> Changes in v2: Mainly a rebase over c/s 5b42c82f "tools/libxc: Fix domid
>> parameter types", and fixup from review comments.  See individual
>> patches for
>> details
>>
>> Andrew Cooper (5):
>>    tools/dombuilder: Drop more PVH v1 leftovers
>>    tools/dombuilder: Remove clear_page() from xc_dom_boot.c
>>    tools/dombuilder: Switch to using gfn terminology for console and
>>  xenstore rings
>>    tools/dombuilder: Fix asymmetry when setting up console and xenstore
>>  rings
>>    tools/dombuilder: Prevent failures of xc_dom_gnttab_init()
>>
>>   tools/libxc/include/xc_dom.h  |  26 ++--
>>   tools/libxc/xc_dom_arm.c  |  17 ++---
>>   tools/libxc/xc_dom_boot.c | 126
>> +++---
>>   tools/libxc/xc_dom_compat_linux.c |   6 +-
>>   tools/libxc/xc_dom_core.c |   8 +++
>>   tools/libxc/xc_dom_x86.c  |  57 +
>>   tools/libxl/libxl_dom.c   |  51 ++-
>>   tools/libxl/libxl_internal.h  |   1 -
>>   8 files changed, 169 insertions(+), 123 deletions(-)
>>
> 


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

[Xen-devel] [xen-4.9-testing test] 115186: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail REGR. vs. 
115018

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop   fail REGR. vs. 115018

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail like 114733
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 114949
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114949
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigratefail like 115018
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 115018
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 115018
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  61b6df9d821481ba4e26e5843aa9320345077319
baseline version:
 xen  2040ac14e4cfbae679751796266527d92d11ac78

Last test of basis   115018  2017-10-22 09:59:18 Z2 days
Testing same since   115186  2017-10-24 14:46:59 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Kevin Tian 
  Wei Liu 

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

[Xen-devel] [PATCH v3 1/1] xen/time: do not decrease steal time after live migration on xen

[Dongli Zhang]

After guest live migration on xen, steal time in /proc/stat
(cpustat[CPUTIME_STEAL]) might decrease because steal returned by
xen_steal_lock() might be less than this_rq()->prev_steal_time which is
derived from previous return value of xen_steal_clock().

For instance, steal time of each vcpu is 335 before live migration.

cpu  198 0 368 200064 1962 0 0 1340 0 0
cpu0 38 0 81 50063 492 0 0 335 0 0
cpu1 65 0 97 49763 634 0 0 335 0 0
cpu2 38 0 81 50098 462 0 0 335 0 0
cpu3 56 0 107 50138 374 0 0 335 0 0

After live migration, steal time is reduced to 312.

cpu  200 0 370 200330 1971 0 0 1248 0 0
cpu0 38 0 82 50123 500 0 0 312 0 0
cpu1 65 0 97 49832 634 0 0 312 0 0
cpu2 39 0 82 50167 462 0 0 312 0 0
cpu3 56 0 107 50207 374 0 0 312 0 0

Since runstate times are cumulative and cleared during xen live migration
by xen hypervisor, the idea of this patch is to accumulate runstate times
to global percpu variables before live migration suspend. Once guest VM is
resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
runstate times and previously accumulated times stored in global percpu
variables.

Similar and more severe issue would impact prior linux 4.8-4.10 as
discussed by Michael Las at
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
which would overflow steal time and lead to 100% st usage in top command
for linux 4.8-4.10. A backport of this patch would fix that issue.

References: 
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
Signed-off-by: Dongli Zhang 

---
Changed since v1:
  * relocate modification to xen_get_runstate_snapshot_cpu

Changed since v2:
  * accumulate runstate times before live migration

---
 drivers/xen/manage.c  |  1 +
 drivers/xen/time.c| 19 +++
 include/xen/xen-ops.h |  1 +
 3 files changed, 21 insertions(+)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index c425d03..9aa2955 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -72,6 +72,7 @@ static int xen_suspend(void *data)
}
 
gnttab_suspend();
+   xen_accumulate_runstate_time();
xen_arch_pre_suspend();
 
/*
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index ac5f23f..6df3f82 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -19,6 +19,8 @@
 /* runstate info updated by Xen */
 static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
 
+static DEFINE_PER_CPU(u64[4], old_runstate_time);
+
 /* return an consistent snapshot of 64-bit time/counter value */
 static u64 get64(const u64 *p)
 {
@@ -52,6 +54,7 @@ static void xen_get_runstate_snapshot_cpu(struct 
vcpu_runstate_info *res,
 {
u64 state_time;
struct vcpu_runstate_info *state;
+   int i;
 
BUG_ON(preemptible());
 
@@ -64,6 +67,22 @@ static void xen_get_runstate_snapshot_cpu(struct 
vcpu_runstate_info *res,
rmb();  /* Hypervisor might update data. */
} while (get64(>state_entry_time) != state_time ||
 (state_time & XEN_RUNSTATE_UPDATE));
+
+   for (i = 0; i < 4; i++)
+   res->time[i] += per_cpu(old_runstate_time, cpu)[i];
+}
+
+void xen_accumulate_runstate_time(void)
+{
+   struct vcpu_runstate_info state;
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   xen_get_runstate_snapshot_cpu(, cpu);
+   memcpy(per_cpu(old_runstate_time, cpu),
+   state.time,
+   4 * sizeof(u64));
+   }
 }
 
 /*
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 218e6aa..5680059 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -32,6 +32,7 @@ void xen_resume_notifier_unregister(struct notifier_block 
*nb);
 bool xen_vcpu_stolen(int vcpu);
 void xen_setup_runstate_info(int cpu);
 void xen_time_setup_guest(void);
+void xen_accumulate_runstate_time(void);
 void xen_get_runstate_snapshot(struct vcpu_runstate_info *res);
 u64 xen_steal_clock(int cpu);
 
-- 
2.7.4


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