Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field ‘anonymous’

[Wei Liu]

On Wed, Aug 26, 2015 at 01:37:12PM -0400, Konrad Rzeszutek Wilk wrote:
 On Wed, Aug 26, 2015 at 01:32:54AM -0600, Jan Beulich wrote:
   On 25.08.15 at 21:54, konrad.w...@oracle.com wrote:
   On Tue, Aug 25, 2015 at 03:52:15PM -0400, Konrad Rzeszutek Wilk wrote:
   On Tue, Aug 25, 2015 at 06:41:06PM +0100, Andrew Cooper wrote:
On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -238,7 +238,9 @@ struct domain *alloc_domain_struct(void)
  if ( unlikely(!bits) )
   bits = _domain_struct_bits();
  
 +#ifndef LOCK_PROFILE
  BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
 +#endif
  d = alloc_xenheap_pages(0, MEMF_bits(bits));
  if ( d != NULL )
  clear_page(d);

 (not compile tested nor runtime tested)

Either remove it locally for debugging, or use something like
   
   I forgot to mention that by removing it locally Xen ends up halting at:
   
   (XEN) Detected 3292.657 MHz processor.
  
  Sure - as Andrew said on irc, neither simply removing it nor replacing
  it by vmalloc() can actually work. At the very least you'd want the
  above to become
 
 I ended up doing:
 
 From 52548151b6db3724fdafd005f52fc1aaefa65eff Mon Sep 17 00:00:00 2001
 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 Date: Tue, 25 Aug 2015 21:25:54 -0400
 Subject: [PATCH] x86: Allow 'struct domain' to expand past PAGE_SIZE
 
 If we are building with lock profilling enabled - as that
 expands the spinlock structures considerably.
 
 Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 ---
  xen/arch/x86/domain.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
 index 045f6ff..7df58d8 100644
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -237,9 +237,10 @@ struct domain *alloc_domain_struct(void)
  
  if ( unlikely(!bits) )
   bits = _domain_struct_bits();
 -
 +#ifndef LOCK_PROFILE
  BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
 -d = alloc_xenheap_pages(0, MEMF_bits(bits));
 +#endif
 +d = alloc_xenheap_pages(get_order_from_bytes(sizeof(*d)), 
 MEMF_bits(bits));
  if ( d != NULL )
  clear_page(d);
  return d;
 @@ -261,7 +262,7 @@ struct vcpu *alloc_vcpu_struct(void)
   * structure must satisfy this restriction. Thus we specify 
 MEMF_bits(32).
   */
  BUILD_BUG_ON(sizeof(*v)  PAGE_SIZE);
 -v = alloc_xenheap_pages(0, MEMF_bits(32));
 +v = alloc_xenheap_pages(get_order_from_bytes(sizeof(*v)), MEMF_bits(32));
  if ( v != NULL )
  clear_page(v);

clear_page() works on PAGE_SIZE page so if you allocate order 2 page it
is not sufficient.

Wei.

  return v;
 -- 
 2.1.0
 
 
 which made it compile and boot. However the moment I ran xenlockprof I got
 this nice splash:
 
 (XEN) CPU:0
 (XEN) RIP:e008:[82d08012e0fa] spinlocerate+0x5b/0x96
 (XEN) RFLAGS: 00010202   CONTEXT: hypervisor (d0v0)
 (XEN) rax: 83009e6f7e40   rbx: c2c2c2c2c2c2c2c2   rcx: 83009e6f7d48
 (XEN) rdx: 003d   rsi: 0001   rdi: c2c2c2c2c2c2c2c2
 (XEN) rbp: 83009e6f7d38   rsp: 83009e6f7cf8   r8:  deadbeef
 (XEN) r9:  deadbeef   r10: 82d0802542a0   r11: 0286
 (XEN) r12: 830413381078   r13: 0001   r14: 82d08012da37
 (XEN) r15: 83009e6f7d48   cr0: 80050033   cr4: 000426e0
 (XEN) cr3: 000411303000   cr2: 7f42d4a6e9a0
 (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
 (XEN) Xen stack trace from rsp=83009e6f7cf8:
 (XEN)00411fc1 82d080327ef0 8304 83009e6f7e40
 (XEN)7f42d4ea4004 83009e6f7f18 83009e6f7f18 82d08031be00
 (XEN)83009e6f7d68 82d08012e1e5 83009e6f7e40 82d0
 (XEN)  83009e6f7ef8 82d08012f3fa
 (XEN)83009e6f7d98 83042c186000 83009e8b 83009e6f7d98
 (XEN)83009e6f7f18 83009e6f7f18 83009e6f7f18 83009e6f7f18
 (XEN)83009e6f7f18 83009e6f7f18 83009e6f7f18 
 (XEN)83009e6f7eb0 83009e6f7ea8 88008020ab10 00411fc1
 (XEN) 8307 00037ff0 820040008000
 (XEN)83009e8b 800402e3d067 00040002 83009e6f7f18
 (XEN)000c000f 0002 7ffd003e 
 (XEN) 7f42d4a5a8e8 010eb050 
 (XEN)7ffd86253bd0 004008f0 7ffd86253cb0 7f42d4ca07c5
 (XEN)010eb050 7f42d47ae695 7ffd86253b68 7ffd86253b68
 (XEN)010eb050 0033 83009e6f7ed8 83009e8b
 (XEN)880068795900 88007395dd88 0003 7ffd86253900
 (XEN)7cff619080c7 82d0802396d2 8100146a 0023
 (XEN)

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Malcolm Crossley]

On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:
 On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
 On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
 Hi everyone,
 I saw some people passingly mention this on the list before but just in
 case it has been missed, my serial is also being spammed with the following
 printouts with both Xen 4.6 RC1 and the latest staging build:

 ...
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 2610742000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
 ...



I think this problem is caused by missing IOMMU mappings for the RMRR regions
if the domain does not have shared EPT enabled. This includes PV Dom 0.

I have posted a patch to fix the issue:

http://lists.xen.org/archives/html/xen-devel/2015-08/msg02090.html



 What's your platform? BDW? And how much memory is set to your guest OS?
 
 Is see this as well. But oddly enough - only when I use the AMT feature
 (normally I just use serial console on the machine).
 
 The platform is /DQ67SW, BIOS
 SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
 
 There is no guest OS - this is initial domain. And I boot with 2GB:
  Released 0 page(s)
 
 Xen: [mem 0x-0x00099fff] usable
 Xen: [mem 0x0009a800-0x000f] reserved
 Xen: [mem 0x0010-0x1fff] usable
 Xen: [mem 0x2000-0x201f] reserved
 Xen: [mem 0x2020-0x3fff] usable
 Xen: [mem 0x4000-0x401f] reserved
 Xen: [mem 0x4020-0x80465fff] usable
 Xen: [mem 0x80466000-0x9e855fff] unusable
 Xen: [mem 0x9e856000-0x9e85efff] ACPI data
 Xen: [mem 0x9e85f000-0x9e8a9fff] ACPI NVS
 Xen: [mem 0x9e8aa000-0x9e8b1fff] unusable
 Xen: [mem 0x9e8b2000-0x9e9a4fff] reserved
 Xen: [mem 0x9e9a5000-0x9e9a6fff] unusable
 Xen: [mem 0x9e9a7000-0x9ebc5fff] reserved
 Xen: [mem 0x9ebc6000-0x9ebc6fff] unusable
 Xen: [mem 0x9ebc7000-0x9ebd6fff] reserved
 Xen: [mem 0x9ebd7000-0x9ebf4fff] ACPI NVS
 Xen: [mem 0x9ebf5000-0x9ec18fff] reserved
 Xen: [mem 0x9ec19000-0x9ec5bfff] ACPI NVS
 Xen: [mem 0x9ec5c000-0x9ee7bfff] reserved
 Xen: [mem 0x9ee7c000-0x9eff] unusable
 Xen: [mem 0x9f80-0xbf9f] reserved
 Xen: [mem 0xfec0-0xfec00fff] reserved
 Xen: [mem 0xfed1c000-0xfed3] reserved
 Xen: [mem 0xfed9-0xfed91fff] reserved
 Xen: [mem 0xfee0-0xfeef] reserved
 Xen: [mem 0xff00-0x] reserved
 Xen: [mem 0x0001-0x00043e5f] unusable
 

 Just at first glance to fault address, this seems be issued from some 
 known erratas on BDS and SKL.
 
 I am runnig v4.2-rc8.

 Thanks
 Tiejun

 The device in question is an integrated Intel graphics card:

 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
 Processor Family Integrated Graphics Controller (rev 09)
 
 Same device..

This is a sandy bridge device which doesn't support shared EPT for GPU device.



 The only way I found to stop the messages from making my serial connection
 useless was by assigning the device to xen-pciback.

This will cause the GPU to be reset and the reset stopped the GPU accessing the
RMRR region.


 Cheers,
 Tamas



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


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


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

[Xen-devel] [linux-3.14 bisection] complete test-amd64-i386-xl-qcow2

[osstest service owner]

branch xen-unstable
xen branch xen-unstable
job test-amd64-i386-xl-qcow2
test guest-saverestore

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
  Bug introduced:  9e6c072a69d87100808d16279d60e9f857291340
  Bug not present: b60d3eee854b881b3f7a478c8b622cbef72d4c4e


  commit 9e6c072a69d87100808d16279d60e9f857291340
  Author: Marek Marczykowski-Górecki marma...@invisiblethingslab.com
  Date:   Fri Jun 26 03:28:24 2015 +0200

  xen/gntdevt: Fix race condition in gntdev_release()

  commit 30b03d05e07467b8c6ec683ea96b5bffcbcd3931 upstream.

  While gntdev_release() is called the MMU notifier is still registered
  and can traverse priv-maps list even if no pages are mapped (which is
  the case -- gntdev_release() is called after all). But
  gntdev_release() will clear that list, so make sure that only one of
  those things happens at the same time.

  Signed-off-by: Marek Marczykowski-Górecki 
marma...@invisiblethingslab.com
  Signed-off-by: David Vrabel david.vra...@citrix.com
  Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org


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


Searching for failure / basis pass:
 60823 fail [host=huxelrebe1] / 60666 [host=chardonnay1] 60655 [host=elbling1] 
60549 [host=chardonnay0] template as basis? using template as basis.
Failure / basis pass flights: 60823 / 60666
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git
Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 318ff69ca4c275bae4b875b87df5bdbd7988486a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
145a8004a7d659668d5a3b0ad9868d7678b24822
Basis pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
201eac83831d94ba2e9a63a7eed4c128633fafb1
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#9b8b905951bde404f20a7bd4b37a5134f3484569-318ff69ca4c275bae4b875b87df5bdbd7988486a
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/staging/qemu-xen-unstable.git#7f057440b31da38196e3398fd1b618fc36ad97d6-7f057440b31da38196e3398fd1b618fc36ad97d6
 
git://xenbits.xen.org/staging/qemu-upstream-unstable.git#bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa-bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa
 
git://xenbits.xen.org/xen.git#201eac83831d94ba2e9a63a7eed4c128633fafb1-145a8004a7d659668d5a3b0ad9868d7678b24822
+ exec
+ sh -xe
+ cd /home/osstest/repos/linux-stable
+ git remote set-url origin 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /home/osstest/repos/xen
+ git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /home/osstest/repos/linux-stable
+ git remote set-url origin 
git://cache:9419/git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
+ exec
+ sh -xe
+ cd /home/osstest/repos/xen
+ git remote set-url origin git://cache:9419/git://xenbits.xen.org/xen.git
+ git fetch -p origin +refs/heads/*:refs/remotes/origin/*
Loaded 2001 nodes in revision graph
Searching for test results:
 60655 [host=elbling1]
 60666 [host=chardonnay1]
 60821 pass 9b8b905951bde404f20a7bd4b37a5134f3484569 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
201eac83831d94ba2e9a63a7eed4c128633fafb1
 60747 fail 318ff69ca4c275bae4b875b87df5bdbd7988486a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
7f057440b31da38196e3398fd1b618fc36ad97d6 
bcf35eec0b621c46dbf0aeb40c6bc06b5d3981aa 
145a8004a7d659668d5a3b0ad9868d7678b24822
 60787 fail 318ff69ca4c275bae4b875b87df5bdbd7988486a 

Re: [Xen-devel] [PATCH V2] xen/x86: Clean up vm_event-related code in asm-x86/domain.h

[Jan Beulich]

 On 25.08.15 at 23:47, andrew.coop...@citrix.com wrote:
 On 15/08/15 07:23, Razvan Cojocaru wrote:
 As suggested by Jan Beulich, moved struct monitor_write_data from
 struct arch_domain to struct arch_vcpu, as well as moving all
 vm_event-related data from asm-x86/domain.h to struct vm_event,
 and allocating it dynamically only when needed.

 Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
 
 Apologies - this fell off my radar while travelling.
 
 Looks fine, and also looks like a candidate for 4.6 as well?

So far we were pretty determined for this to be a post-4.6
change - why would you see this qualifying for 4.6 at this point?

Jan


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

Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Jan Beulich]

 On 25.08.15 at 18:31, daniel.ki...@oracle.com wrote:
 On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote:
  On 24.08.15 at 22:54, daniel.ki...@oracle.com wrote:
  On Mon, Aug 24, 2015 at 05:35:21AM -0600, Jan Beulich wrote:
   On 22.08.15 at 15:59, daniel.ki...@oracle.com wrote:
   On Thu, Aug 20, 2015 at 09:39:39AM -0600, Jan Beulich wrote:
On 20.07.15 at 16:29, daniel.ki...@oracle.com wrote:
Currently, PE file contains many sections which are not linear (one
after another without any holes) or even do not have representation
in a file (e.g. BSS). In theory there is a chance that we could build
proper PE file using current build system. However, it means that
  
   What is improper about the currently built PE file? And if there is
   anything improper, did you inform the binutils maintainers of the
   problem?
  
   From PE loader point of view everything is OK. However, current Xen PE
   image (at least build on my machines) is not usable by multiboot (v1)
   or multiboot2 protocol compatible loader because it is not linear (one
   section does not live immediately after another without any voids).
 
  Again - either I'm missing something (and then your explanation is
  not good enough) or this is (as said above) a pointless adjustment.
 
  Let's focus on multiboot2 protocol (multiboot (v1) is similar to multiboot2
  in discussed case). In general multiboot2 is able to load any file which
  has:
1. proper multiboot2 header in first 32 KiB of a given file,
2. the text and data segments must be consecutive in the OS image
   (The Multiboot Specification version 1.6).
 
  This implies that we can e.g. build valid ELF file which is also multiboot2
  protocol compatible image. And we does. However, we can go further.
  Potentially we can build valid PE image which is also valid multiboot2
  protocol image. Although current build method does not satisfy requirement
  number 2 because, e.g.:
 
  Sections:
  Idx Name  Size  VMA   LMA   File off
  Algn
0 .text 001513d0  82d08020  82d08020  1000
  2**12
^^
CONTENTS, ALLOC, LOAD, CODE
1 .rodata   0004de12  82d0803513e0  82d0803513e0  00153000
  2**5
^^
CONTENTS, ALLOC, LOAD, READONLY, DATA
 
  Hence, we must use special method to build PE image (I discussed that in
  my earlier email in that topic) to do it compatible with multiboot2
  protocol.

 And you realize that we use a special method for building the
 current flat ELF image too?
 
 Yes, I know about that.

And with that I wonder ...

  This way one file could be loaded by native PE loader, mulitboot (v1)
  protocol
  (it requires relevant header but it does not interfere with PE and
  multiboot2
  protocol stuff) and mutliboot2 protocol compatible loaders. Additionally,
  if it is signed with Secure Boot signature then potentially signature could
  be verified by UEFI itself and e.g. GRUB2. However, as I said earlier this
  requires more work and this is next step which I am going to do after
  applying
  this series. Currently I am going to embed EFI support into ELF file 
  because
  it is easy (less changes; currently used ELF file has required properties
  because multiboot (v1) which we use has similar requirements like 
  multiboot2
  protocol) to make it compatible with multiboot2 protocol.

 I think whether what you do now makes sense depends on the
 ultimate goal: If we want a single binary usable for all three cases,
 then while yes, having EFI code available in the ELF image makes
 sense, using an ELF Image won't work. And we can't have an
 image being both ELF and PE. Hence the goal ought to be to have
 a single PE image, and with that the direction you move seems
 wrong.
 
 It depends how we want to generate proper PE file. There are two options.
 
 We can put manually proper PE header into xen/arch/x86/boot/head.S (maybe
 with some additional needed stuff). Then after build we will have ELF file
 which is loadable by multiboot protocols and has extra PE header. Of course
 it is unusable directly by EFI loader. However, using simple objcopy we can
 extract all interesting stuff from ELF file. This way we get proper PE file
 which is usable by three different boot protocols. Going that way we can
 also remove strict dependency on exact version of binutils which must have
 enabled i386pep support if we wish to build PE image.
 
 Potentially we can choose second way and build proper PE image using ld and
 objcopy/objdump tools with proper options. However, this require more work
 (maybe we will be forced to build something similar to mkelf32) and we bind
 Xen build machinery more tightly with exact version of binutils which is
 not nice.
 
 So, I decided to choose option #1.

... why there's 

Re: [Xen-devel] About runtime service for Xen on ARM

[Jan Beulich]

 On 26.08.15 at 05:24, julien.gr...@citrix.com wrote:
 On 19/08/2015 23:27, Shannon Zhao wrote:
 In addition, if you know this, does it support runtime service for Xen
 on x86?
 
 There is some on-going work for EFI runtime on x86. I'm not sure if it 
 has been upstream (CCed Daniel for this).

Daniel is working on boot improvements; runtime services have been
available from the beginning of EFI support on the x86 side.

Jan


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

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Andrew Cooper]

On 26/08/15 18:15, Konrad Rzeszutek Wilk wrote:
 On Wed, Aug 26, 2015 at 05:19:39PM +0100, Malcolm Crossley wrote:
 On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:
 On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
 On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
 Hi everyone,
 I saw some people passingly mention this on the list before but just in
 case it has been missed, my serial is also being spammed with the 
 following
 printouts with both Xen 4.6 RC1 and the latest staging build:

 ...
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 2610742000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
 ...

 I think this problem is caused by missing IOMMU mappings for the RMRR regions
 if the domain does not have shared EPT enabled. This includes PV Dom 0.

 I have posted a patch to fix the issue:

 http://lists.xen.org/archives/html/xen-devel/2015-08/msg02090.html
 No dice. Still seeing the same problem :-(

Does your BIOS provide suitable extra RMRR regions when AMT is in use? 
IIRC, AMT uses the on-chip GPU as part of its VNC handling.

~Andrew

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

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Konrad Rzeszutek Wilk]

On Wed, Aug 26, 2015 at 06:20:34PM +0100, Andrew Cooper wrote:
 On 26/08/15 18:15, Konrad Rzeszutek Wilk wrote:
  On Wed, Aug 26, 2015 at 05:19:39PM +0100, Malcolm Crossley wrote:
  On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:
  On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
  On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
  Hi everyone,
  I saw some people passingly mention this on the list before but just in
  case it has been missed, my serial is also being spammed with the 
  following
  printouts with both Xen 4.6 RC1 and the latest staging build:
 
  ...
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  2610742000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
  ...
 
  I think this problem is caused by missing IOMMU mappings for the RMRR 
  regions
  if the domain does not have shared EPT enabled. This includes PV Dom 0.
 
  I have posted a patch to fix the issue:
 
  http://lists.xen.org/archives/html/xen-devel/2015-08/msg02090.html
  No dice. Still seeing the same problem :-(
 
 Does your BIOS provide suitable extra RMRR regions when AMT is in use? 
 IIRC, AMT uses the on-chip GPU as part of its VNC handling.

It looks to be (see inline serial log). Ignore the dump_stack in the Linux 
kernel - that
is some code I added.


Trying 192.168.102.15...
Connected to maxsrv2.
Escape character is '^]'.
 Xen 4.6.0-rc
(XEN) Xen version 4.6.0-rc (konrad@(none)) (gcc (GCC) 4.4.4 20100503 (Red Hat 
4.4.4-2)) debug=y Wed Aug 26 14:24:N) Console output is synchronous.
(XEN) Bootloader: unknown
(XEN) Command line: iommu=verbose,debug dom0pvh=0 ucode=scan vpmu= transfer 
time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 2 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 0009a800 (usable)
(XEN)  0009a800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 2000 (usable)
(XEN)  2000 - 2020 (reserved)
(XEN)  2020 - 4000 (usable)
(XEN)  4000 - 4020 (reserved)
(XEN)  4020 - 9e856000 (usable)
(XEN)  9e856000 - 9e85f000 (ACPI data)
(XEN)  9e85f000 - 9e8aa000 (ACPI NVS)
(XEN)  9e8aa000 - 9e8b2000 (usable)
(XEN)  9e8b2000 - 9e9a5000 (reserved)
(XEN)  9e9a5000 - 9e9a7000 (usable)
(XEN)  9e9a7000 - 9ebc6000 (reserved)
(XEN)  9ebc6000 - 9ebc7000 (usable)
(XEN)  9ebc7000 - 9ebd7000 (reserved)
(XEN)  9ebd7000 - 9ebf5000 (ACPI NVS)
(XEN)  9ebf5000 - 9ec19000 (reserved)
(XEN)  9ec19000 - 9ec5c000 (ACPI NVS)
(XEN)  9ec5c000 - 9ee7c000 (reserved)
(XEN)  9ee7c000 - 9f00 (usable)
(XEN)  9f80 - bfa0 (reserved)
(XEN)  fed1c000 - fed4 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00043e60 (usable)
(XEN) ACPI: RSDP 000F0450, 0024 (r2  INTEL)
(XEN) ACPI: XSDT 9E856070, 0064 (r1 INTEL  DQ67SW1072009 AMI 10013)
(XEN) ACPI: FACP 9E85DBC0, 00F4 (r4 INTEL  DQ67SW1072009 AMI 10013)
(XEN) ACPI: DSDT 9E856168, 7A54 (r2 INTEL  DQ67SW 16 INTL 20051117)
(XEN) ACPI: FACS 9EBDBF80, 0040
(XEN) ACPI: APIC 9E85DCB8, 0072 (r3 INTEL  DQ67SW1072009 AMI 10013)
(XEN) ACPI: TCPA 9E85DD30, 0032 (r2 INTEL  DQ67SW  1 MSFT  113)
(XEN) ACPI: SSDT 9E85DD68, 0102 (r1 INTEL  DQ67SW  1 MSFT  301)
(XEN) ACPI: MCFG 9E85DE70, 003C (r1 INTEL  DQ67SW1072009 MSFT   97)
(XEN) ACPI: HPET 9E85DEB0, 0038 (r1 INTEL  DQ67SW1072009 AMI.4)
(XEN) ACPI: ASF! 9E85DEE8, 00A0 (r32 INTEL  DQ67SW  1 TFSMF4240)
(XEN) ACPI: DMAR 9E85DF88, 00E8 (r1 INTEL  DQ67SW  1 INTL1)
(XEN) System RAM: 15819MB (16199164kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00043e60
(XEN) Domain heap initialised
(XEN) Allocated console ring of 1048576 KiB.
(XEN) found SMP MP-table at 000fda50
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 

[Xen-devel] [seabios test] 60861: regressions - FAIL

[osstest service owner]

flight 60861 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60861/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail REGR. vs. 60761

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail REGR. vs. 60761
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60761

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 seabios  2fc20dc42cf4a3131fb65c12b2825cd5daa91e7e
baseline version:
 seabios  4c904957cdadd8232fdf87fc370ffa97b22f1e17

Last test of basis60761  2015-08-17 16:43:32 Z8 days
Testing same since60861  2015-08-24 15:10:25 Z2 days1 attempts


People who touched revisions under test:
  Kevin O'Connor ke...@koconnor.net

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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 2fc20dc42cf4a3131fb65c12b2825cd5daa91e7e
Author: Kevin O'Connor ke...@koconnor.net
Date:   Mon Aug 24 09:50:30 2015 -0400

xhci: Minor - add USB port type comments to xhci_hub_reset()

Signed-off-by: Kevin O'Connor ke...@koconnor.net

commit 9f7b2362ef9d6f8e7de54c9d245778c575bd1b23
Author: Kevin O'Connor ke...@koconnor.net
Date:   Mon Aug 10 12:51:41 2015 -0400

sdcard: Allow sdcard addresses to be specified in CBFS files

Allow a hardcoded address to be specified in cbfs files with a prefix
of etc/sdcard.  Some real-world devices have valid SDHCI controllers
that do not show up as PCI devices.

Signed-off-by: Kevin O'Connor ke...@koconnor.net

commit 5ddce09ab45ec87a61723c6b100e13294b5d7757
Author: Kevin O'Connor ke...@koconnor.net
Date:   Mon Aug 10 15:50:53 2015 -0400

ps2: Eliminate etc/ps2-poll-only; use CONFIG_HARDWARE_IRQ instead

The etc/ps2-poll-only runtime setting is directly tied to the new
CONFIG_HARDWARE_IRQ setting - use the compile time setting to control
both.

Signed-off-by: Kevin O'Connor ke...@koconnor.net

commit bd5f6c7432f4c8297871ed4e243dc69a9cece318
Author: Kevin O'Connor ke...@koconnor.net
Date:   Mon Aug 10 16:14:48 2015 -0400

Add minimal support for machines without hardware interrupts

Some Chromebooks (with Baytrail CPUs) apparently do not support
routing 

[Xen-devel] [PATCH for 4.6] VT-d: Create IOMMU mappings for RMRR regions if shared EPT is not being used

[Malcolm Crossley]

Add RMRR 1:1 IOMMU mappings to IOMMU page tables if EPT page table are not being
shared with the IOMMU.

This is a regression in behaviour versus Xen 4.5.

Signed-off-by: Malcolm Crossley malcolm.cross...@citrix.com
---
 xen/drivers/passthrough/vtd/iommu.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 836aed5..89de741 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1839,8 +1839,16 @@ static int rmrr_identity_mapping(struct domain *d, 
bool_t map,
 
 while ( base_pfn  end_pfn )
 {
-if ( clear_identity_p2m_entry(d, base_pfn) )
-ret = -ENXIO;
+if ( iommu_use_hap_pt(d) )
+{
+if ( clear_identity_p2m_entry(d, base_pfn) )
+ret = -ENXIO;
+}
+else
+{
+if ( intel_iommu_unmap_page(d, base_pfn) )
+ret = -ENXIO;
+}
 base_pfn++;
 }
 
@@ -1855,7 +1863,16 @@ static int rmrr_identity_mapping(struct domain *d, 
bool_t map,
 
 while ( base_pfn  end_pfn )
 {
-int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
+int err;
+if ( iommu_use_hap_pt(d) )
+{
+err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
+}
+else
+{
+err = intel_iommu_map_page(d, base_pfn, base_pfn,
+   IOMMUF_readable|IOMMUF_writable);
+}
 
 if ( err )
 return err;
-- 
1.7.12.4


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

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Andrew Cooper]

On 26/08/15 18:28, Konrad Rzeszutek Wilk wrote:
 On Wed, Aug 26, 2015 at 06:20:34PM +0100, Andrew Cooper wrote:
 On 26/08/15 18:15, Konrad Rzeszutek Wilk wrote:
 On Wed, Aug 26, 2015 at 05:19:39PM +0100, Malcolm Crossley wrote:
 On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:
 On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
 On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
 Hi everyone,
 I saw some people passingly mention this on the list before but just in
 case it has been missed, my serial is also being spammed with the 
 following
 printouts with both Xen 4.6 RC1 and the latest staging build:

 ...
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 33487d7000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
 (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
 2610742000, iommu reg = 82c000201000
 (XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
 ...

 I think this problem is caused by missing IOMMU mappings for the RMRR 
 regions
 if the domain does not have shared EPT enabled. This includes PV Dom 0.

 I have posted a patch to fix the issue:

 http://lists.xen.org/archives/html/xen-devel/2015-08/msg02090.html
 No dice. Still seeing the same problem :-(
 Does your BIOS provide suitable extra RMRR regions when AMT is in use? 
 IIRC, AMT uses the on-chip GPU as part of its VNC handling.

 (XEN)   - 0009a800 (usable)
 (XEN)  0009a800 - 000a (reserved)
 (XEN)  000e - 0010 (reserved)
 (XEN)  0010 - 2000 (usable)
 (XEN)  2000 - 2020 (reserved)
 (XEN)  2020 - 4000 (usable)
 (XEN)  4000 - 4020 (reserved)
 (XEN)  4020 - 9e856000 (usable)
 (XEN)  9e856000 - 9e85f000 (ACPI data)
 (XEN)  9e85f000 - 9e8aa000 (ACPI NVS)
 (XEN)  9e8aa000 - 9e8b2000 (usable)
 (XEN)  9e8b2000 - 9e9a5000 (reserved)
 (XEN)  9e9a5000 - 9e9a7000 (usable)
 (XEN)  9e9a7000 - 9ebc6000 (reserved)
 (XEN)  9ebc6000 - 9ebc7000 (usable)
 (XEN)  9ebc7000 - 9ebd7000 (reserved)
 (XEN)  9ebd7000 - 9ebf5000 (ACPI NVS)
 (XEN)  9ebf5000 - 9ec19000 (reserved)
 (XEN)  9ec19000 - 9ec5c000 (ACPI NVS)
 (XEN)  9ec5c000 - 9ee7c000 (reserved)
 (XEN)  9ee7c000 - 9f00 (usable)
 (XEN)  9f80 - bfa0 (reserved)
 (XEN)  fed1c000 - fed4 (reserved)
 (XEN)  ff00 - 0001 (reserved)
 (XEN)  0001 - 00043e60 (usable)
snip
 (XEN) [VT-D]dmar.c:809: Host address width 36

snip

 (XEN) [VT-D]dmar.c:823: found ACPI_DMAR_DRHD:
 (XEN) [VT-D]dmar.c:485:   dmaru-address = fed9
 (XEN) [VT-D]iommu.c:1149: drhd-address = fed9 iommu-reg = 
 82c000201000
 (XEN) [VT-D]iommu.c:1151: cap = c020e60262 ecap = f0101a
 (XEN) [VT-D]dmar.c:396:  endpoint: :00:02.0
 (XEN) [VT-D]dmar.c:823: found ACPI_DMAR_DRHD:
 (XEN) [VT-D]dmar.c:485:   dmaru-address = fed91000
 (XEN) [VT-D]iommu.c:1149: drhd-address = fed91000 iommu-reg = 
 82c000203000
 (XEN) [VT-D]iommu.c:1151: cap = c9008020660262 ecap = f0105a
 (XEN) [VT-D]dmar.c:410:  IOAPIC: :f0:1f.0
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.0
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.1
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.2
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.3
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.4
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.5
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.6
 (XEN) [VT-D]dmar.c:374:  MSI HPET: :f0:0f.7
 (XEN) [VT-D]dmar.c:499:   flags: INCLUDE_ALL
 (XEN) [VT-D]dmar.c:828: found ACPI_DMAR_RMRR:
 (XEN) [VT-D]dmar.c:396:  endpoint: :00:1d.0
 (XEN) [VT-D]dmar.c:396:  endpoint: :00:1a.0
 (XEN) [VT-D]dmar.c:694:   RMRR region: base_addr 9ebad000 end_address 9ebbbfff
 (XEN) [VT-D]dmar.c:828: found ACPI_DMAR_RMRR:
 (XEN) [VT-D]dmar.c:396:  endpoint: :00:02.0
 (XEN) [VT-D]dmar.c:694:   RMRR region: base_addr 9f80 end_address bf9f

 There  That is the device.

snip (although, that is a large RMRR...)
 (XEN) [VT-D]iommu.c:873: iommu_fault_status: Fault Overflow
 (XEN) [VT-D]iommu.c:875: iommu_fault_status: Primary Pending Fault
 (XEN) [VT-D]DMAR:[DMA Read] 

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Konrad Rzeszutek Wilk]

On Wed, Aug 26, 2015 at 05:19:39PM +0100, Malcolm Crossley wrote:
 On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:
  On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:
  On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
  Hi everyone,
  I saw some people passingly mention this on the list before but just in
  case it has been missed, my serial is also being spammed with the 
  following
  printouts with both Xen 4.6 RC1 and the latest staging build:
 
  ...
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  33487d7000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
  (XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
  2610742000, iommu reg = 82c000201000
  (XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
  ...
 
 
 
 I think this problem is caused by missing IOMMU mappings for the RMRR regions
 if the domain does not have shared EPT enabled. This includes PV Dom 0.
 
 I have posted a patch to fix the issue:
 
 http://lists.xen.org/archives/html/xen-devel/2015-08/msg02090.html

No dice. Still seeing the same problem :-(

 
 
 
  What's your platform? BDW? And how much memory is set to your guest OS?
  
  Is see this as well. But oddly enough - only when I use the AMT feature
  (normally I just use serial console on the machine).
  
  The platform is /DQ67SW, BIOS
  SWQ6710H.86A.0066.2012.1105.1504 11/05/2012
  
  There is no guest OS - this is initial domain. And I boot with 2GB:
   Released 0 page(s)
  
  Xen: [mem 0x-0x00099fff] usable
  Xen: [mem 0x0009a800-0x000f] reserved
  Xen: [mem 0x0010-0x1fff] usable
  Xen: [mem 0x2000-0x201f] reserved
  Xen: [mem 0x2020-0x3fff] usable
  Xen: [mem 0x4000-0x401f] reserved
  Xen: [mem 0x4020-0x80465fff] usable
  Xen: [mem 0x80466000-0x9e855fff] unusable
  Xen: [mem 0x9e856000-0x9e85efff] ACPI data
  Xen: [mem 0x9e85f000-0x9e8a9fff] ACPI NVS
  Xen: [mem 0x9e8aa000-0x9e8b1fff] unusable
  Xen: [mem 0x9e8b2000-0x9e9a4fff] reserved
  Xen: [mem 0x9e9a5000-0x9e9a6fff] unusable
  Xen: [mem 0x9e9a7000-0x9ebc5fff] reserved
  Xen: [mem 0x9ebc6000-0x9ebc6fff] unusable
  Xen: [mem 0x9ebc7000-0x9ebd6fff] reserved
  Xen: [mem 0x9ebd7000-0x9ebf4fff] ACPI NVS
  Xen: [mem 0x9ebf5000-0x9ec18fff] reserved
  Xen: [mem 0x9ec19000-0x9ec5bfff] ACPI NVS
  Xen: [mem 0x9ec5c000-0x9ee7bfff] reserved
  Xen: [mem 0x9ee7c000-0x9eff] unusable
  Xen: [mem 0x9f80-0xbf9f] reserved
  Xen: [mem 0xfec0-0xfec00fff] reserved
  Xen: [mem 0xfed1c000-0xfed3] reserved
  Xen: [mem 0xfed9-0xfed91fff] reserved
  Xen: [mem 0xfee0-0xfeef] reserved
  Xen: [mem 0xff00-0x] reserved
  Xen: [mem 0x0001-0x00043e5f] unusable
  
 
  Just at first glance to fault address, this seems be issued from some 
  known erratas on BDS and SKL.
  
  I am runnig v4.2-rc8.
 
  Thanks
  Tiejun
 
  The device in question is an integrated Intel graphics card:
 
  00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
  Processor Family Integrated Graphics Controller (rev 09)
  
  Same device..
 
 This is a sandy bridge device which doesn't support shared EPT for GPU device.
 
 
 
  The only way I found to stop the messages from making my serial connection
  useless was by assigning the device to xen-pciback.
 
 This will cause the GPU to be reset and the reset stopped the GPU accessing 
 the
 RMRR region.
 
 
  Cheers,
  Tamas
 
 
 
  ___
  Xen-devel mailing list
  Xen-devel@lists.xen.org
  http://lists.xen.org/xen-devel
 
 
  ___
  Xen-devel mailing list
  Xen-devel@lists.xen.org
  http://lists.xen.org/xen-devel
  
  ___
  Xen-devel mailing list
  Xen-devel@lists.xen.org
  http://lists.xen.org/xen-devel
  
 
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 

Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field ‘anonymous’

[Konrad Rzeszutek Wilk]

On Wed, Aug 26, 2015 at 01:32:54AM -0600, Jan Beulich wrote:
  On 25.08.15 at 21:54, konrad.w...@oracle.com wrote:
  On Tue, Aug 25, 2015 at 03:52:15PM -0400, Konrad Rzeszutek Wilk wrote:
  On Tue, Aug 25, 2015 at 06:41:06PM +0100, Andrew Cooper wrote:
   On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -238,7 +238,9 @@ struct domain *alloc_domain_struct(void)
 if ( unlikely(!bits) )
  bits = _domain_struct_bits();
 
+#ifndef LOCK_PROFILE
 BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
+#endif
 d = alloc_xenheap_pages(0, MEMF_bits(bits));
 if ( d != NULL )
 clear_page(d);
   
(not compile tested nor runtime tested)
   
   Either remove it locally for debugging, or use something like
  
  I forgot to mention that by removing it locally Xen ends up halting at:
  
  (XEN) Detected 3292.657 MHz processor.
 
 Sure - as Andrew said on irc, neither simply removing it nor replacing
 it by vmalloc() can actually work. At the very least you'd want the
 above to become

I ended up doing:

From 52548151b6db3724fdafd005f52fc1aaefa65eff Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 25 Aug 2015 21:25:54 -0400
Subject: [PATCH] x86: Allow 'struct domain' to expand past PAGE_SIZE

If we are building with lock profilling enabled - as that
expands the spinlock structures considerably.

Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 xen/arch/x86/domain.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 045f6ff..7df58d8 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -237,9 +237,10 @@ struct domain *alloc_domain_struct(void)
 
 if ( unlikely(!bits) )
  bits = _domain_struct_bits();
-
+#ifndef LOCK_PROFILE
 BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
-d = alloc_xenheap_pages(0, MEMF_bits(bits));
+#endif
+d = alloc_xenheap_pages(get_order_from_bytes(sizeof(*d)), MEMF_bits(bits));
 if ( d != NULL )
 clear_page(d);
 return d;
@@ -261,7 +262,7 @@ struct vcpu *alloc_vcpu_struct(void)
  * structure must satisfy this restriction. Thus we specify MEMF_bits(32).
  */
 BUILD_BUG_ON(sizeof(*v)  PAGE_SIZE);
-v = alloc_xenheap_pages(0, MEMF_bits(32));
+v = alloc_xenheap_pages(get_order_from_bytes(sizeof(*v)), MEMF_bits(32));
 if ( v != NULL )
 clear_page(v);
 return v;
-- 
2.1.0


which made it compile and boot. However the moment I ran xenlockprof I got
this nice splash:

(XEN) CPU:0
(XEN) RIP:e008:[82d08012e0fa] spinlocerate+0x5b/0x96
(XEN) RFLAGS: 00010202   CONTEXT: hypervisor (d0v0)
(XEN) rax: 83009e6f7e40   rbx: c2c2c2c2c2c2c2c2   rcx: 83009e6f7d48
(XEN) rdx: 003d   rsi: 0001   rdi: c2c2c2c2c2c2c2c2
(XEN) rbp: 83009e6f7d38   rsp: 83009e6f7cf8   r8:  deadbeef
(XEN) r9:  deadbeef   r10: 82d0802542a0   r11: 0286
(XEN) r12: 830413381078   r13: 0001   r14: 82d08012da37
(XEN) r15: 83009e6f7d48   cr0: 80050033   cr4: 000426e0
(XEN) cr3: 000411303000   cr2: 7f42d4a6e9a0
(XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
(XEN) Xen stack trace from rsp=83009e6f7cf8:
(XEN)00411fc1 82d080327ef0 8304 83009e6f7e40
(XEN)7f42d4ea4004 83009e6f7f18 83009e6f7f18 82d08031be00
(XEN)83009e6f7d68 82d08012e1e5 83009e6f7e40 82d0
(XEN)  83009e6f7ef8 82d08012f3fa
(XEN)83009e6f7d98 83042c186000 83009e8b 83009e6f7d98
(XEN)83009e6f7f18 83009e6f7f18 83009e6f7f18 83009e6f7f18
(XEN)83009e6f7f18 83009e6f7f18 83009e6f7f18 
(XEN)83009e6f7eb0 83009e6f7ea8 88008020ab10 00411fc1
(XEN) 8307 00037ff0 820040008000
(XEN)83009e8b 800402e3d067 00040002 83009e6f7f18
(XEN)000c000f 0002 7ffd003e 
(XEN) 7f42d4a5a8e8 010eb050 
(XEN)7ffd86253bd0 004008f0 7ffd86253cb0 7f42d4ca07c5
(XEN)010eb050 7f42d47ae695 7ffd86253b68 7ffd86253b68
(XEN)010eb050 0033 83009e6f7ed8 83009e8b
(XEN)880068795900 88007395dd88 0003 7ffd86253900
(XEN)7cff619080c7 82d0802396d2 8100146a 0023
(XEN)  7ffd86253cb0 004008f0
(XEN)8800686d3e68 7ffd86253900 0286 7ffd862539b0
(XEN)7ffd86253b68 7f42d4c95256 0023 8100146a
(XEN) Xen call trace:
(XEN)[82d08012e0fa] 

[Xen-devel] [PATCH V3] xen/x86: Clean up vm_event-related code in asm-x86/domain.h

[Razvan Cojocaru]

As suggested by Jan Beulich, moved struct monitor_write_data from
struct arch_domain to struct arch_vcpu, as well as moving all
vm_event-related data from asm-x86/domain.h to struct vm_event,
and allocating it dynamically only when needed.

Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Acked-by: Tamas K Lengyel ta...@tklengyel.com
Reviewed-by: Andrew Cooper andrew.coop...@citrix.com

---
Changes since V2:
 - Renamed struct vm_event to struct arch_vm_event.
 - Rebased the patch to apply cleanly on staging.
---
 xen/arch/x86/domain.c  |   10 ++
 xen/arch/x86/hvm/emulate.c |7 ---
 xen/arch/x86/hvm/hvm.c |   42 
 xen/arch/x86/mm/p2m.c  |   25 
 xen/arch/x86/vm_event.c|   26 +++--
 xen/include/asm-x86/domain.h   |   13 +
 xen/include/asm-x86/vm_event.h |   12 
 7 files changed, 60 insertions(+), 75 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 045f6ff..58e173e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -424,9 +424,6 @@ int vcpu_initialise(struct vcpu *v)
 
 v-arch.flags = TF_kernel_mode;
 
-/* By default, do not emulate */
-v-arch.vm_event.emulate_flags = 0;
-
 rc = mapcache_vcpu_init(v);
 if ( rc )
 return rc;
@@ -511,8 +508,8 @@ int vcpu_initialise(struct vcpu *v)
 
 void vcpu_destroy(struct vcpu *v)
 {
-xfree(v-arch.vm_event.emul_read_data);
-v-arch.vm_event.emul_read_data = NULL;
+xfree(v-arch.vm_event);
+v-arch.vm_event = NULL;
 
 if ( is_pv_32bit_vcpu(v) )
 {
@@ -668,9 +665,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 
 void arch_domain_destroy(struct domain *d)
 {
-vfree(d-arch.event_write_data);
-d-arch.event_write_data = NULL;
-
 if ( has_hvm_container_domain(d) )
 hvm_domain_destroy(d);
 
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 30acb78..5934c72 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -22,6 +22,7 @@
 #include asm/hvm/trace.h
 #include asm/hvm/support.h
 #include asm/hvm/svm/svm.h
+#include asm/vm_event.h
 
 static void hvmtrace_io_assist(const ioreq_t *p)
 {
@@ -71,12 +72,12 @@ static int set_context_data(void *buffer, unsigned int size)
 {
 struct vcpu *curr = current;
 
-if ( curr-arch.vm_event.emul_read_data )
+if ( curr-arch.vm_event )
 {
 unsigned int safe_size =
-min(size, curr-arch.vm_event.emul_read_data-size);
+min(size, curr-arch.vm_event-emul_read_data.size);
 
-memcpy(buffer, curr-arch.vm_event.emul_read_data-data, safe_size);
+memcpy(buffer, curr-arch.vm_event-emul_read_data.data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 615fa89..67bbb92 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -63,6 +63,7 @@
 #include asm/altp2m.h
 #include asm/mtrr.h
 #include asm/apic.h
+#include asm/vm_event.h
 #include public/sched.h
 #include public/hvm/ioreq.h
 #include public/version.h
@@ -541,9 +542,9 @@ void hvm_do_resume(struct vcpu *v)
 break;
 }
 
-if ( unlikely(d-arch.event_write_data) )
+if ( unlikely(v-arch.vm_event) )
 {
-struct monitor_write_data *w = d-arch.event_write_data[v-vcpu_id];
+struct monitor_write_data *w = v-arch.vm_event-write_data;
 
 if ( w-do_write.msr )
 {
@@ -3337,7 +3338,6 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 struct domain *d = v-domain;
 unsigned long gfn, old_value = v-arch.hvm_vcpu.guest_cr[0];
 struct page_info *page;
-struct arch_domain *currad = v-domain-arch;
 
 HVM_DBG_LOG(DBG_LEVEL_VMMU, Update CR0 value = %lx, value);
 
@@ -3367,16 +3367,17 @@ int hvm_set_cr0(unsigned long value, bool_t may_defer)
 goto gpf;
 }
 
-if ( may_defer  unlikely(currad-monitor.write_ctrlreg_enabled 
+if ( may_defer  unlikely(v-domain-arch.monitor.write_ctrlreg_enabled 
monitor_ctrlreg_bitmask(VM_EVENT_X86_CR0)) )
 {
-ASSERT(currad-event_write_data != NULL);
+ASSERT(v-arch.vm_event);
 
 if ( hvm_event_crX(CR0, value, old_value) )
 {
 /* The actual write will occur in hvm_do_resume(), if permitted. */
-currad-event_write_data[v-vcpu_id].do_write.cr0 = 1;
-currad-event_write_data[v-vcpu_id].cr0 = value;
+v-arch.vm_event-write_data.do_write.cr0 = 1;
+v-arch.vm_event-write_data.cr0 = value;
+
 
 return X86EMUL_OKAY;
 }
@@ -3468,18 +3469,18 @@ int hvm_set_cr3(unsigned long value, bool_t may_defer)
 struct vcpu *v = current;
 struct page_info *page;
 unsigned long old = v-arch.hvm_vcpu.guest_cr[3];
-struct arch_domain 

[Xen-devel] [DOCS DAY] [PATCH for-4.6 0/5] Cleanup of docs spread throughout the tree

[Andrew Cooper]

After this series, I don't believe there are any docs remaining out of
the docs/ subtree.

The three manpages moved have been converted from ?roff to POD to match
all our other manpages

Andrew Cooper (5):
  docs: Move misc README's into docs/misc/
  docs: Move xentop.1 to docs/man/xentop.pod.1
  docs: Move xentrace_format.1 to docs/man/xentrace_format.pod.1
  docs: Support for generating man(8) pages
  docs: Move xentrace.8 to docs/man/xentrace.pod.8

 .gitignore   |1 +
 docs/Makefile|   97 ++
 docs/man/xentop.pod.1|  111 +
 docs/man/xentrace.pod.8  |  166 ++
 docs/man/xentrace_format.pod.1   |   46 +++
 docs/misc/stubdom.txt|   93 +
 docs/misc/xenmon.txt |  114 ++
 stubdom/Makefile |6 +-
 stubdom/README   |   93 -
 tools/xenmon/Makefile|2 -
 tools/xenmon/README  |  114 --
 tools/xenstat/xentop/Makefile|4 +-
 tools/xenstat/xentop/xentop.1|  103 ---
 tools/xentrace/Makefile  |6 --
 tools/xentrace/xentrace.8|  164 -
 tools/xentrace/xentrace_format.1 |   44 --
 16 files changed, 577 insertions(+), 587 deletions(-)
 create mode 100644 docs/man/xentop.pod.1
 create mode 100644 docs/man/xentrace.pod.8
 create mode 100644 docs/man/xentrace_format.pod.1
 create mode 100644 docs/misc/stubdom.txt
 create mode 100644 docs/misc/xenmon.txt
 delete mode 100644 stubdom/README
 delete mode 100644 tools/xenmon/README
 delete mode 100644 tools/xenstat/xentop/xentop.1
 delete mode 100644 tools/xentrace/xentrace.8
 delete mode 100644 tools/xentrace/xentrace_format.1

-- 
1.7.10.4


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

[Xen-devel] [PATCH for-4.6 3/5] docs: Move xentrace_format.1 to docs/man/xentrace_format.pod.1

[Andrew Cooper]

And transform to POD to match our other manpages.

The content is identical (other than one correction), although the
layout differs slightly with certain indentation.

As a correction, remove the reference to xentrace_cpusplit(1) which was
removed in c/s 9b9ca98b6ab16, more than 10 years ago!

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
 .../man/xentrace_format.pod.1  |   46 ++--
 tools/xentrace/Makefile|3 --
 2 files changed, 24 insertions(+), 25 deletions(-)
 rename tools/xentrace/xentrace_format.1 = docs/man/xentrace_format.pod.1 (55%)

diff --git a/tools/xentrace/xentrace_format.1 b/docs/man/xentrace_format.pod.1
similarity index 55%
rename from tools/xentrace/xentrace_format.1
rename to docs/man/xentrace_format.pod.1
index 374ec6d..e05479a 100644
--- a/tools/xentrace/xentrace_format.1
+++ b/docs/man/xentrace_format.pod.1
@@ -1,20 +1,20 @@
-.TH XENTRACE_FORMAT 1 11 May 2004 Xen domain 0 utils
-.SH NAME
-xentrace_format \- pretty-print Xen trace data
-.SH SYNOPSIS
-.B xentrace_format
-[
-.I DEFS-FILE
-]
-.SH DESCRIPTION
-.B xentrace_format
-parses trace data in \fBxentrace\fP binary format from standard input
-and reformats it according to the rules in a file of definitions
-(\fIDEFS-FILE\fP), printing to standard output.
-
-The rules in \fIDEFS-FILE\fP should have the format shown below:
-
-\fIevent_id\fP \fIwhitespace\fP \fIformat\fP
+=head1 NAME
+
+xentrace_format - pretty-print Xen trace data
+
+=head1 SYNOPSIS
+
+Bxentrace_format [ IDEFS-FILE ]
+
+=head1 DESCRIPTION
+
+Bxentrace_format parses trace data in Bxentrace binary format from
+standard input and reformats it according to the rules in a file of
+definitions (IDEFS-FILE), printing to standard output.
+
+The rules in IDEFS-FILE should have the format shown below:
+
+Ievent_id Iwhitespace Iformat
 
 Each rule should start on a new line.
 
@@ -34,11 +34,13 @@ in the file tools/xentrace/formats in the Xen source tree.
 
 Depending on your system and the rate at which trace data is produced,
 this script may not be able to keep up with the output of
-\fBxentrace\fP if it is piped directly.  In these circumstances you
-should have \fBxentrace\fP output to a file for processing off-line.
+Bxentrace if it is piped directly.  In these circumstances you
+should have Bxentrace output to a file for processing off-line.
+
+=head1 AUTHOR
 
-.SH AUTHOR
 Mark A. Williamson mark.a.william...@intel.com
 
-.SH SEE ALSO
-xentrace(8), xentrace_cpusplit(1)
+=head1 SEE ALSO
+
+xentrace(8)
diff --git a/tools/xentrace/Makefile b/tools/xentrace/Makefile
index 2f57bda..41caccb 100644
--- a/tools/xentrace/Makefile
+++ b/tools/xentrace/Makefile
@@ -11,7 +11,6 @@ BIN  = $(BIN-y)
 SBIN = xentrace xentrace_setsize
 LIBBIN   = xenctx
 SCRIPTS  = xentrace_format
-MAN1 = $(wildcard *.1)
 MAN8 = $(wildcard *.8)
 
 .PHONY: all
@@ -25,7 +24,6 @@ install: build
$(INSTALL_DIR) $(DESTDIR)$(bindir)
$(INSTALL_DIR) $(DESTDIR)$(sbindir)
[ -z $(LIBBIN) ] || $(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
-   $(INSTALL_DIR) $(DESTDIR)$(MAN1DIR)
$(INSTALL_DIR) $(DESTDIR)$(MAN8DIR)
 ifneq ($(BIN),)
$(INSTALL_PROG) $(BIN) $(DESTDIR)$(bindir)
@@ -33,7 +31,6 @@ endif
$(INSTALL_PROG) $(SBIN) $(DESTDIR)$(sbindir)
$(INSTALL_PYTHON_PROG) $(SCRIPTS) $(DESTDIR)$(bindir)
[ -z $(LIBBIN) ] || $(INSTALL_PROG) $(LIBBIN) $(DESTDIR)$(LIBEXEC_BIN)
-   $(INSTALL_DATA) $(MAN1) $(DESTDIR)$(MAN1DIR)
$(INSTALL_DATA) $(MAN8) $(DESTDIR)$(MAN8DIR)
 
 .PHONY: clean
-- 
1.7.10.4


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

[Xen-devel] [PATCH for-4.6 2/5] docs: Move xentop.1 to docs/man/xentop.pod.1

[Andrew Cooper]

And transform to POD to match our other manpages.

The content is identical, although the layout differs slightly with
certain indentation.

In addition, adjust the MAN{1,5}SRC-y `find` runes to be more general.

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
 docs/Makefile |6 +--
 docs/man/xentop.pod.1 |  111 +
 tools/xenstat/xentop/Makefile |4 +-
 tools/xenstat/xentop/xentop.1 |  103 --
 4 files changed, 114 insertions(+), 110 deletions(-)
 create mode 100644 docs/man/xentop.pod.1
 delete mode 100644 tools/xenstat/xentop/xentop.1

diff --git a/docs/Makefile b/docs/Makefile
index 272292c..ef3340c 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -7,10 +7,8 @@ VERSION:= $(shell $(MAKE) -C $(XEN_ROOT)/xen 
--no-print-directory xenversion)
 DOC_ARCHES  := arm x86_32 x86_64
 
 # Documentation sources to build
-MAN1SRC-y += $(sort $(shell find man -name 'xl*.pod.1' -print))
-MAN1SRC-y += $(sort $(shell find man -name 'xenstore*.pod.1' -print))
-
-MAN5SRC-y := $(sort $(shell find man -name 'xl*.pod.5' -print))
+MAN1SRC-y := $(sort $(shell find man/ -name '*.pod.1' -print))
+MAN5SRC-y := $(sort $(shell find man/ -name '*.pod.5' -print))
 
 MARKDOWNSRC-y := $(sort $(shell find misc -name '*.markdown' -print))
 
diff --git a/docs/man/xentop.pod.1 b/docs/man/xentop.pod.1
new file mode 100644
index 000..1d0eb50
--- /dev/null
+++ b/docs/man/xentop.pod.1
@@ -0,0 +1,111 @@
+=head1 NAME
+
+xentop - displays real-time information about a Xen system and domains
+
+=head1 SYNOPSIS
+
+Bxentop [B-h] [B-V] [B-dSECONDS] [B-n] [B-r] [B-v] [B-f]
+[B-b] [B-iITERATIONS]
+
+=head1 DESCRIPTION
+
+Bxentop displays information about the Xen system and domains, in a
+continually-updating manner.  Command-line options and interactive commands
+can change the detail and format of the information displayed by Bxentop.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B-h, B--help
+
+display help and exit
+
+=item B-V, B--version
+
+output version information and exit
+
+=item B-d, B--delay=ISECONDS
+
+seconds between updates (default 3)
+
+=item B-n, B--networks
+
+output network information
+
+=item B-x, B--vbds
+
+output vbd block device data
+
+=item B-r, B--repeat-header
+
+repeat table header before each domain
+
+=item B-v, B--vcpus
+
+output VCPU data
+
+=item B-f, B--full-name
+
+output the full domain name (not truncated)
+
+=item B-b, B--batch
+
+output data in batch mode (to stdout)
+
+=item B-i, B--iterations=IITERATIONS
+
+maximum number of iterations xentop should produce before ending
+
+=back
+
+=head1 INTERACTIVE COMMANDS
+
+All interactive commands are case-insensitive.
+
+=over 4
+
+=item BD
+
+set delay between updates
+
+=item BN
+
+toggle display of network information
+
+=item BQ, BEsc
+
+quit
+
+=item BR
+
+toggle table header before each domain
+
+=item BS
+
+cycle sort order
+
+=item BV
+
+toggle display of VCPU information
+
+=item BArrows
+
+scroll domain display
+
+=back
+
+=head1 AUTHORS
+
+Written by Judy Fischbach, David Hendricks, and Josh Triplett
+
+=head1 REPORTING BUGS
+
+Report bugs to xen-devel@lists.xen.org.
+
+=head1 COPYRIGHT
+
+Copyright 2005  International Business Machines  Corp
+
+This is free software; see the source for copying conditions.  There is NO
+warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
diff --git a/tools/xenstat/xentop/Makefile b/tools/xenstat/xentop/Makefile
index e67c9ab..1cc393f 100644
--- a/tools/xenstat/xentop/Makefile
+++ b/tools/xenstat/xentop/Makefile
@@ -30,11 +30,9 @@ LDFLAGS += $(APPEND_LDFLAGS)
 all: xentop
 
 .PHONY: install
-install: xentop xentop.1
+install: xentop
$(INSTALL_DIR) $(DESTDIR)$(sbindir)
$(INSTALL_PROG) xentop $(DESTDIR)$(sbindir)/xentop
-   $(INSTALL_DIR) $(DESTDIR)$(MAN1DIR)
-   $(INSTALL_DATA) xentop.1 $(DESTDIR)$(MAN1DIR)/xentop.1
 
 endif
 
diff --git a/tools/xenstat/xentop/xentop.1 b/tools/xenstat/xentop/xentop.1
deleted file mode 100644
index 82c000e..000
--- a/tools/xenstat/xentop/xentop.1
+++ /dev/null
@@ -1,103 +0,0 @@
-.\ Copyright (C) International Business Machines  Corp., 2005
-.\ Author: Josh Triplett j...@kernel.org
-.\
-.\ 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; under version 2 of the License.
-.\
-.\ This program is distributed in the hope that it will be useful,
-.\ but WITHOUT ANY WARRANTY; without even the implied warranty of
-.\ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-.\ GNU General Public License for more details.
-.\
-.\ You should have received a copy of the GNU General Public License
-.\ along with this program; If not, see http://www.gnu.org/licenses/.
-.TH xentop 

[Xen-devel] [PATCH for-4.6 1/5] docs: Move misc README's into docs/misc/

[Andrew Cooper]

To live with the other documentation.

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
 stubdom/README = docs/misc/stubdom.txt |0
 tools/xenmon/README = docs/misc/xenmon.txt |0
 stubdom/Makefile|6 +-
 tools/xenmon/Makefile   |2 --
 4 files changed, 1 insertion(+), 7 deletions(-)
 rename stubdom/README = docs/misc/stubdom.txt (100%)
 rename tools/xenmon/README = docs/misc/xenmon.txt (100%)

diff --git a/stubdom/README b/docs/misc/stubdom.txt
similarity index 100%
rename from stubdom/README
rename to docs/misc/stubdom.txt
diff --git a/tools/xenmon/README b/docs/misc/xenmon.txt
similarity index 100%
rename from tools/xenmon/README
rename to docs/misc/xenmon.txt
diff --git a/stubdom/Makefile b/stubdom/Makefile
index faa7c21..e1359cf 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -463,15 +463,11 @@ xenstore-stubdom: mini-os-$(XEN_TARGET_ARCH)-xenstore 
libxc xenstore
 #
 
 ifeq ($(STUBDOM_SUPPORTED),1)
-install: $(STUBDOMPATH) install-readme $(STUBDOM_INSTALL)
+install: $(STUBDOMPATH) $(STUBDOM_INSTALL)
 else
 install: $(STUBDOMPATH)
 endif
 
-install-readme:
-   $(INSTALL_DIR) $(DESTDIR)$(docdir)
-   $(INSTALL_DATA) README $(DESTDIR)$(docdir)/README.stubdom
-
 install-ioemu: ioemu-stubdom
$(INSTALL_DIR) $(DESTDIR)$(LIBEXEC_BIN)
$(INSTALL_PROG) stubdom-dm $(DESTDIR)$(LIBEXEC_BIN)
diff --git a/tools/xenmon/Makefile b/tools/xenmon/Makefile
index 5095682..20ea100 100644
--- a/tools/xenmon/Makefile
+++ b/tools/xenmon/Makefile
@@ -31,8 +31,6 @@ install: build
$(INSTALL_PROG) xenbaked $(DESTDIR)$(sbindir)/xenbaked
$(INSTALL_PROG) xentrace_setmask  $(DESTDIR)$(sbindir)/xentrace_setmask
$(INSTALL_PROG) xenmon.py  $(DESTDIR)$(sbindir)/xenmon.py
-   $(INSTALL_DIR) $(DESTDIR)$(docdir)
-   $(INSTALL_DATA) README $(DESTDIR)$(docdir)/README.xenmon
 
 .PHONY: clean
 clean:
-- 
1.7.10.4


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

[Xen-devel] [PATCH for-4.6 5/5] docs: Move xentrace.8 to docs/man/xentrace.pod.8

[Andrew Cooper]

And transform to POD to match our other manpages.

The content is identical, although the formatting was altered slightly
to conform to more usual manpage layout.

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
 .../xentrace/xentrace.8 = docs/man/xentrace.pod.8 |  160 ++--
 tools/xentrace/Makefile|3 -
 2 files changed, 81 insertions(+), 82 deletions(-)
 rename tools/xentrace/xentrace.8 = docs/man/xentrace.pod.8 (63%)

diff --git a/tools/xentrace/xentrace.8 b/docs/man/xentrace.pod.8
similarity index 63%
rename from tools/xentrace/xentrace.8
rename to docs/man/xentrace.pod.8
index 7b3172b..69aef05 100644
--- a/tools/xentrace/xentrace.8
+++ b/docs/man/xentrace.pod.8
@@ -1,92 +1,93 @@
-.TH XENTRACE 8 22 February 2007 Xen domain 0 utils
-.SH NAME
-xentrace \- capture Xen trace buffer data
-.SH SYNOPSIS
-.B xentrace
-[
-.I OPTIONS
-] [
-.I FILE
-]
-.SH DESCRIPTION
-.B xentrace
-is used to capture trace buffer data from Xen.  The data is
+=head1 NAME
+
+xentrace - capture Xen trace buffer data
+
+=head1 SYNOPSIS
+
+Bxentrace [ IOPTIONS ] [ IFILE ]
+
+=head1 DESCRIPTION
+
+Bxentrace is used to capture trace buffer data from Xen.  The data is
 output in the following binary format (host endian):
-.PP
+
 CPU(uint) TSC(u64) EVENT(u32) D1 D2 D3 D4 D5 (all u32)
-.PP
+
 Where CPU is the processor number, TSC is the record's timestamp
 (the value of the CPU cycle counter), EVENT is the event ID and
 D1...D5 are the trace data.
 
 Data is dumped onto the standard output (which must not be a TTY) or a
-\fIFILE\fP specified on the command line.
+IFILE specified on the command line.
 
 The output should be parsed using the tool xentrace_format, which can
 produce human-readable output in ASCII format.
 
 
-.SS Options
-.TP
-.B -t, --log-thresh=l
-set the threshold number, l, of new records required to trigger a write of
+=head1 OPTIONS
+
+=over 4
+
+=item B-t Il, B--log-thresh=Il
+
+set the threshold number, Il, of new records required to trigger a write of
 all new records to the output
-.TP
-.B -s, --poll-sleep=p
-set the time, p, (in milliseconds) to sleep between polling the buffers
+
+=item B-s Ip, B--poll-sleep=Ip
+
+set the time, Ip, (in milliseconds) to sleep between polling the buffers
 for new data.
-.TP
-.B -c, --cpu-mask=[\fIc\fP|\fICPU-LIST\fP|\fIall\fP]
+
+=item B-c [Ic|ICPU-LIST|Iall], B--cpu-mask=[Ic|ICPU-LIST|Iall]
+
 This can be: a hex value (of the form 0x...), or a set of cpu
-ranges as described below, or the string \fIall\fP. Hex values are limited
+ranges as described below, or the string Iall. Hex values are limited
 to 32 bits. If not specified, the cpu-mask as set during bootup will be
-constructed. If using the \fICPU-LIST\fP it expects decimal numbers, which
+constructed. If using the ICPU-LIST it expects decimal numbers, which
 may be specified as follows:
 
-.RS 4
-.ie n .IP 0-3 4
-.el .IP ``0-3'' 4
-.IX Item 0-3
-Trace only on CPUs 0 through 3
-.ie n .IP 0,2,5-7 4
-.el .IP ``0,2,5-7'' 4
-.IX Item 0,2,5-7
-Trace only on CPUs 0, 2, and 5 through 7.
-.ie n .IP -3 4
-.el .IP ``-3'' 4
-.IX Item -3
-Trace only on CPUs 0 through 3
-.ie n .IP -3,7 4
-.el .IP ``-3,7'' 4
-.IX Item -3,7
-Trace only on CPUs 0 through 3 and 7
-.ie n .IP 3- 4
-.el .IP ``3-'' 4
-.IX Item -3-
-Trace only on CPUs 3 up to maximum numbers of CPUs the host has.
-.RE
-.Sp
-
-If using \fIall\fP it will use all of the CPUs the host has.
-.TP
-.B -e, --evt-mask=e
+  0-3
+  Trace only on CPUs 0 through 3
+
+  0,2,5-7
+  Trace only on CPUs 0, 2, and 5 through 7
+
+  -3
+  Trace only on CPUs 0 through 3
+
+  -3,7
+  Trace only on CPUs 0 through 3 and 7
+
+  3-
+  Trace only on CPUs 3 up to maximum numbers of CPUs the host has
+
+If using Iall it will use all of the CPUs the host has.
+
+=item B-e Imask, B--evt-mask=Imask
+
 set event capture mask. If not specified the TRC_ALL will be used.
-.TP
-.B -?, --help
+
+=item B-?, B--help
+
 Give this help list
-.TP
-.B --usage
+
+=item B--usage
+
 Give a short usage message
-.TP
-.B -V, --version
+
+=item B-V, B--version
+
 Print program version
 
-.SS Event Classes (Masks)
+=back
+
+=head2 Event Classes (Masks)
+
 The following event classes (masks) can be used to filter the events being
 gathered by xentrace:
-.PP
-\fIID\fP  \fIDescription\fP
-.PP
+
+ID  Description
+
 0x0001f000  TRC_GEN
 0x0002f000  TRC_SCHED
 0x0004f000  TRC_DOM0OP
@@ -95,22 +96,23 @@ gathered by xentrace:
 0xf000  TRC_ALL
 
 
-.SS Event Subclasses (More Masks)
+=head2 Event Subclasses (More Masks)
+
 The following event subclasses (masks) can also be used to filter the events 
being
 gathered by xentrace:
-.PP
-\fIID\fP  \fIDescription\fP
-.PP
+
+ID  

[Xen-devel] [PATCH for-4.6 4/5] docs: Support for generating man(8) pages

[Andrew Cooper]

The manpage rules are very repetative, because of the section number being
present in the filenames.

Instead of adding another set of 3 rules, switch to using a metarule to
automate the repetative action.  New rules for different manpage sections can
be added simply by extending the $(foreach)

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
CC: Ian Campbell ian.campb...@citrix.com
CC: Ian Jackson ian.jack...@eu.citrix.com
CC: Wei Liu wei.l...@citrix.com
---
 .gitignore|1 +
 docs/Makefile |   91 ++---
 2 files changed, 43 insertions(+), 49 deletions(-)

diff --git a/.gitignore b/.gitignore
index dafa3c4..9ead7c4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -43,6 +43,7 @@ dist/*
 docs/html/
 docs/man1/
 docs/man5/
+docs/man8/
 docs/pdf/
 docs/txt/
 extras/mini-os
diff --git a/docs/Makefile b/docs/Makefile
index ef3340c..3d77913 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -9,6 +9,7 @@ DOC_ARCHES  := arm x86_32 x86_64
 # Documentation sources to build
 MAN1SRC-y := $(sort $(shell find man/ -name '*.pod.1' -print))
 MAN5SRC-y := $(sort $(shell find man/ -name '*.pod.5' -print))
+MAN8SRC-y := $(sort $(shell find man/ -name '*.pod.8' -print))
 
 MARKDOWNSRC-y := $(sort $(shell find misc -name '*.markdown' -print))
 
@@ -19,17 +20,20 @@ PANDOCSRC-y := $(sort $(shell find specs -name '*.pandoc' 
-print))
 # Documentation targets
 DOC_MAN1 := $(patsubst man/%.pod.1,man1/%.1,$(MAN1SRC-y))
 DOC_MAN5 := $(patsubst man/%.pod.5,man5/%.5,$(MAN5SRC-y))
+DOC_MAN8 := $(patsubst man/%.pod.8,man8/%.8,$(MAN8SRC-y))
 DOC_HTML := $(patsubst %.markdown,html/%.html,$(MARKDOWNSRC-y)) \
 $(patsubst %.pandoc,html/%.html,$(PANDOCSRC-y)) \
 $(patsubst man/%.pod.1,html/man/%.1.html,$(MAN1SRC-y)) \
 $(patsubst man/%.pod.5,html/man/%.5.html,$(MAN5SRC-y)) \
+$(patsubst man/%.pod.8,html/man/%.8.html,$(MAN8SRC-y)) \
 $(patsubst %.txt,html/%.txt,$(TXTSRC-y)) \
 $(patsubst %,html/hypercall/%/index.html,$(DOC_ARCHES))
 DOC_TXT  := $(patsubst %.txt,txt/%.txt,$(TXTSRC-y)) \
 $(patsubst %.markdown,txt/%.txt,$(MARKDOWNSRC-y)) \
 $(patsubst %.pandoc,txt/%.txt,$(PANDOCSRC-y)) \
 $(patsubst man/%.pod.1,txt/man/%.1.txt,$(MAN1SRC-y)) \
-$(patsubst man/%.pod.5,txt/man/%.5.txt,$(MAN5SRC-y))
+$(patsubst man/%.pod.5,txt/man/%.5.txt,$(MAN5SRC-y)) \
+$(patsubst man/%.pod.8,txt/man/%.8.txt,$(MAN8SRC-y))
 DOC_PDF  := $(patsubst %.markdown,pdf/%.pdf,$(MARKDOWNSRC-y)) \
 $(patsubst %.pandoc,pdf/%.pdf,$(PANDOCSRC-y))
 
@@ -55,7 +59,7 @@ else
 endif
 
 .PHONY: man-pages
-man-pages: $(DOC_MAN1) $(DOC_MAN5)
+man-pages: $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN8)
 
 .PHONY: pdf
 pdf: $(DOC_PDF)
@@ -75,6 +79,42 @@ distclean: clean
autom4te.cache
 
 # Top level install targets
+
+# Metarules for generating manpages.  Run with $(1) substitued for section
+define GENERATE_MANPAGE_RULES
+
+# Real manpages
+man$(1)/%.$(1): man/%.pod.$(1) Makefile
+ifneq ($(POD2MAN),)
+   @$(INSTALL_DIR) $$(@D)
+   $(POD2MAN) --release=$(VERSION) --name=$$* -s $(1) -c Xen $$ $$@
+else
+   @echo pod2man not installed; skipping $$@
+endif
+
+# HTML manpages
+html/man/%.$(1).html: man/%.pod.$(1) Makefile
+ifneq ($(POD2HTML),)
+   @$(INSTALL_DIR) $$(@D)
+   $(POD2HTML) --infile=$$ --outfile=$$@
+else
+   @echo pod2html not installed; skipping $$@
+endif
+
+# Text manpages
+txt/man/%.$(1).txt: man/%.pod.$(1) Makefile
+ifneq ($(POD2TEXT),)
+   @$(INSTALL_DIR) $$(@D)
+   $(POD2TEXT) $$ $$@
+else
+   @echo pod2text not installed; skipping $$@
+endif
+
+endef
+
+# Generate manpage rules for each section
+$(foreach i,1 5 8,$(eval $(call GENERATE_MANPAGE_RULES,$(i
+
 .PHONY: install-man-pages
 install-man-pages: man-pages
$(INSTALL_DIR) $(DESTDIR)$(mandir)
@@ -90,22 +130,6 @@ install-html: html txt figs
 install: install-man-pages install-html
 
 # Individual file build targets
-man1/%.1: man/%.pod.1 Makefile
-ifneq ($(POD2MAN),)
-   @$(INSTALL_DIR) $(@D)
-   $(POD2MAN) --release=$(VERSION) --name=$* -s 1 -c Xen $ $@
-else
-   @echo pod2man not installed; skipping $@
-endif
-
-man5/%.5: man/%.pod.5 Makefile
-ifneq ($(POD2MAN),)
-   @$(INSTALL_DIR) $(@D)
-   $(POD2MAN) --release=$(VERSION) --name=$* -s 5 -c Xen $ $@
-else
-   @echo pod2man not installed; skipping $@
-endif
-
 html/index.html: $(DOC_HTML) $(CURDIR)/gen-html-index INDEX
$(PERL) -w -- $(CURDIR)/gen-html-index -i INDEX html $(DOC_HTML)
 
@@ -121,21 +145,6 @@ html/%.txt: %.txt
@$(INSTALL_DIR) $(@D)
$(INSTALL_DATA) $ $@
 
-html/man/%.1.html: man/%.pod.1 Makefile
-ifneq ($(POD2HTML),)
-   @$(INSTALL_DIR) $(@D)
-   $(POD2HTML) --infile=$ --outfile=$@
-else
-   @echo pod2html not installed; skipping $@
-endif
-
-html/man/%.5.html: man/%.pod.5 Makefile
-ifneq ($(POD2HTML),)
-   @$(INSTALL_DIR) 

Re: [Xen-devel] [PATCH V4 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Andrew Cooper]

On 25/08/2015 11:54, Shuai Ruan wrote:
 This patch add basic definitions/helpers which will be used in
 later patches.

 Signed-off-by: Shuai Ruan shuai.r...@linux.intel.com

Thankyou - this series is looking far better now.

 ---
  xen/arch/x86/xstate.c| 137 
 +++
  xen/include/asm-x86/cpufeature.h |   4 ++
  xen/include/asm-x86/domain.h |   1 +
  xen/include/asm-x86/msr-index.h  |   2 +
  xen/include/asm-x86/xstate.h |  11 +++-
  5 files changed, 154 insertions(+), 1 deletion(-)

 diff --git a/xen/arch/x86/xstate.c b/xen/arch/x86/xstate.c
 index d5f5e3b..3986515 100644
 --- a/xen/arch/x86/xstate.c
 +++ b/xen/arch/x86/xstate.c
 @@ -29,6 +29,10 @@ static u32 __read_mostly xsave_cntxt_size;
  /* A 64-bit bitmask of the XSAVE/XRSTOR features supported by processor. */
  u64 __read_mostly xfeature_mask;
  
 +unsigned int *xstate_offsets, *xstate_sizes;
 +static unsigned int xstate_features;
 +static unsigned int xstate_comp_offsets[sizeof(xfeature_mask)*8];

All of these should be tagged as __read_mostly.

 +
  /* Cached xcr0 for fast read */
  static DEFINE_PER_CPU(uint64_t, xcr0);
  
 @@ -65,6 +69,139 @@ uint64_t get_xcr0(void)
  return this_cpu(xcr0);
  }
  
 +static void setup_xstate_features(void)
 +{
 +unsigned int eax, ebx, ecx, edx, leaf = 0x2;
 +unsigned int i;
 +
 +xstate_features = fls(xfeature_mask);
 +xstate_offsets = xzalloc_array(unsigned int, xstate_features);
 +xstate_sizes = xzalloc_array(unsigned int, xstate_features);

These can both be plain xmalloc_array(), as we unconditionally set every
member below.

As a separate patch (or possibly this one if it isn't too big), you now
need to modify the xstate initialisation to return int rather than
void.  You must also check for allocation failures and bail with
-ENOMEM.  It is fine for an error like this to be fatal to system or AP
startup.

Also, merging review from patch 2, this function gets called once per
pcpu, meaning that you waste a moderate quantity of memory and
repeatedly clobber the xstate_{offsets,sizes} pointers.  You should pass
in bool_t bsp and, if bsp, allocate the arrays and read out, while if
not bsp, check that the ap is identical to the bsp.

 +
 +for (i = 0; i  xstate_features ; i++)

Style: spaces inside braces, and there shouldn't be one between
xstate_features;

Also, you can remove i entirely, and use for ( leaf = 2; leaf 
xstate_features; ++i )

 +{
 +cpuid_count(XSTATE_CPUID, leaf, eax, ebx, ecx, edx);
 +
 +xstate_offsets[leaf] = ebx;
 +xstate_sizes[leaf] = eax;

You can drop the ebx and eax temporaries, and as ecx and edx are only
around as discard variables, you can get away with having a single tmp
variable.

Therefore, something like:

cpuid_count(XSTATE_CPUID, leaf, xstate_sizes[leaf],
xstate_offsets[leaf], tmp, tmp);

which also drops the body of the function to a single statement,
allowing you to drop the braces.

 +
 +leaf++;
 +}
 +}
 +
 +static void setup_xstate_comp(void)

This function can get away with being __init, as it is based solely on
data written by the BSP.

Also merging review from patch 2, it only needs calling once.

 +{
 +unsigned int xstate_comp_sizes[sizeof(xfeature_mask)*8];
 +unsigned int i;
 +
 +/*
 + * The FP xstates and SSE xstates are legacy states. They are always
 + * in the fixed offsets in the xsave area in either compacted form
 + * or standard form.
 + */
 +xstate_comp_offsets[0] = 0;
 +xstate_comp_offsets[1] = XSAVE_SSE_OFFSET;
 +
 +xstate_comp_offsets[2] = FXSAVE_SIZE + XSAVE_HDR_SIZE;
 +
 +for (i = 2; i  xstate_features; i++)

Style - spaces inside braces.

 +{
 +if ( (1ull  i)  xfeature_mask )
 +xstate_comp_sizes[i] = xstate_sizes[i];
 +else
 +xstate_comp_sizes[i] = 0;
 +
 +if ( i  2 )
 +xstate_comp_offsets[i] = xstate_comp_offsets[i-1]
 ++ xstate_comp_sizes[i-1];

The entire xstate_comp_sizes array (which is quite large) can be removed
if you rearrange the loop body as:

xstate_comp_offsets[i] = xstate_comp_offsets[i-1] + (((1ul  i) 
xfeature_mask) ? xstate_comp_sizes[i-1] : 0);

which also removes the if ( i  2 )

 +}

As this point, it is probably worth matching xstate_comp_offsets[i-1]
against cpuid.0xd[0].ecx.  If hardware and Xen disagree on the maximum
size of an xsave area, we shouldn't continue.

 +}
 +
 +static void *get_xsave_addr(struct xsave_struct *xsave, int xstate)
 +{
 +int feature = fls(xstate) - 1;

In each callsite, you have already calculated fls(xstate) - 1.  It would
be better to pass an unsigned int xfeature_idx and avoid the repeated
calculation.

 +if ( !(1ull  feature  xfeature_mask) )

Style.  This is a mix of binary operators so needs more brackets than this.

if ( !((1ul  feature)  xfeature_mask )

 +return NULL;
 +
 +return (void *)xsave + 

Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field ‘anonymous’

[Jan Beulich]

 On 25.08.15 at 19:41, andrew.coop...@citrix.com wrote:
 On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
 On Tue, Aug 25, 2015 at 05:48:58PM +0100, Andrew Cooper wrote:
 On 25/08/15 17:43, Konrad Rzeszutek Wilk wrote:
 I am troubleshooting an locking issue and figured I would enable extra 
 options.

 But now I am hitting this build issue:

 domain.c:241: error: negative width in bit-field ‘anonymous’

 Which is:

  229 struct domain *alloc_domain_struct(void)
  230 {
  231 struct domain *d;
 ...
  241 BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);

 Thoughts?
 That is to catch the case where sizeof struct domain exceeds PAGE_SIZE.

 The logic behind this was to prevent needing order 1 allocations for
 domains or vcpus, and therefore allocation failures in heavily memory
 fragmented situations.

 It means we will probably need to find some other areas of struct domain
 to shrink, or move out into a separate xmalloc().

 For straight debugging, it is acceptable to drop the BUILD_BUG_ON().  If
 we can't drop the size of struct domain, we might want to move to using
 vmalloc() instead.
 It is big. pahole says:

/* size: 4352, cachelines: 68, members: 74 */ 
 /* sum members: 4238, holes: 9, sum holes: 34 */ 
 /* padding: 80 */ 
 /* paddings: 1, sum paddings: 4 */
 
 So by rearranging to reduce padding, it would easily fit ;p

How that? 4238  4096.

Jan

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

[Xen-devel] [PATCH] x86/bigmem: eliminate struct domain address width restriction

[Jan Beulich]

PDX-es are 64 bits wide in that case, and hence no limit needs to be
enforced.

Reported-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Jan Beulich jbeul...@suse.com

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -204,6 +204,7 @@ smap_check_policy_t smap_policy_change(s
 return old_policy;
 }
 
+#ifndef CONFIG_BIGMEM
 /*
  * The hole may be at or above the 44-bit boundary, so we need to determine
  * the total bit count until reaching 32 significant (not squashed out) bits
@@ -225,10 +226,12 @@ static unsigned int __init noinline _dom
 
 return bits;
 }
+#endif
 
 struct domain *alloc_domain_struct(void)
 {
 struct domain *d;
+#ifndef CONFIG_BIGMEM
 /*
  * We pack the PDX of the domain structure into a 32-bit field within
  * the page_info structure. Hence the MEMF_bits() restriction.
@@ -237,12 +240,16 @@ struct domain *alloc_domain_struct(void)
 
 if ( unlikely(!bits) )
  bits = _domain_struct_bits();
+#else
+# define bits 0
+#endif
 
 BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
 d = alloc_xenheap_pages(0, MEMF_bits(bits));
 if ( d != NULL )
 clear_page(d);
 return d;
+#undef bits
 }
 
 void free_domain_struct(struct domain *d)



x86/bigmem: eliminate struct domain address width restriction

PDX-es are 64 bits wide in that case, and hence no limit needs to be
enforced.

Reported-by: Andrew Cooper andrew.coop...@citrix.com
Signed-off-by: Jan Beulich jbeul...@suse.com

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -204,6 +204,7 @@ smap_check_policy_t smap_policy_change(s
 return old_policy;
 }
 
+#ifndef CONFIG_BIGMEM
 /*
  * The hole may be at or above the 44-bit boundary, so we need to determine
  * the total bit count until reaching 32 significant (not squashed out) bits
@@ -225,10 +226,12 @@ static unsigned int __init noinline _dom
 
 return bits;
 }
+#endif
 
 struct domain *alloc_domain_struct(void)
 {
 struct domain *d;
+#ifndef CONFIG_BIGMEM
 /*
  * We pack the PDX of the domain structure into a 32-bit field within
  * the page_info structure. Hence the MEMF_bits() restriction.
@@ -237,12 +240,16 @@ struct domain *alloc_domain_struct(void)
 
 if ( unlikely(!bits) )
  bits = _domain_struct_bits();
+#else
+# define bits 0
+#endif
 
 BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
 d = alloc_xenheap_pages(0, MEMF_bits(bits));
 if ( d != NULL )
 clear_page(d);
 return d;
+#undef bits
 }
 
 void free_domain_struct(struct domain *d)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.18 test] 60851: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail REGR. vs. 58581

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 19 guest-start/debianhvm.repeat 
fail in 60817 pass in 60851
 test-amd64-i386-xl-qemut-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
pass in 60817

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 58581
 test-armhf-armhf-xl-rtds 11 guest-start fail baseline untested
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail baseline untested
 test-armhf-armhf-xl-rtds 15 guest-start.2  fail in 60817 baseline untested
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 60817 baseline untested
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 60817 like 58558
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 58581
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  like 58581
 test-armhf-armhf-xl   6 xen-boot fail   like 58581
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail   like 58581
 test-armhf-armhf-xl-xsm   6 xen-boot fail   like 58581
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 58581
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 58581
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 58581

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 60817 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 60817 never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxe9fd6ddcabf8695329f2462d3ece5a8442f2a8cf
baseline version:
 linuxd048c068d00da7d4cfa5ea7651933b99026958cf

Last test of basis58581  2015-06-15 09:42:22 Z   71 days
Failing since 58976  2015-06-29 19:43:23 Z   57 days   49 attempts
Testing same since60642  2015-08-09 13:18:01 Z   16 days8 attempts


383 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   

Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field ‘anonymous’

[Jan Beulich]

 On 25.08.15 at 21:54, konrad.w...@oracle.com wrote:
 On Tue, Aug 25, 2015 at 03:52:15PM -0400, Konrad Rzeszutek Wilk wrote:
 On Tue, Aug 25, 2015 at 06:41:06PM +0100, Andrew Cooper wrote:
  On 25/08/15 18:09, Konrad Rzeszutek Wilk wrote:
   --- a/xen/arch/x86/domain.c
   +++ b/xen/arch/x86/domain.c
   @@ -238,7 +238,9 @@ struct domain *alloc_domain_struct(void)
if ( unlikely(!bits) )
 bits = _domain_struct_bits();

   +#ifndef LOCK_PROFILE
BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
   +#endif
d = alloc_xenheap_pages(0, MEMF_bits(bits));
if ( d != NULL )
clear_page(d);
  
   (not compile tested nor runtime tested)
  
  Either remove it locally for debugging, or use something like
 
 I forgot to mention that by removing it locally Xen ends up halting at:
 
 (XEN) Detected 3292.657 MHz processor.

Sure - as Andrew said on irc, neither simply removing it nor replacing
it by vmalloc() can actually work. At the very least you'd want the
above to become

#ifndef LOCK_PROFILE
BUILD_BUG_ON(sizeof(*d)  PAGE_SIZE);
d = alloc_xenheap_pages(0, MEMF_bits(bits));
#else
BUILD_BUG_ON(sizeof(*d)  2 * PAGE_SIZE);
d = alloc_xenheap_pages(1, MEMF_bits(bits));
#endif

But preferably we'd find ways to shrink struct domain back to a size
where all build options work.

Jan


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

Re: [Xen-devel] [PATCH] x86/bigmem: eliminate struct domain address width restriction

[Andrew Cooper]

On 26/08/15 08:41, Jan Beulich wrote:
 PDX-es are 64 bits wide in that case, and hence no limit needs to be
 enforced.

 Reported-by: Andrew Cooper andrew.coop...@citrix.com
 Signed-off-by: Jan Beulich jbeul...@suse.com

Reviewed-by: Andrew Cooper andrew.coop...@citrix.com

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

Re: [Xen-devel] Xen 4.6.0-rc1 build with lock_profile=y crash_debug=y, frame_pointer=y and domain.c:241: error: negative width in bit-field ‘anonymous’

[Jan Beulich]

 On 25.08.15 at 19:41, andrew.coop...@citrix.com wrote:
 Jan: While reading the code, I note that the bits restriction is not
 required if CONFIG_BIGMEM, and should probably become conditional.

Indeed - patch about to be sent (but probably not qualifying for 4.6).

Jan


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

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

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   37838

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



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH V4 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

[Andrew Cooper]

On 25/08/15 11:54, Shuai Ruan wrote:
 This patch enables xsaves for hvm guest, includes:
 1.handle xsaves vmcs init and vmexit.
 2.add logic to write/read the XSS msr.

 Signed-off-by: Shuai Ruan shuai.r...@linux.intel.com

Reviewed-by: Andrew Cooper andrew.coop...@citrix.com, given two
corrections...

 ---
  xen/arch/x86/hvm/hvm.c | 43 
 ++
  xen/arch/x86/hvm/vmx/vmcs.c|  6 --
  xen/arch/x86/hvm/vmx/vmx.c | 20 ++
  xen/arch/x86/xstate.c  |  4 ++--
  xen/include/asm-x86/hvm/vmx/vmcs.h |  7 +++
  xen/include/asm-x86/hvm/vmx/vmx.h  |  2 ++
  xen/include/asm-x86/xstate.h   |  1 +
  7 files changed, 79 insertions(+), 4 deletions(-)

 diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
 index dc444ac..57612de 100644
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -4540,6 +4540,33 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
 unsigned int *ebx,
  *ebx = _eax + _ebx;
  }
  }
 +if ( count == 1 )
 +{
 +if ( cpu_has_xsaves )
 +{
 +*ebx = XSTATE_AREA_MIN_SIZE;
 +if ( v-arch.xcr0 | v-arch.msr_ia32_xss )
 +for ( sub_leaf = 2; sub_leaf  63; sub_leaf++ )
 +{
 +if ( !((v-arch.xcr0 | v-arch.msr_ia32_xss)
 + (1ULL  sub_leaf)) )

Stray hard tabs.

 @@ -4771,6 +4804,16 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
 msr_content,
 return X86EMUL_EXCEPTION;
  break;
  
 +case MSR_IA32_XSS:
 + /*
 +  * skylake only support bit 8 , but it is
 +  * not support in xen.
 +  */

I would alter this comment to

/* No XSS features currently supported for guests. */

The skylake bits are covered by cpu_has_xsaves.

~Andrew

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

Re: [Xen-devel] [PATCH V4 4/4] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

[Andrew Cooper]

On 25/08/15 11:54, Shuai Ruan wrote:
 This patch exposes xsaves/xgetbv1/xsavec to hvm guest.
 The reserved bits of eax/ebx/ecx/edx must be cleaned up
 when call cpuid(0dh) with leaf 1 or 2..63.

 According to the spec the following bits must be reserved:
 For leaf 1, bits 03-04/08-31 of ecx is reserved. Edx is reserved.
 For leaf 2...63, bits 01-31 of ecx is reserved. Edx is reserved.

 Acked-by: Ian Campbell ian.campb...@citrix.com
 Signed-off-by: Shuai Ruan shuai.r...@linux.intel.com
 ---
  tools/libxc/xc_cpuid_x86.c | 13 +
  1 file changed, 9 insertions(+), 4 deletions(-)

 diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
 index e146a3e..73908b0 100644
 --- a/tools/libxc/xc_cpuid_x86.c
 +++ b/tools/libxc/xc_cpuid_x86.c
 @@ -210,6 +210,9 @@ static void intel_xc_cpuid_policy(
  }
  
  #define XSAVEOPT(1  0)
 +#define XSAVEC  (1  1)
 +#define XGETBV1 (1  2)
 +#define XSAVES  (1  3)
  /* Configure extended state enumeration leaves (0x000D for xsave) */
  static void xc_cpuid_config_xsave(
  xc_interface *xch, domid_t domid, uint64_t xfeature_mask,
 @@ -246,8 +249,9 @@ static void xc_cpuid_config_xsave(
  regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
  break;
  case 1: /* leaf 1 */
 -regs[0] = XSAVEOPT;
 -regs[1] = regs[2] = regs[3] = 0;
 +regs[0] = (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES);
 +regs[2] = 0xe7;

Shouldn't this 0xe7 be mask of xstate_feature bits?

~Andrew

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

[Xen-devel] [Draft B] Boot ABI for HVM guests without a device-model

[Roger Pau Monné]

Hello,

The discussion in [1] lead to an agreement of the missing pieces in PVH
(or HVM without a device-model) in order to progress with it's
implementation.

One of the missing pieces is a new boot ABI, that replaces the PV boot
ABI. The aim of this new boot ABI is to remove the limitations of the
PV boot ABI, that are no longer present when using auto-translated
guests. The new boot protocol should allow to use the same entry point
for both 32bit and 64bit guests, and let the guest choose it's bitness
at run time without the domain builder knowing in advance.

Roger.

[1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html

---
HVM direct boot ABI
===

Since the Xen entry point into the kernel can be different from the
native entry point, ELFNOTES are used in order to tell the domain
builder how to load and jump into the kernel entry point. At least the
following ELFNOTES are required in order to use this boot ABI:

ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,  .asciz, FreeBSD)
ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION, .asciz, 
__XSTRING(__FreeBSD_version))
ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION,   .asciz, xen-3.0)
ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,  .quad,  xen_start32)
ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,  .asciz, 
writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel)
ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,.long ((1  
XENFEAT_writable_page_tables) | \
   (1  
XENFEAT_auto_translated_physmap) | \
   (1  
XENFEAT_supervisor_mode_kernel) | \
   (1  
XENFEAT_hvm_callback_vector))
ELFNOTE(Xen, XEN_ELFNOTE_LOADER,.asciz, generic)

The first three notes contain information about the guest kernel and
the Xen hypercall ABI version. The following notes are of special
interest:

 * XEN_ELFNOTE_PHYS32_ENTRY: the 32bit physical entry point into the kernel.
 * XEN_ELFNOTE_FEATURES: features required by the guest kernel in order
   to run.

The presence of the XEN_ELFNOTE_PHYS32_ENTRY note indicates that the
kernel supports the boot ABI described in this document.

The domain builder will load the kernel into the guest memory space and
jump into the entry point defined at XEN_ELFNOTE_PHYS32_ENTRY with the
following machine state:

 * ebx: contains the physical memory address where the loader has placed
   the boot start info structure.

 * cr0: bit 0 (PE) will be set. All the other writeable bits are cleared.

 * cr4: all bits are cleared.

 * cs: must be a 32-bit read/execute code segment with an offset of ‘0’
   and a limit of ‘0x’. The selector value is unspecified.

 * ds, es: must be a 32-bit read/write data segment with an offset of
   ‘0’ and a limit of ‘0x’. The selector values are all unspecified.

 * tr: must be a 32-bit TSS (active) with a base of '0' and a limit of '0xFF'.

 * eflags: bit 17 (VM) must be cleared. Bit 9 (IF) must be cleared.
   Other bits are all unspecified.

All other processor registers and flag bits are unspecified. The OS is in
charge of setting up it's own stack, GDT and IDT.

The format of the structure passed in the %ebx register is the following:

struct hvm_start_info {
#define HVM_START_MAGIC_VALUE 0x336ec578
uint32_t magic; /* Contains the magic value 0x336ec578   */
/* (xEn3 with the 0x80 bit of the E set).*/
uint32_t flags; /* SIF_xxx flags.*/
uint32_t cmdline_paddr; /* Physical address of the command line. */
uint32_t nr_modules;/* Number of modules passed to the kernel.   */
uint32_t modlist_paddr; /* Physical address of an array of   */
/* hvm_modlist_entry.*/
};

struct hvm_modlist_entry {
uint64_t paddr; /* Physical address of the module.   */
uint64_t size;  /* Size of the module in bytes.  */
};

This structure is guaranteed to always be placed in memory after the
loaded kernel and modules. There's no upper bound on the size of the
structure, users should be aware that it might cross a page boundary.

Note that the boot protocol resembles the multiboot1 specification,
this is done so OSes with multiboot1 entry points can reuse those if
desired.

Other relevant information needed in order to boot a guest kernel
(console page address, xenstore event channel...) can be obtained
using HVMPARAMS, just like it's done on HVM guests.

The setup of the hypercall page is also performed in the same way
as HVM guests, using a wrmsr.

AP startup
==

AP startup is performed using hypercalls. The following VCPU operations
are used in order to bring up secondary vCPUs:

 * VCPUOP_initialise is used to set the initial state of the vCPU. The
   argument 

Re: [Xen-devel] [Draft B] Boot ABI for HVM guests without a device-model

[Andrew Cooper]

On 26/08/15 12:48, Roger Pau Monné wrote:
 Hello,

 The discussion in [1] lead to an agreement of the missing pieces in PVH
 (or HVM without a device-model) in order to progress with it's
 implementation.

 One of the missing pieces is a new boot ABI, that replaces the PV boot
 ABI. The aim of this new boot ABI is to remove the limitations of the
 PV boot ABI, that are no longer present when using auto-translated
 guests. The new boot protocol should allow to use the same entry point
 for both 32bit and 64bit guests, and let the guest choose it's bitness
 at run time without the domain builder knowing in advance.

 Roger.

 [1] http://lists.xen.org/archives/html/xen-devel/2015-06/msg00258.html

 ---
 HVM direct boot ABI
 ===

 Since the Xen entry point into the kernel can be different from the
 native entry point, ELFNOTES are used in order to tell the domain
 builder how to load and jump into the kernel entry point. At least the
 following ELFNOTES are required in order to use this boot ABI:

Perhaps note that this includes the example FreeBSD values.  It
shouldn't be implied that these are the exact notes which should be used.


 ELFNOTE(Xen, XEN_ELFNOTE_GUEST_OS,  .asciz, FreeBSD)
 ELFNOTE(Xen, XEN_ELFNOTE_GUEST_VERSION, .asciz, 
 __XSTRING(__FreeBSD_version))
 ELFNOTE(Xen, XEN_ELFNOTE_XEN_VERSION,   .asciz, xen-3.0)
 ELFNOTE(Xen, XEN_ELFNOTE_PHYS32_ENTRY,  .quad,  xen_start32)

As this is strictly a 32bit entry, it can be .long rather than .quad

 ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,  .asciz, 
 writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel)
 ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,.long ((1  
 XENFEAT_writable_page_tables) | \
(1  
 XENFEAT_auto_translated_physmap) | \
(1  
 XENFEAT_supervisor_mode_kernel) | \
(1  
 XENFEAT_hvm_callback_vector))

Can we see about fixing the overloading of XENFEAT_supervisor_mode_kernel ?

IMO it should be relegated to history.  It was an old,
not-fully-implemented pv feature (subsequently removed completely) which
is not relevant to HVM guests.

 snip

 Other relevant information needed in order to boot a guest kernel
 (console page address, xenstore event channel...) can be obtained
 using HVMPARAMS, just like it's done on HVM guests.

 The setup of the hypercall page is also performed in the same way
 as HVM guests, using a wrmsr.

using the hypervisor cpuid leaves and msr ranges.

~Andrew

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

Re: [Xen-devel] [PATCH V4 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Jan Beulich]

 On 25.08.15 at 12:54, shuai.r...@linux.intel.com wrote:
 +void save_xsave_states(struct vcpu *v, void *dest ,unsigned int size)
 +{
 +struct xsave_struct *xsave = v-arch.xsave_area;
 +u64 xstate_bv = xsave-xsave_hdr.xstate_bv;
 +u64 valid;
 +
 +/*
 + * Copy legacy XSAVE area, to avoid complications with CPUID
 + * leaves 0 and 1 in the loop below.
 + */
 +memcpy(dest, xsave, FXSAVE_SIZE);
 +
 +/* Set XSTATE_BV */
 +*(u64 *)(dest + XSAVE_HDR_OFFSET) = xstate_bv;

Please try to avoid such (dangerous) casts.

 +/*
 + * Copy each region from the possibly compacted offset to the
 + * non-compacted offset.
 + */
 +valid = xstate_bv  ~XSTATE_FP_SSE;
 +while ( valid )
 +{
 +u64 feature = valid  -valid;
 +int index = fls(feature) - 1;

find_first_set_bit() (or ffsl()) would make this more readable.

 --- a/xen/include/asm-x86/domain.h
 +++ b/xen/include/asm-x86/domain.h
 @@ -506,6 +506,7 @@ struct arch_vcpu
   */
  struct xsave_struct *xsave_area;
  uint64_t xcr0;
 +uint64_t msr_ia32_xss;

Considering that you mean to not support this for PV guests, this
should go into struct hvm_vcpu. And I think naming it just xss
or at most msr_xss would be quite fine.

Jan


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

Re: [Xen-devel] [PATCH V4 2/4] x86/xsaves: enable xsaves/xrstors in xen

[Andrew Cooper]

On 26/08/15 12:50, Jan Beulich wrote:
 On 26.08.15 at 12:12, andrew.coop...@citrix.com wrote:
 On 25/08/15 11:54, Shuai Ruan wrote:
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -2148,8 +2148,12 @@ static int hvm_save_cpu_xsave_states(struct domain 
 *d, hvm_domain_context_t *h)
  ctxt-xfeature_mask = xfeature_mask;
  ctxt-xcr0 = v-arch.xcr0;
  ctxt-xcr0_accum = v-arch.xcr0_accum;
 -memcpy(ctxt-save_area, v-arch.xsave_area,
 -   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
 +   if ( cpu_has_xsaves )
 Stray hard tab.

 +save_xsave_states(v, (void *)ctxt-save_area,
 +  size - offsetof(struct 
 hvm_hw_cpu_xsave,save_area));
 These offsetof()s can become far shorter by using offsetof(*ctxt,
 save_area).
 Are you mixing this up with sizeof()? If anything, offsetof(typeof(),).

Oops sorry yes.  I did mean to include the use of typeof(), which still
makes it shorter.


 --- a/xen/arch/x86/traps.c
 +++ b/xen/arch/x86/traps.c
 @@ -936,9 +936,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
  if ( regs-_ecx == 1 )
  {
  a = XSTATE_FEATURE_XSAVEOPT |
 - XSTATE_FEATURE_XSAVEC |
 - (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 - (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0);
 + XSTATE_FEATURE_XSAVEC;
 +/* PV guest will not support xsaves. */
 + /* (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 + (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0); */
 Don't leave this code commented out like this.  Just delete it.
 Agreed, but - mind reminding me again why supporting them for
 PV guests isn't going to work?

xsaves is a cpl0 instruction used to manage state which userspace can't
be trusted to handle alone.  Xen therefore can't trust PV guests to use
it either.

The first of these features is Processor Trace.  A PV guest able to use
xsaves/xrstors would be able to gather trace data of hypervisor
execution, or cause the trace buffers to clobber arbitrary physical memory.

The features covered by MSR_IA32_XSS can safely be exposed to PV guests,
but via a hypercall interface.

~Andrew

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

Re: [Xen-devel] [PATCH v5 21/22] xen/arm: ITS: Generate ITS node for Dom0

[Vijay Kilari]

On Tue, Aug 18, 2015 at 1:11 AM, Julien Grall julien.gr...@citrix.com wrote:


 On 27/07/2015 04:12, vijay.kil...@gmail.com wrote:

 From: Vijaya Kumar K vijaya.ku...@caviumnetworks.com

 Parse host dt and generate ITS node for Dom0.
 ITS node resides inside GIC node so when GIC node
 is encountered look for ITS node.

 Signed-off-by: Vijaya Kumar K vijaya.ku...@caviumnetworks.com
 ---
 v5: - Moved ITS dt node generation to ITS driver
 v4: - Generate only one ITS node for Dom0
  - Replace msi-parent references to single its phandle
 ---
   xen/arch/arm/domain_build.c   |   17 ++
   xen/arch/arm/gic-v3-its.c |   74
 +
   xen/arch/arm/gic-v3.c |   29 
   xen/arch/arm/gic.c|   18 ++
   xen/include/asm-arm/gic-its.h |3 ++
   xen/include/asm-arm/gic.h |7 
   6 files changed, 148 insertions(+)

 diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
 index 8556afd..6b6f013 100644
 --- a/xen/arch/arm/domain_build.c
 +++ b/xen/arch/arm/domain_build.c
 @@ -469,6 +469,19 @@ static int write_properties(struct domain *d, struct
 kernel_info *kinfo,
   continue;
   }

 +/*
 + * Replace all msi-parent phandle references to single ITS node
 + * generated for Dom0
 + */
 +if ( dt_property_name_is_equal(prop, msi-parent) )


 I think this need more care than replacing every msi-parent without any
 checking.

 You need to make sure that the msi-parent points to an ITS MSI just in case
 there is other possibility of MSI.

 Furthermore, I would do this a ITS specific callback (gic_rewrite_node or
 smth similar) to avoid replacing msi-parent when it's not necessary. I have
 in mind GICv2M.

 +{
 +fdt32_t phandle = gic_get_msi_handle();
 +DPRINT( Set msi-parent(ITS) phandle 0x%x\n,phandle);
 +fdt_property(kinfo-fdt, prop-name, (void *)phandle,
 + sizeof(phandle));
 +continue;
 +}
 +
   res = fdt_property(kinfo-fdt, prop-name, prop_data, prop_len);

   xfree(new_data);
 @@ -875,6 +888,10 @@ static int make_gic_node(const struct domain *d, void
 *fdt,
   return res;

   res = fdt_end_node(fdt);
 +if ( res )
 +return res;
 +
 +res = gic_its_hwdom_dt_node(d, node, fdt);


 Can you explain why you didn't follow my suggestion to plumb the ITS node
 creation in gic_hwdow_dt_node? IHMO there is no need of new callback.

 Furthermore the call is misplaced. You will end up to have a DT looking like

 gic {
 }

 gic-its {
 }

 rather than

 gic {
   gic-its {
   }
 }

 As discussed, I have tried to generate ITS node inside gic node and call
fdt_end_node() for gic after generating ITS node. But dom0 fails to
find ITS node in the generated device tree. Any clue?

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

Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Jan Beulich]

 On 26.08.15 at 14:33, daniel.ki...@oracle.com wrote:
 Do you suggest that I should put this functionality (PE with multiboot
 headers) on top of this patch series? Well, it is possible but this
 series is big and I would like to avoid to make it bigger. I prefer to
 get current patches into Xen tree and then work on new features (it
 should not take so long because as I can see we almost agreed most
 of stuff in that case). Or if at least half patches of current series
 will be accepted (as I can see there is a chance to do that with v3)
 then I can work on this functionality and put it on top of second not
 applied part. Does it make sense?

Yes. I'm not objecting to deferring that part. All I want is you to make
sure not to submit any changes potentially conflicting with the end
goal of having a single binary (which as I understand it can only be a
PE one).

Jan


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

Re: [Xen-devel] [PATCH V4 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Jan Beulich]

 On 26.08.15 at 11:47, andrew.coop...@citrix.com wrote:
 On 25/08/2015 11:54, Shuai Ruan wrote:
 --- a/xen/include/asm-x86/cpufeature.h
 +++ b/xen/include/asm-x86/cpufeature.h
 @@ -153,6 +153,10 @@
  #define X86_FEATURE_RDSEED  (7*32+18) /* RDSEED instruction */
  #define X86_FEATURE_ADX (7*32+19) /* ADCX, ADOX instructions */
  #define X86_FEATURE_SMAP(7*32+20) /* Supervisor Mode Access Prevention 
 */
 +#define XSAVEOPT(1  0)
 +#define XSAVEC  (1  1)
 +#define XGETBV1 (1  2)
 +#define XSAVES  (1  3)
 
 This absolutely must be X86_FEATURE_* for consistency, and you will need
 to introduce a new capability word.

Or even better re-use word 2.

Jan


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

Re: [Xen-devel] [PATCH V4 2/4] x86/xsaves: enable xsaves/xrstors in xen

[Jan Beulich]

 On 26.08.15 at 12:12, andrew.coop...@citrix.com wrote:
 On 25/08/15 11:54, Shuai Ruan wrote:
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -2148,8 +2148,12 @@ static int hvm_save_cpu_xsave_states(struct domain 
 *d, hvm_domain_context_t *h)
  ctxt-xfeature_mask = xfeature_mask;
  ctxt-xcr0 = v-arch.xcr0;
  ctxt-xcr0_accum = v-arch.xcr0_accum;
 -memcpy(ctxt-save_area, v-arch.xsave_area,
 -   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
 +if ( cpu_has_xsaves )
 
 Stray hard tab.
 
 +save_xsave_states(v, (void *)ctxt-save_area,
 +  size - offsetof(struct 
 hvm_hw_cpu_xsave,save_area));
 
 These offsetof()s can become far shorter by using offsetof(*ctxt,
 save_area).

Are you mixing this up with sizeof()? If anything, offsetof(typeof(),).

 --- a/xen/arch/x86/traps.c
 +++ b/xen/arch/x86/traps.c
 @@ -936,9 +936,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
  if ( regs-_ecx == 1 )
  {
  a = XSTATE_FEATURE_XSAVEOPT |
 - XSTATE_FEATURE_XSAVEC |
 - (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 - (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0);
 + XSTATE_FEATURE_XSAVEC;
 + /* PV guest will not support xsaves. */
 + /* (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 + (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0); */
 
 Don't leave this code commented out like this.  Just delete it.

Agreed, but - mind reminding me again why supporting them for
PV guests isn't going to work?

Jan


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

Re: [Xen-devel] [PATCH V4 2/4] x86/xsaves: enable xsaves/xrstors in xen

[Jan Beulich]

 On 26.08.15 at 14:05, andrew.coop...@citrix.com wrote:
 On 26/08/15 12:50, Jan Beulich wrote:
 On 26.08.15 at 12:12, andrew.coop...@citrix.com wrote:
 On 25/08/15 11:54, Shuai Ruan wrote:
 --- a/xen/arch/x86/traps.c
 +++ b/xen/arch/x86/traps.c
 @@ -936,9 +936,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
  if ( regs-_ecx == 1 )
  {
  a = XSTATE_FEATURE_XSAVEOPT |
 - XSTATE_FEATURE_XSAVEC |
 - (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 - (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0);
 + XSTATE_FEATURE_XSAVEC;
 +   /* PV guest will not support xsaves. */
 + /* (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 + (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0); */
 Don't leave this code commented out like this.  Just delete it.
 Agreed, but - mind reminding me again why supporting them for
 PV guests isn't going to work?
 
 xsaves is a cpl0 instruction used to manage state which userspace can't
 be trusted to handle alone.  Xen therefore can't trust PV guests to use
 it either.
 
 The first of these features is Processor Trace.  A PV guest able to use
 xsaves/xrstors would be able to gather trace data of hypervisor
 execution, or cause the trace buffers to clobber arbitrary physical memory.
 
 The features covered by MSR_IA32_XSS can safely be exposed to PV guests,
 but via a hypercall interface.

That covers xsaves, but not xgetbv1 (which also covers XSAVEOPT).

Jan


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

Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Daniel Kiper]

On Wed, Aug 26, 2015 at 06:40:22AM -0600, Jan Beulich wrote:
  On 26.08.15 at 14:33, daniel.ki...@oracle.com wrote:
  Do you suggest that I should put this functionality (PE with multiboot
  headers) on top of this patch series? Well, it is possible but this
  series is big and I would like to avoid to make it bigger. I prefer to
  get current patches into Xen tree and then work on new features (it
  should not take so long because as I can see we almost agreed most
  of stuff in that case). Or if at least half patches of current series
  will be accepted (as I can see there is a chance to do that with v3)
  then I can work on this functionality and put it on top of second not
  applied part. Does it make sense?

 Yes. I'm not objecting to deferring that part. All I want is you to make

Great!

 sure not to submit any changes potentially conflicting with the end

OK.

 goal of having a single binary (which as I understand it can only be a
 PE one).

This is the end goal but I think that we should have transitional phase
when both formats (ELF and PE) are avaibale for users. Just in case.

Daniel

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

Re: [Xen-devel] [PATCH V4 4/4] libxc: expose xsaves/xgetbv1/xsavec to hvm guest

[Jan Beulich]

 On 26.08.15 at 12:43, andrew.coop...@citrix.com wrote:
 On 25/08/15 11:54, Shuai Ruan wrote:
 @@ -246,8 +249,9 @@ static void xc_cpuid_config_xsave(
  regs[1] = 512 + 64; /* FP/SSE + XSAVE.HEADER */
  break;
  case 1: /* leaf 1 */
 -regs[0] = XSAVEOPT;
 -regs[1] = regs[2] = regs[3] = 0;
 +regs[0] = (XSAVEOPT | XSAVEC | XGETBV1 | XSAVES);
 +regs[2] = 0xe7;
 
 Shouldn't this 0xe7 be mask of xstate_feature bits?

And a few lines down there's also a similar hard coded 1. Please
stay away from adding new literal numbers - if there are no suitable
ones, introduce manifest constants.

Jan


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

Re: [Xen-devel] [Draft B] Boot ABI for HVM guests without a device-model

[Andrew Cooper]

On 26/08/15 13:00, Jan Beulich wrote:

 struct hvm_start_info {
 #define HVM_START_MAGIC_VALUE 0x336ec578
 uint32_t magic; /* Contains the magic value 0x336ec578   
 */
 /* (xEn3 with the 0x80 bit of the E 
 set).*/
 uint32_t flags; /* SIF_xxx flags.
 */
 uint32_t cmdline_paddr; /* Physical address of the command line. 
 */
 uint32_t nr_modules;/* Number of modules passed to the kernel.   
 */
 uint32_t modlist_paddr; /* Physical address of an array of   
 */
 /* hvm_modlist_entry.
 */
 };

 struct hvm_modlist_entry {
 uint64_t paddr; /* Physical address of the module.   
 */
 uint64_t size;  /* Size of the module in bytes.  
 */
 };
 Why is paddr 64-bit here, but 32-bit in both cases above?

This was my fault for suggesting it like this, but on further
consideration, uint32_t's for both fields will be fine.  It won't be
interesting to load any modules outside of the 32bit boundary.

Anyone wishing to load more than 4GB of modules this way should go away
and rethink their boot procedure.


 This structure is guaranteed to always be placed in memory after the
 DYM These structures are ...?

 loaded kernel and modules.

There is no requirement for the command line/module information to be
after the loaded kernel.  All it needs to do is not overlap.

  There's no upper bound on the size of the
 structure, users should be aware that it might cross a page boundary.
 How is there no size limit? It's (currently) 16 bytes, and I don't see
 why it would change. And even if - as implied by the previous
 comment - this also relates to struct hvm_start_info: Its size is
 fixed (and unlikely to change much) too.

I agree it is unlikely to change (but there is a flags field just in
case), but we shouldn't impose unnecessary arbitrary restrictions.

~Andrew

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

Re: [Xen-devel] [PATCH V4 1/4] x86/xsaves: add basic definitions/helpers to support xsaves

[Jan Beulich]

 On 26.08.15 at 13:41, jbeul...@suse.com wrote:
 On 26.08.15 at 11:47, andrew.coop...@citrix.com wrote:
 On 25/08/2015 11:54, Shuai Ruan wrote:
 --- a/xen/include/asm-x86/cpufeature.h
 +++ b/xen/include/asm-x86/cpufeature.h
 @@ -153,6 +153,10 @@
  #define X86_FEATURE_RDSEED (7*32+18) /* RDSEED instruction */
  #define X86_FEATURE_ADX(7*32+19) /* ADCX, ADOX instructions */
  #define X86_FEATURE_SMAP   (7*32+20) /* Supervisor Mode Access Prevention 
 */
 +#define XSAVEOPT   (1  0)
 +#define XSAVEC (1  1)
 +#define XGETBV1(1  2)
 +#define XSAVES (1  3)
 
 This absolutely must be X86_FEATURE_* for consistency, and you will need
 to introduce a new capability word.
 
 Or even better re-use word 2.

And make sure to replace the then redundant XSTATE_FEATURE_*
definitions in xstate.h.

Jan


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

[Xen-devel] [linux-mingo-tip-master test] 60853: regressions - FAIL

[osstest service owner]

flight 60853 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/60853/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 5 kernel-build  fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl   14 guest-saverestorefail   like 60684
 test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   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-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-raw   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-libvirt  14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  14 guest-saverestorefail   never pass
 test-amd64-i386-xl-xsm   14 guest-saverestorefail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux975b43717d0e1fed3cc68ce42aa692b59c4ff845
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z   13 days
Failing since 60712  2015-08-15 18:33:48 Z   10 days5 attempts
Testing same since60853  2015-08-24 04:24:16 Z2 days1 attempts

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopsfail
 build-i386-pvops pass
 build-amd64-rumpuserxen  

Re: [Xen-devel] [Draft B] Boot ABI for HVM guests without a device-model

[Jan Beulich]

 On 26.08.15 at 13:48, roger@citrix.com wrote:
  * tr: must be a 32-bit TSS (active) with a base of '0' and a limit of '0xFF'.

Why 0xFF instead of 0x67?

 struct hvm_start_info {
 #define HVM_START_MAGIC_VALUE 0x336ec578
 uint32_t magic; /* Contains the magic value 0x336ec578   
 */
 /* (xEn3 with the 0x80 bit of the E 
 set).*/
 uint32_t flags; /* SIF_xxx flags.
 */
 uint32_t cmdline_paddr; /* Physical address of the command line. 
 */
 uint32_t nr_modules;/* Number of modules passed to the kernel.   
 */
 uint32_t modlist_paddr; /* Physical address of an array of   
 */
 /* hvm_modlist_entry.
 */
 };
 
 struct hvm_modlist_entry {
 uint64_t paddr; /* Physical address of the module.   
 */
 uint64_t size;  /* Size of the module in bytes.  
 */
 };

Why is paddr 64-bit here, but 32-bit in both cases above?

 This structure is guaranteed to always be placed in memory after the

DYM These structures are ...?

 loaded kernel and modules. There's no upper bound on the size of the
 structure, users should be aware that it might cross a page boundary.

How is there no size limit? It's (currently) 16 bytes, and I don't see
why it would change. And even if - as implied by the previous
comment - this also relates to struct hvm_start_info: Its size is
fixed (and unlikely to change much) too.

 Note that the boot protocol resembles the multiboot1 specification,
 this is done so OSes with multiboot1 entry points can reuse those if
 desired.

Which raises the question why we don't make it multiboot1 as much
as possible.

Jan


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

Re: [Xen-devel] [PATCH v2 10/23] efi: build xen.gz with EFI code

[Daniel Kiper]

On Wed, Aug 26, 2015 at 12:46:22AM -0600, Jan Beulich wrote:
  On 25.08.15 at 18:31, daniel.ki...@oracle.com wrote:
  On Tue, Aug 25, 2015 at 06:09:09AM -0600, Jan Beulich wrote:
   On 24.08.15 at 22:54, daniel.ki...@oracle.com wrote:

[...]

  And you realize that we use a special method for building the
  current flat ELF image too?
 
  Yes, I know about that.

 And with that I wonder ...

   This way one file could be loaded by native PE loader, mulitboot (v1)
   protocol
   (it requires relevant header but it does not interfere with PE and
   multiboot2
   protocol stuff) and mutliboot2 protocol compatible loaders. Additionally,
   if it is signed with Secure Boot signature then potentially signature 
   could
   be verified by UEFI itself and e.g. GRUB2. However, as I said earlier 
   this
   requires more work and this is next step which I am going to do after
   applying
   this series. Currently I am going to embed EFI support into ELF file 
   because
   it is easy (less changes; currently used ELF file has required properties
   because multiboot (v1) which we use has similar requirements like 
   multiboot2
   protocol) to make it compatible with multiboot2 protocol.
 
  I think whether what you do now makes sense depends on the
  ultimate goal: If we want a single binary usable for all three cases,
  then while yes, having EFI code available in the ELF image makes
  sense, using an ELF Image won't work. And we can't have an
  image being both ELF and PE. Hence the goal ought to be to have
  a single PE image, and with that the direction you move seems
  wrong.
 
  It depends how we want to generate proper PE file. There are two options.
 
  We can put manually proper PE header into xen/arch/x86/boot/head.S (maybe
  with some additional needed stuff). Then after build we will have ELF file
  which is loadable by multiboot protocols and has extra PE header. Of course
  it is unusable directly by EFI loader. However, using simple objcopy we can
  extract all interesting stuff from ELF file. This way we get proper PE file
  which is usable by three different boot protocols. Going that way we can
  also remove strict dependency on exact version of binutils which must have
  enabled i386pep support if we wish to build PE image.
 
  Potentially we can choose second way and build proper PE image using ld and
  objcopy/objdump tools with proper options. However, this require more work
  (maybe we will be forced to build something similar to mkelf32) and we bind
  Xen build machinery more tightly with exact version of binutils which is
  not nice.
 
  So, I decided to choose option #1.

 ... why there's no option #3 here: Build a suitable PE image using a
 tool similar to mkelf32 _without_ involving ld/objcopy (i.e. straight
 from the full ELF binary that mkelf32 today uses as its input).

This is variant of #1 and make sense too. However, this way we do not get
extra PE header in ELF file which is also good.

  It looks simpler because we have a lot of
  needed stuff in place (e.g. Xen ELF image is currently in format usable by
  multiboot protocols). However, I think that in first step we should add EFI
  code to xen.gz because we want to load Xen using GRUB2 on EFI platforms
  ASAP.
  This patch allows us to do that. Later after getting this feature into
  upstream
  we can focus on building proper PE image with multiboot protocols support
  embedded in it.

 But for whatever we do now we should keep in mind what the end
 goal is, and at least avoid making it more cumbersome to reach that
 end goal. And in the end I'm not sure not going the full way at once

#1 and #3 need EFI code in xen.gz. So, I do not think that we do anything
wrong adding this functionality here because we need it for GRUB2 support
on EFI platforms too. Hence, both things benefit from that change but one
does not depend on another.

 will actually turn out to be the easier route.

Do you suggest that I should put this functionality (PE with multiboot
headers) on top of this patch series? Well, it is possible but this
series is big and I would like to avoid to make it bigger. I prefer to
get current patches into Xen tree and then work on new features (it
should not take so long because as I can see we almost agreed most
of stuff in that case). Or if at least half patches of current series
will be accepted (as I can see there is a chance to do that with v3)
then I can work on this functionality and put it on top of second not
applied part. Does it make sense?

Daniel

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

Re: [Xen-devel] [PATCH] x86/MSI: don't flag non-maskable entries a host-masked

[Wei Liu]

On Wed, Aug 26, 2015 at 07:50:24AM -0600, Jan Beulich wrote:
 'M' debug key output looks confusing without this adjustment.
 
 Signed-off-by: Jan Beulich jbeul...@suse.com
 

Release-acked-by: Wei Liu wei.l...@citrix.com

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

Re: [Xen-devel] [Draft B] Boot ABI for HVM guests without a device-model

[Roger Pau Monné]

El 26/08/15 a les 14.12, Andrew Cooper ha escrit:
 On 26/08/15 13:00, Jan Beulich wrote:
 This structure is guaranteed to always be placed in memory after the
 DYM These structures are ...?

 loaded kernel and modules.
 
 There is no requirement for the command line/module information to be
 after the loaded kernel.  All it needs to do is not overlap.

IMHO, this is helpful in order to get last used physical address, after
which free memory starts. Current FreeBSD implementation relies on this,
if we didn't do it that way I would have to calculate where the symtab +
strtab ends, which is more complex.

  There's no upper bound on the size of the
 structure, users should be aware that it might cross a page boundary.
 How is there no size limit? It's (currently) 16 bytes, and I don't see
 why it would change. And even if - as implied by the previous
 comment - this also relates to struct hvm_start_info: Its size is
 fixed (and unlikely to change much) too.
 
 I agree it is unlikely to change (but there is a flags field just in
 case), but we shouldn't impose unnecessary arbitrary restrictions.

After reading it again, I realize this is not properly worded. What I
wanted to say is that the cmdline or the list of loaded modules might
cross a page boundary.

Roger.


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

Re: [Xen-devel] [PATCH] x86/MSI: don't flag non-maskable entries a host-masked

[Jan Beulich]

 On 26.08.15 at 15:57, konrad.w...@oracle.com wrote:
 On Wed, Aug 26, 2015 at 07:50:24AM -0600, Jan Beulich wrote:
 'M' debug key output looks confusing without this adjustment.
 
 Signed-off-by: Jan Beulich jbeul...@suse.com
 
 --- a/xen/arch/x86/msi.c
 +++ b/xen/arch/x86/msi.c
 @@ -716,8 +716,8 @@ static int msi_capability_init(struct pc
  entry[i].msi_attrib.type = PCI_CAP_ID_MSI;
  entry[i].msi_attrib.is_64 = is_64bit_address(control);
  entry[i].msi_attrib.entry_nr = i;
 +entry[i].msi_attrib.host_masked =
  entry[i].msi_attrib.maskbit = is_mask_bit_support(control);
 -entry[i].msi_attrib.host_masked = 1;
  entry[i].msi_attrib.guest_masked = 0;
  entry[i].msi_attrib.pos = pos;
  if ( entry[i].msi_attrib.maskbit )
 
 
 
 
 x86/MSI: don't flag non-maskable entries a host-masked
 
 s/a/as/ ?

Of course - sorry.

Jan


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

Re: [Xen-devel] [PATCH V4 3/4] x86/xsaves: enable xsaves/xrstors for hvm guest

[Jan Beulich]

 On 25.08.15 at 12:54, shuai.r...@linux.intel.com wrote:
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -4540,6 +4540,33 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
 unsigned int *ebx,
  *ebx = _eax + _ebx;
  }
  }
 +if ( count == 1 )
 +{
 +if ( cpu_has_xsaves )
 +{
 +*ebx = XSTATE_AREA_MIN_SIZE;
 +if ( v-arch.xcr0 | v-arch.msr_ia32_xss )
 +for ( sub_leaf = 2; sub_leaf  63; sub_leaf++ )
 +{
 +if ( !((v-arch.xcr0 | v-arch.msr_ia32_xss)
 + (1ULL  sub_leaf)) )
 +continue;
 +_eax = xstate_sizes[sub_leaf];
 +*ebx =  *ebx + _eax;

Why not just *ebx += xstate_sizes[sub_leaf]?

 +}
 +}
 +else
 +{
 +*eax = ~XSAVES;
 +*ebx = *ecx = *edx = 0;
 +}
 +if ( !cpu_has_xgetbv1 )
 +*eax = ~XGETBV1;
 +if ( !cpu_has_xsavec )
 +*eax = ~XSAVEC;
 +if ( !cpu_has_xsaveopt )
 +*eax = ~XSAVEOPT;

Are all these really necessary? And is they are, why isn't the
XSAVEOPT one needed already before this series?

 @@ -1238,7 +1239,8 @@ static int construct_vmcs(struct vcpu *v)
  __vmwrite(HOST_PAT, host_pat);
  __vmwrite(GUEST_PAT, guest_pat);
  }
 -
 +if ( cpu_has_vmx_xsaves )
 +__vmwrite(XSS_EXIT_BITMAP, VMX_XSS_EXIT_BITMAP);

This reads as if you were writing an architecture mandated value
into an architecture defined VMCS slot. I.e. the second constant
would better be renamed imo.

 @@ -365,6 +370,8 @@ enum vmcs_field {
  VMREAD_BITMAP   = 0x2026,
  VMWRITE_BITMAP  = 0x2028,
  VIRT_EXCEPTION_INFO = 0x202a,
 +XSS_EXIT_BITMAP = 0x202c,
 +XSS_EXIT_BITMAP_HIGH= 0x202d,

Did you not notice that all the ..._HIGH value are gone in favor of
using VMCS_HIGH() in the few cases where a 64-bit hypervisor really
needs to access (or rather, emulate) them?

Jan


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

Re: [Xen-devel] About runtime service for Xen on ARM

[Shannon Zhao]

Hi Julien,

Thanks for your reply. :)

On 2015/8/26 11:24, Julien Grall wrote:



On 19/08/2015 23:27, Shannon Zhao wrote:

Hi Julien,


Hi Shannon,

Sorry for the late answer I was on holiday. In general it's better to CC
multiple person and the mailing list as we may not be able to answer in
short time or not know the answer.

I've CCed the ML and few people which know better than me the status of
EFI runtime.


Do you know the status of runtime service for Xen on ARM? Does it
support runtime service booting with DT? If not, is there a plan to
support it?


There is no support of runtime EFI on ARM for now and I'm not aware of
any short plan for this.


In addition, if you know this, does it support runtime service for Xen
on x86?


There is some on-going work for EFI runtime on x86. I'm not sure if it
has been upstream (CCed Daniel for this).

Although, one of there is a fundamental difference between the UEFI boot
on x86 and ARM. While the code is the same, on ARM the UEFI act as a
stub and should not be able to communicate via exported variable with
Xen (we clobber BSS just after the UEFI stub jump on the normal boot
start).

I know that the ARM EFI stub is using some shared variable with Xen (I
have in mind the memory banks see bootinfo). We are very lucky that it's
working because the variable is living in initdata which somehow is part
of text (I'm not sure why) and not BSS.
So we should either decide that the stub and xen should be able to
communicate together or not.

I would be in favor of the former but I don't know what are the view of
the others.

Regards,



--
Shannon

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

Re: [Xen-devel] [PATCH] x86/MSI: don't flag non-maskable entries a host-masked

[Konrad Rzeszutek Wilk]

On Wed, Aug 26, 2015 at 07:50:24AM -0600, Jan Beulich wrote:
 'M' debug key output looks confusing without this adjustment.
 
 Signed-off-by: Jan Beulich jbeul...@suse.com
 
 --- a/xen/arch/x86/msi.c
 +++ b/xen/arch/x86/msi.c
 @@ -716,8 +716,8 @@ static int msi_capability_init(struct pc
  entry[i].msi_attrib.type = PCI_CAP_ID_MSI;
  entry[i].msi_attrib.is_64 = is_64bit_address(control);
  entry[i].msi_attrib.entry_nr = i;
 +entry[i].msi_attrib.host_masked =
  entry[i].msi_attrib.maskbit = is_mask_bit_support(control);
 -entry[i].msi_attrib.host_masked = 1;
  entry[i].msi_attrib.guest_masked = 0;
  entry[i].msi_attrib.pos = pos;
  if ( entry[i].msi_attrib.maskbit )
 
 
 

 x86/MSI: don't flag non-maskable entries a host-masked

s/a/as/ ?

 
 'M' debug key output looks confusing without this adjustment.
 
 Signed-off-by: Jan Beulich jbeul...@suse.com
 
 --- a/xen/arch/x86/msi.c
 +++ b/xen/arch/x86/msi.c
 @@ -716,8 +716,8 @@ static int msi_capability_init(struct pc
  entry[i].msi_attrib.type = PCI_CAP_ID_MSI;
  entry[i].msi_attrib.is_64 = is_64bit_address(control);
  entry[i].msi_attrib.entry_nr = i;
 +entry[i].msi_attrib.host_masked =
  entry[i].msi_attrib.maskbit = is_mask_bit_support(control);
 -entry[i].msi_attrib.host_masked = 1;
  entry[i].msi_attrib.guest_masked = 0;
  entry[i].msi_attrib.pos = pos;
  if ( entry[i].msi_attrib.maskbit )

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


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

Re: [Xen-devel] [PATCH] x86/MSI: don't flag non-maskable entries a host-masked

[Andrew Cooper]

On 26/08/15 14:50, Jan Beulich wrote:
 'M' debug key output looks confusing without this adjustment.

 Signed-off-by: Jan Beulich jbeul...@suse.com

Reviewed-by: Andrew Cooper andrew.coop...@citrix.com, with Konrads
suggestion fixed.


 --- a/xen/arch/x86/msi.c
 +++ b/xen/arch/x86/msi.c
 @@ -716,8 +716,8 @@ static int msi_capability_init(struct pc
  entry[i].msi_attrib.type = PCI_CAP_ID_MSI;
  entry[i].msi_attrib.is_64 = is_64bit_address(control);
  entry[i].msi_attrib.entry_nr = i;
 +entry[i].msi_attrib.host_masked =
  entry[i].msi_attrib.maskbit = is_mask_bit_support(control);
 -entry[i].msi_attrib.host_masked = 1;
  entry[i].msi_attrib.guest_masked = 0;
  entry[i].msi_attrib.pos = pos;
  if ( entry[i].msi_attrib.maskbit )





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

Re: [Xen-devel] [DOCS DAY] [PATCH for-4.6 0/5] Cleanup of docs spread throughout the tree

[Wei Liu]

On Wed, Aug 26, 2015 at 10:09:46AM +0100, Andrew Cooper wrote:
 After this series, I don't believe there are any docs remaining out of
 the docs/ subtree.
 
 The three manpages moved have been converted from ?roff to POD to match
 all our other manpages
 
 Andrew Cooper (5):
   docs: Move misc README's into docs/misc/
   docs: Move xentop.1 to docs/man/xentop.pod.1
   docs: Move xentrace_format.1 to docs/man/xentrace_format.pod.1
   docs: Support for generating man(8) pages
   docs: Move xentrace.8 to docs/man/xentrace.pod.8
 

Whole series:

Acked-by: Wei Liu wei.l...@citrix.com

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

Re: [Xen-devel] [PATCH V4 2/4] x86/xsaves: enable xsaves/xrstors in xen

[Jan Beulich]

 On 25.08.15 at 12:54, shuai.r...@linux.intel.com wrote:
 @@ -896,9 +897,28 @@ long arch_do_domctl(
  ret = -EFAULT;
  
  offset += sizeof(v-arch.xcr0_accum);
 -if ( !ret  copy_to_guest_offset(evc-buffer, offset,
 -  (void *)v-arch.xsave_area,
 -  size - 2 * sizeof(uint64_t)) )
 +
 +if ( cpu_has_xsaves )
 +{

There is not point in entering this code when ret != 0.

 +xsave_area = xmalloc_bytes(size);
 +if ( !xsave_area )
 +{
 +ret = -ENOMEM;
 +goto vcpuextstate_out;

As can even be seen from the patch context, this bypasses the
vcpu_unpause().

 +}
 +
 +save_xsave_states(v, xsave_area,
 +  evc-size - 2*sizeof(uint64_t));
 +
 +if ( !ret  copy_to_guest_offset(evc-buffer, offset,
 +   xsave_area, size -
 +   2 * sizeof(uint64_t)) )
 + ret = -EFAULT;
 + xfree(xsave_area);
 +   }
 +   else if ( !ret  copy_to_guest_offset(evc-buffer, offset,
 + (void *)v-arch.xsave_area,
 + size - 2 * 
 sizeof(uint64_t)) )
  ret = -EFAULT;
  
  vcpu_unpause(v);
 @@ -954,8 +974,12 @@ long arch_do_domctl(
  v-arch.xcr0_accum = _xcr0_accum;
  if ( _xcr0_accum  XSTATE_NONLAZY )
  v-arch.nonlazy_xstate_used = 1;
 -memcpy(v-arch.xsave_area, _xsave_area,
 -   evc-size - 2 * sizeof(uint64_t));
 +if ( cpu_has_xsaves )
 +load_xsave_states(v, (void *)_xsave_area,

Casts like this and ...

 +  evc-size - 2*sizeof(uint64_t));
 +else
 +memcpy(v-arch.xsave_area, (void *)_xsave_area,
 +   evc-size - 2 * sizeof(uint64_t));
  vcpu_unpause(v);
  }
  else
 --- a/xen/arch/x86/hvm/hvm.c
 +++ b/xen/arch/x86/hvm/hvm.c
 @@ -2148,8 +2148,12 @@ static int hvm_save_cpu_xsave_states(struct domain *d, 
 hvm_domain_context_t *h)
  ctxt-xfeature_mask = xfeature_mask;
  ctxt-xcr0 = v-arch.xcr0;
  ctxt-xcr0_accum = v-arch.xcr0_accum;
 -memcpy(ctxt-save_area, v-arch.xsave_area,
 -   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
 + if ( cpu_has_xsaves )
 +save_xsave_states(v, (void *)ctxt-save_area,

... this and ...

 +  size - offsetof(struct 
 hvm_hw_cpu_xsave,save_area));
 +else
 +memcpy(ctxt-save_area, v-arch.xsave_area,
 +   size - offsetof(struct hvm_hw_cpu_xsave, save_area));
  }
  
  return 0;
 @@ -2248,9 +2252,14 @@ static int hvm_load_cpu_xsave_states(struct domain *d, 
 hvm_domain_context_t *h)
  v-arch.xcr0_accum = ctxt-xcr0_accum;
  if ( ctxt-xcr0_accum  XSTATE_NONLAZY )
  v-arch.nonlazy_xstate_used = 1;
 -memcpy(v-arch.xsave_area, ctxt-save_area,
 -   min(desc-length, size) - offsetof(struct hvm_hw_cpu_xsave,
 -   save_area));
 +if ( cpu_has_xsaves )
 +load_xsave_states(v, (void *)ctxt-save_area,

... this are bogus and should be avoided if at all possible.

 --- a/xen/arch/x86/i387.c
 +++ b/xen/arch/x86/i387.c
 @@ -309,7 +309,11 @@ int vcpu_init_fpu(struct vcpu *v)
  return rc;
  
  if ( v-arch.xsave_area )
 +{
  v-arch.fpu_ctxt = v-arch.xsave_area-fpu_sse;
 +if ( cpu_has_xsaves )

Why (only) dependent on XSAVES and not (also) XSAVEC?

 --- a/xen/arch/x86/traps.c
 +++ b/xen/arch/x86/traps.c
 @@ -936,9 +936,10 @@ void pv_cpuid(struct cpu_user_regs *regs)
  if ( regs-_ecx == 1 )
  {
  a = XSTATE_FEATURE_XSAVEOPT |
 - XSTATE_FEATURE_XSAVEC |
 - (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 - (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0);
 + XSTATE_FEATURE_XSAVEC;
 +  /* PV guest will not support xsaves. */
 + /* (cpu_has_xgetbv1 ? XSTATE_FEATURE_XGETBV1 : 0) |
 + (cpu_has_xsaves ? XSTATE_FEATURE_XSAVES : 0); */

As already said to Andrew - fine for XSAVES, but why also for
XGETBV1?

 --- a/xen/arch/x86/xstate.c
 +++ b/xen/arch/x86/xstate.c
 @@ -214,6 +214,11 @@ void xsave(struct vcpu *v, uint64_t mask)
  typeof(ptr-fpu_sse.fip.sel) fcs = ptr-fpu_sse.fip.sel;
  typeof(ptr-fpu_sse.fdp.sel) fds = ptr-fpu_sse.fdp.sel;
  
 +if ( cpu_has_xsaves )
 +asm volatile ( .byte 0x48,0x0f,0xc7,0x2f
 +   : =m (*ptr)
 +   

Re: [Xen-devel] [PATCH v5 21/22] xen/arm: ITS: Generate ITS node for Dom0

[Julien Grall]

Hi Vijay,

On 26/08/2015 05:40, Vijay Kilari wrote:

+{
+fdt32_t phandle = gic_get_msi_handle();
+DPRINT( Set msi-parent(ITS) phandle 0x%x\n,phandle);
+fdt_property(kinfo-fdt, prop-name, (void *)phandle,
+ sizeof(phandle));
+continue;
+}
+
   res = fdt_property(kinfo-fdt, prop-name, prop_data, prop_len);

   xfree(new_data);
@@ -875,6 +888,10 @@ static int make_gic_node(const struct domain *d, void
*fdt,
   return res;

   res = fdt_end_node(fdt);
+if ( res )
+return res;
+
+res = gic_its_hwdom_dt_node(d, node, fdt);



Can you explain why you didn't follow my suggestion to plumb the ITS node
creation in gic_hwdow_dt_node? IHMO there is no need of new callback.

Furthermore the call is misplaced. You will end up to have a DT looking like

gic {
}

gic-its {
}

rather than

gic {
   gic-its {
   }
}


  As discussed, I have tried to generate ITS node inside gic node and call
fdt_end_node() for gic after generating ITS node. But dom0 fails to
find ITS node in the generated device tree. Any clue?


I can't give any clue without any log from Linux or code you've written...

I still think that your previous code is wrong (see 
Documentation/devicetree/bindings/arm/gic-v3.txt in Linux tree), because 
fdt_end_node of the parent should be called after all the children has 
been created i.e


fdt_begin_node(fdt, gic);

/* properties of the gic node */

fdt_begin_node(fdt, ITS);

/* properties of the ITS node */

fdt_end_node(fdt); // End of ITS
fdt_end_node(fdt); // End of GIC

Note that *all* the properties of the GIC node should have been written 
before creating the children nodes. Otherwise the device tree is 
considered as invalid.


Regards,

--
Julien Grall

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

Re: [Xen-devel] Design doc of adding ACPI support for arm64 on Xen - version 4

[Julien Grall]

Hi,

Sorry for the late answer.

On 20/08/2015 19:25, Shannon Zhao wrote:

On 2015/8/20 22:06, Jan Beulich wrote:

On 20.08.15 at 14:56, shannon.z...@linaro.org wrote:




On 2015/8/20 17:30, Jan Beulich wrote:

On 20.08.15 at 05:41, zhaoshengl...@huawei.com wrote:

On 2015/8/19 22:05, Jan Beulich wrote:

On 19.08.15 at 14:13, zhaoshengl...@huawei.com wrote:

1. Create minimal DT to pass required information to Dom0
--
Since there are no legacy interfaces like x86 for Dom0 to get the
booting required information on ARM, here we use the minimal DT which is
used by UEFI stub communicating with Linux kernel as well.

The UEFI stub is a feature that extends the Image/zImage into a valid
UEFI PE/COFF executable, including a loader application that makes it
possible to load the kernel directly from the UEFI shell, boot menu, or
one of the lightweight bootloaders like Gummiboot or rEFInd.

The kernel image built with stub support remains a valid kernel image
for booting in non-UEFI environments and the UEFI stub will be jumped
for non-UEFI environments.


Isn't this backwards? I.e. ...


Sorry, what do you mean here?
It's used for backwards compatibility. The reason I mention it here is
to explain that Xen acts as a EFI stub which creates a minimal DT and
load kernel image. Even though the kernel image built with EFI stub
which will be jumped, the kernel could boot well as before.


To me what you and Julien replied contradicts one another: You say
it's Xen to create these DT tags, whereas he assures me that these
tags are Linux internal ones.



I think What Julien said is to explain that the DT properties are used
between EFI stub and kernel image which are built together. So if we
change the names in Linux, it won't break backward compatibility.

I'll explain What I mean here. If not right, please fix me.
Firstly, Xen doesn't offer a (complete) firmware for Dom0, so it can't
load EFI stub, then EFI stub loads the kernel image. Therefore, there
are no chance to create the DT which we want to use it to pass the uefi
information.
Secondly, we make Xen act like a EFI stub to create the DT which could
pass the information to Dom0. When we load kernel image, the kernel will
call efi_get_fdt_params to get the information from the DT just like the
DT is created by EFI stub for kernel.


So can the two of you please sort out whether these are Linux
internal tags (which Xen has no business generating, or even
knowing of) or some form of publicly documented interface?


They are Linux internal tags. But to support Xen ACPI on ARM, we just
reuse the existing mechanism to pass the information to Dom0.


My previous mail was unclear, sorry. I was explaining the current usage 
of those properties because you seemed to be concern about the backward 
compatibility.


We'd like to formalize those properties in order to use them to pass 
information between Xen and the kernel image.


This would avoid us to create a Xen specific entry path in the kernel 
and use the non-EFI one (also used by the EFI stub) and make easier to 
support new DOM0 OS (for instance FreeBSD).


So I totally agree with Shannon mails.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] xen: arm: Support 32MB frametables

[Julien Grall]

Hi Chris,

On 21/08/2015 14:30, Chris Brand wrote:

setup_frametable_mappings() rounds frametable_size up to a multiple
of 32MB. This is wasteful on systems with less than 4GB of RAM,
although it does allow the contig bit to be set in the PTEs.

Where the frametable is less than 32MB in size, instead round up
to a multiple of 2MB, not setting the contig bit in the PTEs.

Signed-off-by: Chris Brand chris.br...@broadcom.com


Reviewed-by: Julien Grall julien.gr...@citrix.com

Regards,

--
Julien Grall

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

Re: [Xen-devel] [Draft B] Boot ABI for HVM guests without a device-model

[Roger Pau Monné]

El 26/08/15 a les 14.18, Andrew Cooper ha escrit:
 On 26/08/15 12:48, Roger Pau Monné wrote: 
 ELFNOTE(Xen, XEN_ELFNOTE_FEATURES,  .asciz, 
 writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel)
 ELFNOTE(Xen, XEN_ELFNOTE_SUPPORTED_FEATURES,.long ((1  
 XENFEAT_writable_page_tables) | \
(1  
 XENFEAT_auto_translated_physmap) | \
(1  
 XENFEAT_supervisor_mode_kernel) | \
(1  
 XENFEAT_hvm_callback_vector))
 
 Can we see about fixing the overloading of XENFEAT_supervisor_mode_kernel ?
 
 IMO it should be relegated to history.  It was an old,
 not-fully-implemented pv feature (subsequently removed completely) which
 is not relevant to HVM guests.

Maybe we can get rid of both XEN_ELFNOTE_FEATURES and
XEN_ELFNOTE_SUPPORTED_FEATURES if the kernel only supports PVH?

Roger.


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

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Chen, Tiejun]

On 8/27/2015 12:19 AM, Malcolm Crossley wrote:

On 25/08/15 15:43, Konrad Rzeszutek Wilk wrote:

On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:

On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:

Hi everyone,
I saw some people passingly mention this on the list before but just in
case it has been missed, my serial is also being spammed with the following
printouts with both Xen 4.6 RC1 and the latest staging build:

...
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
2610742000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
...





I think this problem is caused by missing IOMMU mappings for the RMRR regions
if the domain does not have shared EPT enabled. This includes PV Dom 0.


I don't think this is relevant to current problem.



I have posted a patch to fix the issue:

http://lists.xen.org/archives/html/xen-devel/2015-08/msg02090.html



And we already fixed this on 4.6.

Thanks
Tiejun





What's your platform? BDW? And how much memory is set to your guest OS?


Is see this as well. But oddly enough - only when I use the AMT feature
(normally I just use serial console on the machine).

The platform is /DQ67SW, BIOS
SWQ6710H.86A.0066.2012.1105.1504 11/05/2012

There is no guest OS - this is initial domain. And I boot with 2GB:
 Released 0 page(s)

Xen: [mem 0x-0x00099fff] usable
Xen: [mem 0x0009a800-0x000f] reserved
Xen: [mem 0x0010-0x1fff] usable
Xen: [mem 0x2000-0x201f] reserved
Xen: [mem 0x2020-0x3fff] usable
Xen: [mem 0x4000-0x401f] reserved
Xen: [mem 0x4020-0x80465fff] usable
Xen: [mem 0x80466000-0x9e855fff] unusable
Xen: [mem 0x9e856000-0x9e85efff] ACPI data
Xen: [mem 0x9e85f000-0x9e8a9fff] ACPI NVS
Xen: [mem 0x9e8aa000-0x9e8b1fff] unusable
Xen: [mem 0x9e8b2000-0x9e9a4fff] reserved
Xen: [mem 0x9e9a5000-0x9e9a6fff] unusable
Xen: [mem 0x9e9a7000-0x9ebc5fff] reserved
Xen: [mem 0x9ebc6000-0x9ebc6fff] unusable
Xen: [mem 0x9ebc7000-0x9ebd6fff] reserved
Xen: [mem 0x9ebd7000-0x9ebf4fff] ACPI NVS
Xen: [mem 0x9ebf5000-0x9ec18fff] reserved
Xen: [mem 0x9ec19000-0x9ec5bfff] ACPI NVS
Xen: [mem 0x9ec5c000-0x9ee7bfff] reserved
Xen: [mem 0x9ee7c000-0x9eff] unusable
Xen: [mem 0x9f80-0xbf9f] reserved
Xen: [mem 0xfec0-0xfec00fff] reserved
Xen: [mem 0xfed1c000-0xfed3] reserved
Xen: [mem 0xfed9-0xfed91fff] reserved
Xen: [mem 0xfee0-0xfeef] reserved
Xen: [mem 0xff00-0x] reserved
Xen: [mem 0x0001-0x00043e5f] unusable



Just at first glance to fault address, this seems be issued from some
known erratas on BDS and SKL.


I am runnig v4.2-rc8.


Thanks
Tiejun


The device in question is an integrated Intel graphics card:

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)


Same device..


This is a sandy bridge device which doesn't support shared EPT for GPU device.




The only way I found to stop the messages from making my serial connection
useless was by assigning the device to xen-pciback.


This will cause the GPU to be reset and the reset stopped the GPU accessing the
RMRR region.



Cheers,
Tamas



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



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


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






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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 ovmf ba1806251ff8ff695175b92ab5732eadbcd2f72e
baseline version:
 ovmf b199d9418820b873d0e05190fe5dc947a6f72b14

Last test of basis60835  2015-08-22 21:41:56 Z4 days
Testing same since60869  2015-08-25 03:03:43 Z1 days1 attempts


People who touched revisions under test:
  Bob Feng bob.c.f...@intel.com
  Dandan Bi dandan...@intel.com
  Gary Ching-Pang Lin g...@suse.com
  Hess Chen hesheng.c...@intel.com
  Jiaxin Wu jiaxin...@intel.com
  Liming Gao liming@intel.com
  Qiu Shumin shumin@intel.com
  Ruiyu Ni ruiyu...@intel.com
  Star Zeng star.z...@intel.com

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=ba1806251ff8ff695175b92ab5732eadbcd2f72e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
ba1806251ff8ff695175b92ab5732eadbcd2f72e
+ branch=ovmf
+ revision=ba1806251ff8ff695175b92ab5732eadbcd2f72e
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
+ local b
+ local p
++ ./mg-list-all-branches
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ for b in '$(./mg-list-all-branches)'
+ case $b in
+ '[' xxen-4.0-testing = 

Re: [Xen-devel] [PATCH v2 for-4.6 2/2] docs: Migration feature document

[Jim Fehlig]

On 08/25/2015 04:40 AM, Andrew Cooper wrote:

Signed-off-by: Andrew Cooper andrew.coop...@citrix.com
---
v2:
  * %Revision and #History, following template review
  * Grammar fixes
---
  docs/features/migration.pandoc |  100 
  1 file changed, 100 insertions(+)
  create mode 100644 docs/features/migration.pandoc

diff --git a/docs/features/migration.pandoc b/docs/features/migration.pandoc
new file mode 100644
index 000..0fd227f
--- /dev/null
+++ b/docs/features/migration.pandoc
@@ -0,0 +1,100 @@
+% Migration
+% Revision 1
+
+\clearpage
+
+# Basics
+--- -
+Status: **Supported**
+
+  Architecture: x86
+
+ Component: Toolstack
+--- -
+
+# Overview
+
+Migration is a mechanism to move a virtual machine while the VM is
+running.  Live migration moves a running virtual machine between two
+physical servers, but the same mechanism can be used for non-live
+migrate (pause and copy) and suspend/resume from disk.


s/migrate/migration/ ?


+
+# User details
+
+No hardware requirements, although hypervisor logdirty support is
+required for live migration.
+
+From the command line, `xl migrate/save/restore` are the top level
+interactions.  e.g.
+
+xl create my-vm.cfg
+xl migrate my-vm localhost
+
+or
+
+xl create my-vm.cfg
+xl save my-vm /path/to/save/file
+xl restore /path/to/save/file
+
+Xen 4.6 sees the instruction of Migration v2.  There is no change for


Xen 4.6 sees the introduction of Migration v2.
Or, Xen 4.6 introduces Migration v2.


+people using `xl`, although the `libxl` API has had an extension.
+
+# Technical details
+
+Migration is formed of several layers.  `libxc` is responsible for the
+contents of the VM (ram, vcpus, etc) and the live migration loop, while
+`libxl` is responsible for items such as emulator state.
+
+The format of the migration v2 stream is specified in two documents, and
+is architecture neutral.  Compatibility with legacy streams is
+maintained via the `convert-legacy-stream` script which transforms a
+legacy stream into a migration v2 stream.
+
+* Documents
+* `docs/specs/libxc-migration-stream.pandoc`
+* `docs/specs/libxl-migration-stream.pandoc`
+* `libxc`
+* `tools/libxc/xc_sr_*.[hc]`
+* `libxl`
+* `tools/libxl/libxl_stream_{read,write}.c`
+* Scripts
+* `tools/python/xen/migration/*.py`
+* `tools/python/scripts/convert-legacy-stream`
+* `tools/python/scripts/verify-stream-v2`
+
+Users of the `libxl` API have a new parameter `stream_version` in
+`domain_restore_params` which is used to distinguish between legacy and
+v2 migration streams, and hence whether legacy conversion is required.


A question better asked when you posted the patches, but is there a way to 
detect if the receiver is V2 capable? I suspect sending a V2 stream to a 
receiver capable only of V1 is not advised :-).


Also, commit id introducing the change would be helpful info. Looks like 
3a9ace01 in this case.



+
+# Limitations
+
+Hypervisor logdirty support is incompatible with hardware passthrough,
+as IOMMU faults cannot be used to track writes.
+
+While not a bug in migration specifically, VMs are very sensitive to
+changes in cpuid information, and cpuid levelling support currently has
+its issues.  Extreme care should be taken when migrating VMs between
+non-identical CPUs until the cpuid levelling improvements are complete.
+
+# Areas for improvement
+
+* Arm support
+* Linear P2M support for x86 PV
+* Live looping parameters


* cpuid levelling

Regards,
Jim


+
+# Known issues
+
+* x86 HVM guest physmap operations (not reflected in logdirty bitmap)
+* x86 HVM with PoD pages (attempts to map cause PoD allocations)
+* x86 HVM with nested-virt (no relevant information included in the
+  stream)
+* x86 PV ballooning (P2M marked dirty, target frame not marked)
+* x86 PV P2M structure changes (not noticed, stale mappings used)
+
+# History
+
+
+Date   Revision Version  Notes
+--   ---
+2015-10-24 1Xen 4.6  Document written
+--   ---



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

Re: [Xen-devel] [RFC v2 for-4.6 0/2] In-tree feature documentation

[Jim Fehlig]

On 08/25/2015 04:40 AM, Andrew Cooper wrote:

An issue which Xen has is an uncertain support statement for features.
Given the success seen with docs/misc/xen-command-line.markdown, and in
particular keeping it up to date, introduce a similar system for
features.

Patch 1 introduces a proposed template (and a makefile tweak to include
the new docs/features subdirectory), while patch 2 is a feature document
covering the topic of migration.

v2 Adds %Revision and #History table, following feedback from v1.

This is tagged RFC as I expect people to have different views as to what
is useful to include.  I would particilarly appreciate feedback on the
template before it starts getting used widely.

Lars: Does this look like a reasonable counterpart to your formal
support statement document?

Jim: Per your request at the summit for new information, is patch 2
suitable?


Yes. It provides excellent info, with pointers to dig deeper for those 
interested.

Your proposal does raise the bar for feature contribution, but I'm not active 
enough in the Xen community to know if folks are supportive of the additional 
overhead. Would new features require a feature doc before committing?


My comment at the summit was more along the lines of a summary of libxl changes 
for external consumers. A libxl interface changelog of sorts, for consumers 
unable to keep up with xen-devel. But I also noted this may be a personal 
problem. You've already mentioned 'git log' :-).


Regards,
Jim


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

Re: [Xen-devel] [PATCH for 4.6] VT-d: Create IOMMU mappings for RMRR regions if shared EPT is not being used

[Chen, Tiejun]

This kind of issue is already gone.

https://www.mail-archive.com/xen-devel@lists.xen.org/msg32464.html

Thanks
Tiejun

On 8/26/2015 11:49 PM, Malcolm Crossley wrote:

Add RMRR 1:1 IOMMU mappings to IOMMU page tables if EPT page table are not being
shared with the IOMMU.

This is a regression in behaviour versus Xen 4.5.

Signed-off-by: Malcolm Crossley malcolm.cross...@citrix.com
---
  xen/drivers/passthrough/vtd/iommu.c | 23 ---
  1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 836aed5..89de741 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1839,8 +1839,16 @@ static int rmrr_identity_mapping(struct domain *d, 
bool_t map,

  while ( base_pfn  end_pfn )
  {
-if ( clear_identity_p2m_entry(d, base_pfn) )
-ret = -ENXIO;
+if ( iommu_use_hap_pt(d) )
+{
+if ( clear_identity_p2m_entry(d, base_pfn) )
+ret = -ENXIO;
+}
+else
+{
+if ( intel_iommu_unmap_page(d, base_pfn) )
+ret = -ENXIO;
+}
  base_pfn++;
  }

@@ -1855,7 +1863,16 @@ static int rmrr_identity_mapping(struct domain *d, 
bool_t map,

  while ( base_pfn  end_pfn )
  {
-int err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
+int err;
+if ( iommu_use_hap_pt(d) )
+{
+err = set_identity_p2m_entry(d, base_pfn, p2m_access_rw, flag);
+}
+else
+{
+err = intel_iommu_map_page(d, base_pfn, base_pfn,
+   IOMMUF_readable|IOMMUF_writable);
+}

  if ( err )
  return err;



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

Re: [Xen-devel] VT-d faults with Integrated Intel graphics on 4.6

[Chen, Tiejun]

On 8/25/2015 10:43 PM, Konrad Rzeszutek Wilk wrote:

On Tue, Aug 25, 2015 at 02:55:31PM +0800, Chen, Tiejun wrote:

On 8/25/2015 8:19 AM, Tamas K Lengyel wrote:
Hi everyone,
I saw some people passingly mention this on the list before but just in
case it has been missed, my serial is also being spammed with the following
printouts with both Xen 4.6 RC1 and the latest staging build:

...
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
33487d7000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 06 - PTE Read access is not set
(XEN) [VT-D]DMAR:[DMA Read] Request device [:00:02.0] fault addr
2610742000, iommu reg = 82c000201000
(XEN) [VT-D]DMAR: reason 07 - Next page table ptr is invalid
...


What's your platform? BDW? And how much memory is set to your guest OS?


Is see this as well. But oddly enough - only when I use the AMT feature
(normally I just use serial console on the machine).

The platform is /DQ67SW, BIOS
SWQ6710H.86A.0066.2012.1105.1504 11/05/2012

There is no guest OS - this is initial domain. And I boot with 2GB:
  Released 0 page(s)

Xen: [mem 0x-0x00099fff] usable
Xen: [mem 0x0009a800-0x000f] reserved
Xen: [mem 0x0010-0x1fff] usable
Xen: [mem 0x2000-0x201f] reserved
Xen: [mem 0x2020-0x3fff] usable
Xen: [mem 0x4000-0x401f] reserved
Xen: [mem 0x4020-0x80465fff] usable
Xen: [mem 0x80466000-0x9e855fff] unusable
Xen: [mem 0x9e856000-0x9e85efff] ACPI data
Xen: [mem 0x9e85f000-0x9e8a9fff] ACPI NVS
Xen: [mem 0x9e8aa000-0x9e8b1fff] unusable
Xen: [mem 0x9e8b2000-0x9e9a4fff] reserved
Xen: [mem 0x9e9a5000-0x9e9a6fff] unusable
Xen: [mem 0x9e9a7000-0x9ebc5fff] reserved
Xen: [mem 0x9ebc6000-0x9ebc6fff] unusable
Xen: [mem 0x9ebc7000-0x9ebd6fff] reserved
Xen: [mem 0x9ebd7000-0x9ebf4fff] ACPI NVS
Xen: [mem 0x9ebf5000-0x9ec18fff] reserved
Xen: [mem 0x9ec19000-0x9ec5bfff] ACPI NVS
Xen: [mem 0x9ec5c000-0x9ee7bfff] reserved
Xen: [mem 0x9ee7c000-0x9eff] unusable
Xen: [mem 0x9f80-0xbf9f] reserved
Xen: [mem 0xfec0-0xfec00fff] reserved
Xen: [mem 0xfed1c000-0xfed3] reserved
Xen: [mem 0xfed9-0xfed91fff] reserved
Xen: [mem 0xfee0-0xfeef] reserved
Xen: [mem 0xff00-0x] reserved
Xen: [mem 0x0001-0x00043e5f] unusable



Just at first glance to fault address, this seems be issued from some


As you see those fault addresses are out of the normal memory range  here.


known erratas on BDS and SKL.


I am runnig v4.2-rc8.


So I really doubt this is related to some erratas. Currently the 
pre-fetch unit of IOMMU unit dedicated to IGD can't work well on some 
platforms, so you can see these wired faults.


Thanks
Tiejun



Thanks
Tiejun

The device in question is an integrated Intel graphics card:

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core
Processor Family Integrated Graphics Controller (rev 09)


Same device..


The only way I found to stop the messages from making my serial connection
useless was by assigning the device to xen-pciback.

Cheers,
Tamas



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


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




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

Re: [Xen-devel] [osstest test] 60719: tolerable FAIL - PUSHED

[Jim Fehlig]

On 08/21/2015 02:05 AM, Ian Campbell wrote:

On Wed, 2015-08-19 at 00:18 +, osstest service owner wrote:

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
[...]
  test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
  test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass

All of the pending changes are now in production, the libvirt migration
test is now failing in the production colo with:

2015-08-18 19:07:36 Z executing ssh ... root@172.16.144.34 virsh migrate --live 
debian.guest.osstest xen+ssh://pinot1
error: unable to connect to 'pinot1.test-lab.xenproject.org:49152': Invalid 
argument


This sounds a bit like an issue discussed in the Redhat libvirt troubleshooting 
FAQ

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Virtualization_Deployment_and_Administration_Guide/sect-Troubleshooting-Common_libvirt_errors_and_troubleshooting.html#sect-Migration_fails_with_Error_unable_to_resolve_address



 From the _controller_ pinot1.test-lab.xenproject.org is valid:

 ianc@osstest:~$ ping -c 1 pinot1.test-lab.xenproject.org
 PING pinot1.test-lab.xenproject.org (172.16.144.35) 56(84) bytes of data.
 64 bytes from 172.16.144.35: icmp_req=1 ttl=64 time=0.258 ms

 --- pinot1.test-lab.xenproject.org ping statistics ---
 1 packets transmitted, 1 received, 0% packet loss, time 0ms
 rtt min/avg/max/mdev = 0.258/0.258/0.258/0.000 ms

Maybe the test boxes are seeing a different view of DNS, but I doubt
it. Also I note that the failure is Invalid argument and not Unknown
host.


Right. If it is a DNS issue, error handling in the libvirt libxl migration code 
needs improving.


Regards,
Jim


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