[Xen-devel] Faulting linear address??

[Minjun Hong]

Hello~
I think this might be duplicate issue but, I have not resolved for long
time.
So, please understand this post generously.
First, I should explain my history.

1) I worked on the scheduler(credit scheduler) and I had a kernel panic by
my modification.
2) I tried to get any information for debugging so that, I used serial
console and could gain the serial logs like following:

(XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
(XEN) CPU:2
(XEN) RIP:e008:[] csched_schedule+0x373/0x1180
(XEN) RFLAGS: 00010086   CONTEXT: hypervisor
(XEN) rax:    rbx: 830087ffa000   rcx: 830461d2
(XEN) rdx: 830088002c98   rsi: 830461d2   rdi: 
(XEN) rbp: 830461ce2ae0   rsp: 830461d27d10   r8:  001e582339ec
(XEN) r9:  0004   r10: 003c   r11: 0004
(XEN) r12: 0001   r13: 82d0803f26a0   r14: 830461c53000
(XEN) r15:    cr0: 8005003b   cr4: 003526f0
(XEN) cr3: 86077000   cr2: 830088002c98
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen stack trace from rsp=830461d27d10:
(XEN)830461d03950 82d0804081e0 830461c74068 830461d27de0
(XEN)830461c24c30 830461cec800 82d0804081e0 00060002
(XEN)830461ce29d0 830461d2 82d0804081e0 830461d3a720
(XEN)0002 830461d3a700 00c0 830461d27dd0
(XEN)830461d27e68 82d080408180 001e5c106499 01c9c380
(XEN)  8300864e3000 8302e1596fb0
(XEN)830461d27dd0 830461d27dd0 004b 
(XEN)  830461d3a738 8300864e3000
(XEN)82d0804081e0 830461d2e068 001e5c106499 830461d2e060
(XEN)82d0803f26a0 82d080128cb3 001e 830461d2e080
(XEN)82d080279944 82d08015f295 001e5c0504ce 830461d3ad80
(XEN)001e5c1054ba 82d08012f64e 82d0803f26a0 
(XEN)82d0803df880 0001 82d0803df780 
(XEN)830461d2 82d08012c03c  
(XEN)830461d2 830461d2e068 001e5b762541 830461d2e060
(XEN)82d0803f26a0 82d080162e3a  8300864e3000
(XEN)8300864e3000 8800f8bbbfd8  8800f8bbbfd8
(XEN)0003 8800f8bbbec0  0246
(XEN)7ff0   
(XEN)810013aa 0001  0001
(XEN) Xen call trace:
(XEN)[] csched_schedule+0x373/0x1180
(XEN)[] schedule+0xf3/0x590
(XEN)[] reprogram_timer+0x75/0xe0
(XEN)[] timer_softirq_action+0x13e/0x210
(XEN)[] __do_softirq+0x7c/0xd0
(XEN)[] idle_loop+0x3a/0x70
(XEN)
(XEN) Pagetable walk from 830088002c98:
(XEN)  L4[0x106] = 86075063 
(XEN)  L3[0x002] = 86071063 
(XEN)  L2[0x040] =  
(XEN)
(XEN) 
(XEN) Panic on CPU 2:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=]
(XEN) Faulting linear address: 830088002c98
(XEN) 
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.

I want to know where I should start debugging from.
However, although I'm using serial console, I could get not enough clues
only from the kernel log:
1) I could figure out what line and file caused the panic by its call
trace, but it is too rough so it does not help me.
2) What linear address brings about this situation; 'Faulting linear
address', but it is just an address and not recognizable something that
human cannot read.

I think, literally, the 'Faulting linear address' is key point because I
heard that it represents bad address that I should never access.
With the pointer(bad address), is there any way to figure out its real data
or more accurate line in C source code?
If you have any other approach that can be used in some cases like this,
could you please give me the guide?

I hope your help.
Thank you!
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 113140: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9cb0d1d0eb3a9e4d8b97432c9246cdfbb3b0309
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   29 attempts
Testing same since   113131  2017-09-07 16:01:58 Z0 days6 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 368 lines long.)

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

Re: [Xen-devel] [BUG] PV domU Arch Linux kernel 4.12 with CONFIG_INTEL_ATOMISP=y guest crashes

[Juergen Gross]

On 08/09/17 05:40, John Thomson wrote:
> Hi,
> I get a PV domU kernel crash booting Arch Linux 4.12.
> 
> Not sure if this is more relevant to Xen, the Linux kernel or
> distributions.
> 
> Running xen-4.9.0 on Arch Linux x86_64 with kernel 4.12.10.
> Booting UEFI -> grub2 -> linux -> reboot -> grub2 multiboot2 -> xen
> 
> My test was booting the dom0 kernel and ramdisk in a domU PV guest.
> I compiled the 4.12.10 Linux kernel with and without
> CONFIG_INTEL_ATOMISP
> With CONFIG_INTEL_ATOMISP=n, my guest booted without issue.

Don't configure it. It is broken:

Instead of probing whether the device is installed or not the driver's
probe function just assumes the device is present and maps a hard coded
physical address and begins working on that, regardless whether the
mapped address belongs to the correct device type or not.


Juergen

> 
> XenParavirtOpsHelp needed files attached.
> 
> Easily reproduced for me by booting the 201708 Arch Linux ISO.
> http://mirror.rackspace.com/archlinux/iso/2017.08.01/archlinux-2017.08.01-x86_64.iso
> The Arch Linux 201707 install disk with kernel 4.11 boots.
> http://mirror.rackspace.com/archlinux/iso/2017.07.01/archlinux-2017.07.01-x86_64.iso
> 
> xl config:
> name = 'arch201708.cfg'
> memory = 512
> disk=['archlinux-2017.08.01-x86_64.iso, , xvdc, cdrom']
> bootloader='pygrub'
> kernel = 'arch/boot/x86_64/vmlinuz'
> ramdisk = 'arch/boot/x86_64/archiso.img'
> cmdline = 'archisobasedir=arch archisolabel=ARCH_201708'
> 
> Arch ISO 201708 guest console:
> 
> [0.104674] xen:manage: Unable to read sysrq code in control/sysrq
> [0.106995] dmi: Firmware registration failed.
> [0.127871] intel_mid_msgbus_init: Error: msgbus PCI handle NULL
> [2.986550] BUG: unable to handle kernel paging request at
> c900400e5060
> [2.986563] IP: vlv2_plat_configure_clock+0x3b/0xa0
> [2.986565] PGD 1ff05067 
> [2.986566] P4D 1ff05067 
> [2.986567] PUD 1e982067 
> [2.986569] PMD 1e983067 
> [2.986578] PTE 0
> [2.986580] 
> [2.986583] Oops:  [#1] PREEMPT SMP
> [2.986585] Modules linked in:
> [2.986588] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.3-1-ARCH
> #1
> [2.986591] task: 88001e9eb900 task.stack: c900400c8000
> [2.986595] RIP: e030:vlv2_plat_configure_clock+0x3b/0xa0
> [2.986598] RSP: e02b:c900400cbbe0 EFLAGS: 00010246
> [2.986601] RAX:  RBX: c900400e5060 RCX:
> 01d5dfff
> [2.986604] RDX: 88001e9eb900 RSI: 0002 RDI:
> 81ac9980
> [2.986607] RBP: c900400cbbf0 R08: 1000 R09:
> 811d6101
> [2.986610] R10: 7ff0 R11: e8ff R12:
> 0002
> [2.986613] R13:  R14:  R15:
> 
> [2.986620] FS:  () GS:88001f80()
> knlGS:
> [2.986623] CS:  e033 DS:  ES:  CR0: 80050033
> [2.986627] CR2: c900400e5060 CR3: 01a09000 CR4:
> 00042660
> [2.986632] Call Trace:
> [2.986638]  vlv2_plat_clk_probe+0x3f/0x70
> [2.986643]  platform_drv_probe+0x3b/0xa0
> [2.986647]  driver_probe_device+0x2ff/0x450
> [2.986651]  __device_attach_driver+0x83/0x100
> [2.986655]  ? __driver_attach+0xe0/0xe0
> [2.986659]  bus_for_each_drv+0x69/0xb0
> [2.986663]  __device_attach+0xdd/0x160
> [2.986667]  device_initial_probe+0x13/0x20
> [2.986670]  bus_probe_device+0x92/0xa0
> [2.986674]  device_add+0x451/0x690
> [2.986678]  platform_device_add+0x10d/0x270
> [2.986683]  ? set_debug_rodata+0x17/0x17
> [2.986686]  platform_device_register_full+0xfe/0x110
> [2.986692]  ? vlv2_plat_clk_init+0x19/0x19
> [2.986696]  vlv2_plat_clk_init+0x48/0x82
> [2.986700]  do_one_initcall+0x50/0x190
> [2.986704]  kernel_init_freeable+0x186/0x214
> [2.986709]  ? rest_init+0x90/0x90
> [2.986713]  kernel_init+0xe/0x100
> [2.986716]  ret_from_fork+0x25/0x30
> [2.986720] Code: 47 83 fe 02 41 89 f4 77 67 48 8b 05 60 49 84 00 48
> 85 c0 74 48 c1 e7 02 48 63 ff 48 8d 1c 38 48 c7 c7 80 99 ac 81 e8 95 0f
> 15 00 <8b> 03 83 e0 fc 44 09 e0 89 03 48 c7 c7 80 99 ac 81 e8 6f 09 15 
> [2.986745] RIP: vlv2_plat_configure_clock+0x3b/0xa0 RSP:
> c900400cbbe0
> [2.986749] CR2: c900400e5060
> [2.986755] ---[ end trace 1147de716422f210 ]---
> [2.986763] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0009
> [2.986763] 
> [2.986771] Kernel Offset: disabled
> 
> 
> Arch Linux bug:
> https://bugs.archlinux.org/task/55447
> 
> This bug was also seen on Ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711298
> 
> Thanks,
> --
>   John Thomson
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 


___
Xen-devel mailing list
Xen-devel@lists.xen.org

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Roman Shaposhnik]

At a first glance it this appears to be an awesome proposal! I'll give
it a more thorough read over the weekend.

Thanks,
Roman.

On Thu, Sep 7, 2017 at 3:25 AM, Felipe Huici  wrote:
> Dear all,
>
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
>
> Thanks,
>
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
>
>
> PROPOSAL: Unicore
> =
>
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
>
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
>
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
>
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
>
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>
>
> [Attachment: unicore-oneslider.pdf]
>
>
> Figure 1. Unicore architecture.
>
>
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount of customization for the unikernel.
>
>
> The Unicore build tool is in charge of compiling the application and the
> selected libraries together to create a binary for a specific platform and
> architecture (e.g., Xen on x86_64). The tool is currently inspired by
> Linux’s kconfig system and consists of a set of Makefiles. It allows users
> to select libraries, to configure them, and to warn them when library
> dependencies are not met. In addition, the tool can also simultaneously
> generate binaries for multiple platforms.
>
>
> As an example, imagine a user wanting to generate 

[Xen-devel] [xen-unstable-smoke test] 113138: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail pass in 
113136

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9cb0d1d0eb3a9e4d8b97432c9246cdfbb3b0309
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   28 attempts
Testing same since   113131  2017-09-07 16:01:58 Z0 days5 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs
broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken

Not pushing.

(No revision log; it would be 368 lines long.)

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

[Xen-devel] [xen-unstable test] 113122: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113030
 build-arm64-pvops 3 capture-logsbroken like 113030
 build-arm64   2 hosts-allocate  broken like 113030
 build-arm64   3 capture-logsbroken like 113030
 build-arm64-xsm   2 hosts-allocate  broken like 113030
 build-arm64-xsm   3 capture-logsbroken like 113030
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 113030
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113024
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113024
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113024
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113024
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113030
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 113030
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113030
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a
baseline version:
 xen  

[Xen-devel] [xen-unstable-smoke test] 113136: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9cb0d1d0eb3a9e4d8b97432c9246cdfbb3b0309
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   27 attempts
Testing same since   113131  2017-09-07 16:01:58 Z0 days4 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 368 lines long.)

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

[Xen-devel] [linux-4.9 test] 113121: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113014
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
113028

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 113028
 build-arm64   2 hosts-allocate  broken like 113028
 build-arm64-pvops 2 hosts-allocate  broken like 113028
 build-arm64   3 capture-logsbroken like 113028
 build-arm64-pvops 3 capture-logsbroken like 113028
 build-arm64-xsm   3 capture-logs broken never pass
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 113028
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail like 113028
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113028
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113028
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux

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

[Stefano Stabellini]

On Thu, 31 Aug 2017, George Dunlap wrote:
> +### Direct-boot kernel image format
> +
> +Supported, x86: bzImage
> +Supported, ARM32: zImage
> +Supported, ARM64: Image [XXX - Not sure if this is correct]

On ARM64 it's called Image.gz.


> +Format which the toolstack accept for direct-boot kernels
> +
> +### Qemu based disk backend (qdisk) for xl
> +
> +Status: Supported
> +
> +### Open vSwitch integration for xl
> +
> +Status: Supported
> +
> +### systemd support for xl
> +
> +Status: Supported
> +
> +### JSON support for xl
> +
> +Status: Preview
> +
> +### AHCI support for xl
> +
> +Status, x86: Supported
> +
> +### ACPI guest
> +
> +Status, ARM: Preview
> +
> +### PVUSB support for xl
> +
> +Status: Supported
> +
> +### HVM USB passthrough for xl
> +
> +Status, x86: Supported
> +
> +### QEMU backend hotplugging for xl
> +
> +Status: Supported
> +
> +### Soft-reset for xl
> +
> +Status: Supported
> +
> +### Virtual cpu hotplug
> +
> +Status, ARM: Supported
> +
> +## Toolstack/3rd party
> +
> +### libvirt driver for xl
> +
> +Status: Supported, Security support external
> +
> +Security support for libvirt is provided by the libvirt project.
> +See https://libvirt.org/securityprocess.html
> +
> +## Tooling
> +
> +### gdbsx
> +
> +Status, x86: Supported
> +
> +Debugger to debug ELF guests
> +
> +### vPMU
> +
> +Status, x86: Supported, Not security supported
> +
> +Virtual Performance Management Unit for HVM guests
> +
> +Disabled by default (enable with hypervisor command line option).
> +This feature is not security supported: see 
> http://xenbits.xen.org/xsa/advisory-163.html
> +
> +### Guest serial sonsole
> +
> +Status: Supported
> +
> +Logs key hypervisor and Dom0 kernel events to a file
> +
> +### xentrace
> +
> +Status, x86: Supported
> +
> +Tool to capture Xen trace buffer data
> +
> +### gcov
> +
> +Status: Supported, Not security supported
> +
> +## Memory Management
> +
> +### Memory Ballooning
> +
> +Status: Supported
> +
> +### Memory Sharing
> +
> +Status, x86 HVM: Preview
> +Status, ARM: Preview
> +
> +Allow sharing of identical pages between guests
> +
> +### Memory Paging
> +
> +Status, x86 HVM: Experimenal
> +
> +Allow pages belonging to guests to be paged to disk
> +
> +### Transcendent Memory
> +
> +Status: Experimental
> +
> +### Alternative p2m
> +
> +Status, x86: Preview
> +
> +Allows external monitoring of hypervisor memory using Intel EPT by allowing 
> to maintain multiple physical memory to machine physical mappings
> +
> +[XXX Should this be x86/Alternative p2m?]

No, the technology could be available on ARM.


> +## Resource Management
> +
> +### CPU Pools
> +
> +Status: Supported
> +
> +Groups physical cpus into distinct groups called "cpupools",
> +with each pool having the capability of using different schedulers and 
> scheduling properties.
> +
> +### Credit Scheduler
> +
> +Status: Supported
> +
> +The default scheduler, which is a weighted proportional fair share virtual 
> CPU scheduler.
> +
> +### Credit2 Scheduler
> +
> +Status: Supported
> +
> +Credit2 is a general purpose scheduler for Xen,
> +designed with particular focus on fairness, responsiveness and scalability
> +
> +### RTDS based Scheduler
> +
> +Status: Experimental
> +
> +A soft real-time CPU scheduler built to provide guaranteed CPU capacity to 
> guest VMs on SMP hosts
> +
> +### ARINC653 Scheduler
> +
> +Status: Supported, Not security supported
> +
> +A periodically repeating fixed timeslice scheduler. Multicore support is not 
> yet implemented.
> +
> +### Null Scheduler
> +
> +Status: Experimental
> +
> +A very simple, very static scheduling posicy that always schedules the same 
> vCPU(s) on the same pCPU(s). It is designed for maximum determinism and 
> minimum overhead on embedded platforms.

Can we say more than Experimental? I think it should be at least Tech
Preview.


> +### Numa scheduler affinity
> +
> +Status, x86: Supported
> +
> +Enables Numa aware scheduling in Xen
> +
> +## Scalability
> +
> +### 1GB/2MB super page support
> +
> +Status: Supported
> +
> +### x86/Deliver events to PVHVM guests using Xen event channels
> +
> +Status: Supported
> +
> +### Fair locks (ticket-locks)
> +
> +Status: Supported
> +
> +[XXX Is this host ticket locks?  Or some sort of guest PV ticket locks?  If 
> the former it doesn't make any sense to call it 'supported' because they're 
> either there or not.]
> +
> +## High Availability and Fault Tolerance
> +
> +### Live Migration, Save & Restore
> +
> +Status, x86: Supported
> +
> +### Remus Fault Tolerance
> +
> +Status: Experimental
> +
> +### COLO Manager
> +
> +Status: Experimental
> +
> +### vMCE
> +
> +Status, x86: Supported
> +
> +Forward Machine Check Exceptions to Appropriate guests
> +
> +## Virtual driver support, guest side
> +
> +### Blkfront
> +
> +Status, Linux: Supported
> +

Re: [Xen-devel] [PATCH v2] Fix ARM multiboot2 breaking Fedora.

[Daniel Kiper]

On Wed, Aug 30, 2017 at 12:26:28PM +0200, Daniel Kiper wrote:
> On Tue, Aug 29, 2017 at 04:40:51PM -0400, Konrad Rzeszutek Wilk wrote:
> > Since v1 
> > [http://lists.gnu.org/archive/html/grub-devel/2017-08/msg00073.html]
> >  - Fixed up patch with failing invocation,
> >  - Redid patch #2 per Daniel's instructions.
> >
> >
> > Hey,
> >
> > The first patch:
> >  [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command
> >
> > is a fix discovered on Fedora rawhide where I was surprised to see that
> > grub2-mkconfig would not create a configuration file anymore.
> >
> > The second patch has been posted in the past
> > (https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt)
> >
> >  [PATCH 2/2] Use grub-file to figure out whether multiboot2 should be
> >
> > and just allows us to multiboot2 instead of multiboot if the binary
> > supports it.
>
> LGMT. If there are no objections in a week or so I will apply both of them.

Applied!

Thanks,

Daniel

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

[Xen-devel] [xen-unstable-smoke test] 113135: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9cb0d1d0eb3a9e4d8b97432c9246cdfbb3b0309
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   26 attempts
Testing same since   113131  2017-09-07 16:01:58 Z0 days3 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 368 lines long.)

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

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

[Stefano Stabellini]

On Thu, 31 Aug 2017, Jan Beulich wrote:
> >>> On 31.08.17 at 12:27,  wrote:
> > vMCE: Is MCE an x86-only thing, or could this conceivably by extended
> > to ARM?
> 
> I think this can't be reasonably extended beyond x86 (and,
> considering their similar origin, ia64).

Yes, Jan is right. ARM has SErrors today, and might have something
better in the future, but it doubt they will be called MCEs anyway.

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

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

[Stefano Stabellini]

On Thu, 31 Aug 2017, Roger Pau Monne wrote:
> > +### ARM/Non-PCI device passthrough
> > +
> > +Status: Supported
> 
> I guess non-pci devices on ARM also use the IOMMU? (SMMU)

Yes, they do.


> > +### ARM/SMMU
> > +
> > +Status: Supported, with caveats
> > +
> > +Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not 
> > supported.
> 
> I'm not sure of the purpose of this sentence, it's quite clear that
> the SMMU is only supported if available. Also, I'm not sure this
> should be spelled out in this document, x86 doesn't have a VT-d or SVM
> section.

As George wrote, there are many SMMUs in the market for ARM based
platforms, not all of them of ARM design.

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Stefano Stabellini]

On Thu, 7 Sep 2017, Felipe Huici wrote:
> Dear all,
> 
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?

Only a couple of comments. I think this proposal is awesome, I want it
yesterday :)


> Thanks,
> 
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> 
> Figure 1. Unicore architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux; and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount of customization for the unikernel.
>  
> 
> The Unicore build tool is in charge of compiling the application and the
> selected libraries together to create a binary for a specific platform and
> architecture (e.g., Xen on x86_64). The tool is currently inspired by
> Linux’s kconfig system and consists of a set of Makefiles. It allows users
> to select libraries, to configure them, and to warn them when library
> dependencies are not met. In addition, the tool can also simultaneously
> generate binaries for multiple platforms.
> 
>  
> As an example, imagine a user wanting to generate a network driver domain
> unikernel. In this case, we 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Stefano Stabellini]

Hi all,

I would be glad to sponsor this proposal. I think it will be of great
benefit to the ecosystem. Let me know if I need to do anything specific.

Cheers,

Stefano

On Thu, 7 Sep 2017, Lars Kurth wrote:
> Hi all,
> 
> there is a technical issue which still needs resolving: we need a Sponsor. I 
> am thinking of Wei – he would qualify as a Hypervisor Leadership team member 
> and it would have the benefit of making sure that the MiniOS angle is 
> covered. I asked Wei, and he will get back to us once he read the proposal.
> 
> I also want to highlight this proposal at the next AB board meeting, Sept 
> 19th. It would be good, if most feedback could be given in the next week, 
> such that a) we have time to make mods, b) I have a good baseline to share 
> with the AB. I would need to share an updated proposal on the 18th at the 
> latest.
> 
> Technically, the subproject does not need AB approval, as there is no 
> financial impact, but it is always good to have it. 
> 
> Regards
> Lars
> 
> On 07/09/2017, 11:26, "Felipe Huici"  wrote:
> 
> Dear all,
> 
> Following up on discussions that Simon Kuenzer had with several of you at
> the last Xen summit, we’re now submitting a Xen subproject proposal based
> on our Unicore work. Could you please review it?
> 
> Thanks,
> 
> Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.
> 
> 
> PROPOSAL: Unicore
> =
> 
> Roles
> -
> Project Leads: Simon Kuenzer  (main lead)
>Felipe Huici  (co-lead)
>Florian Schmidt  (co-lead)
> Project Mentor:  Lars Kurth 
> Project Sponsor: -To be found-
> 
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
> 
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
> 
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.
> 
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:
>  
> 
> [Attachment: unicore-oneslider.pdf]
> 
> 
> Figure 1. Unicore architecture.
> 
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> 

[Xen-devel] [xen-unstable-smoke test] 113133: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9cb0d1d0eb3a9e4d8b97432c9246cdfbb3b0309
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   25 attempts
Testing same since   113131  2017-09-07 16:01:58 Z0 days2 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 368 lines long.)

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

[Xen-devel] GRUB documentation updated

[Daniel Kiper]

Hey,

Some people asked me about Multiboot2 Specification and other GRUB doc stuff.
So, I have put latest things at
  https://www.gnu.org/software/grub/grub-documentation.html

I hope that helps. If you have any questions please drop me a line.

Thanks,

Daniel

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

[Xen-devel] [libvirt test] 113119: trouble: blocked/broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 113032
 build-arm64-pvops 2 hosts-allocate  broken like 113032
 build-arm64-xsm   3 capture-logsbroken like 113032
 build-arm64   2 hosts-allocate  broken like 113032
 build-arm64-pvops 3 capture-logsbroken like 113032
 build-arm64   3 capture-logsbroken like 113032
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113032
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113032
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113032
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  01f3ea6488a1290d7af3af7b68aade64d937d424
baseline version:
 libvirt  4ee36c33ed371a1d9dfb9cd97b2af0ee08abd3f3

Last test of basis   113032  2017-09-04 04:20:11 Z3 days
Failing since113046  2017-09-05 04:23:42 Z2 days3 attempts
Testing same since   113119  2017-09-07 04:20:18 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Daniel P. Berrange 
  Daniel Veillard 
  Erik Skultety 
  John Ferlan 
  Michal Privoznik 
  Richard W.M. Jones 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pair 

[Xen-devel] [xen-4.8-testing test] 113117: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112944
 build-arm64-xsm   2 hosts-allocate  broken like 112944
 build-arm64-pvops 3 capture-logsbroken like 112944
 build-arm64-xsm   3 capture-logsbroken like 112944
 build-arm64   2 hosts-allocate  broken like 112944
 build-arm64   3 capture-logsbroken like 112944
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112916
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112944
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112944
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112944
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112944
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5
baseline version:
 ovmf b80a4097393c90d041b299ef628e6104612a2586

Last test of basis72070  2017-09-07 01:21:42 Z0 days
Testing same since72072  2017-09-07 15:49:09 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ge Song 
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5
Author: Ge Song 
Date:   Wed Sep 6 11:11:35 2017 +0800

OvmfPkg/SecMain: Fix stack switching to permanent memory

In earlier PEI stage, temporary memory at PcdOvmfSecPeiTempRamBase is
employed as stack and heap. We move them to the new room and do some
relocation fixup when permanent memory becomes available.
TemporaryRamMigration() is responsible for switching the stack.

Before entering TemporaryRamMigration(), Ebp/Rbp is populated with the
content of Esp/Rsp and used as frame pointer.

After the execution of SetJump/LongJump, stack migrates to new position
while the context keeps unchanged.

But when TemporaryRamMigration() exits, Esp/Rsp is filled with
the content of Ebp/Rbp to destroy this stack frame.

The result is, stack switches back to previous temporary memory.

When permanent memory becomes available, modules that have registered
themselves for shadowing will be scheduled to execute. Some of them
need to consume more memory(heap/stack). Contrast to temporary stack,
permanent stack possesses larger space.

The potential risk is overflowing the stack if stack staying in
temporary memory. When it happens, system may crash during S3 resume.

More detailed information:
> (gdb) disassemble /r
> Dump of assembler code for function TemporaryRamMigration:
>   0xfffcd29c <+0>:55  push   %rbp
>   0xfffcd29d <+1>:48 89 e5mov%rsp,%rbp
>   0xfffcd2a0 <+4>:48 81 ec 70 01 00 00sub
> $0x170,%rsp
>...
>...
>0xfffcd425 <+393>: e8 80 10 00 00  callq  0xfffce4aa
> 
> => 0xfffcd42a <+398>: b8 00 00 00 00  mov$0x0,%eax
>0xfffcd42f <+403>: c9  leaveq
>0xfffcd430 <+404>: c3  retq
> End of assembler dump.

See the description of leave(opcode: c9), from
Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2A

"Releases the stack frame set up by an earlier ENTER instruction. The
LEAVE instruction copies the frame pointer (in the EBP register) into
the stack pointer register (ESP), which releases the stack space
allocated to the stack frame. The old frame pointer (the frame pointer
for the calling procedure that was saved by the ENTER instruction) is
then popped from the stack into the EBP register, restoring the calling
procedure’s stack frame."

To solve this, update Ebp/Rbp too when Esp/Rsp is updated

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ge Song 
Tested-by: Laszlo Ersek 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

commit 

Re: [Xen-devel] [PATCH v2 3/5] xen/livepatch/ARM32: Don't load and crash on livepatches loaded with wrong alignment.

[Konrad Rzeszutek Wilk]

On Wed, Aug 02, 2017 at 03:20:05AM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk  07/31/17 6:04 PM >>>
> >On Mon, Jul 31, 2017 at 07:55:34AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk  07/26/17 9:50 PM >>>
> >> >--- a/docs/misc/livepatch.markdown
> >> >+++ b/docs/misc/livepatch.markdown
> >> >@@ -279,6 +279,10 @@ It may also have some architecture-specific 
> >> >sections. For example:
> >> >* Exception tables.
> >> >* Relocations for each of these sections.
> >>  >
> >> >+Note that on ARM 32 the sections SHOULD be four byte aligned. Otherwise
> >> >+we risk hitting Data Abort exception as un-aligned manipulation of data 
> >> >is
> >> >+prohibited on ARM 32.
> >> 
> >> This (and hence the rest of the patch) is not in line with the outcome of 
> >> the
> >> earlier discussion we had. Nothing is wrong with a section having smaller
> >> alignment, as long as there are no 32-bit (or wider, but I don't think 
> >> there
> >> are any such) relocations against such a section. And even if there were, I
> >> think it should rather be the code doing the relocations needing to cope, 
> >> as
> >> I don't think the ARM ELF ABI imposes any such restriction.
> >
> >The idea behind this patch is to give advance warnings. Akin to what
> >2ff229643b739e2fd0cd0536ee9fca506cfa92f8
> >"xen/livepatch: Don't crash on encountering STN_UNDEF relocations" did.
> >
> >The other patches in this series fix the alignment issues.
> >
> >The ARM ELF ABI 
> >(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf)
> >
> >says:
> >
> >4.3.5 Section Alignment
> >There is no minimum alignment required for a section. However, sections 
> >containing thumb code must be at least
> >16-bit aligned and sections containing ARM code must be at least 32-bit 
> >aligned.
> >Platform standards may set a limit on the maximum alignment that they can 
> >guarantee (normally the page size).
> 
> Note the "thumb code" and "ARM code" in here - iirc you're checking _all_
> sections, not just ones containing code.

I can fix the code to only do the check for 'X' ones:

  [ 2] .text PROGBITS   0070
   00ca    AX   0 0 16
  [ 4] .altinstr_replace PROGBITS   013c
   000b    AX   0 0 4
  [ 5] .fixupPROGBITS   0147
   000d    AX   0 0 1


And also have the check in the relocation - which right now are
32-bit: R_ARM_ABS32, R_ARM_REL32, R_ARM_MOVW_ABS_NC, R_ARM_MOVT_ABS,
R_ARM_CALL, R_ARM_JUMP24 so will leave the code as in
arch_livepatch_perform.

But neither one of those is going to help in catching livepatches
that have the wrong alignment without relocations and not executable.
For example .livepatch.depends

Thoughts on how you would want to catch those?

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

[Xen-devel] [xen-unstable-smoke test] 113131: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9cb0d1d0eb3a9e4d8b97432c9246cdfbb3b0309
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   24 attempts
Testing same since   113131  2017-09-07 16:01:58 Z0 days1 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 368 lines long.)

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

Re: [Xen-devel] [PATCH v10 1/3] gitignore: add local vimrc files

[Petre Ovidiu PIRCALABU]

On Jo, 2017-09-07 at 17:12 +0100, Ian Jackson wrote:
> Petre Ovidiu PIRCALABU writes ("Re: [PATCH v10 1/3] gitignore: add
> local vimrc files"):
> > 
> > On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> > > 
> > > OOI how does this work?
> ...
> > 
> > I haven't added the file to the repository, just to .gitignore in
> > order
> > to mask it from git. It will help me very much to have it upstream
> > because right now I have to cherry-pick it each time I create a
> > local
> > branch.
> > I'm using neovim and 'MarcWeber/vim-addon-local-vimrc'. My local
> > .vimrc
> > is quite simple, just sets the alignment, tabs and tabspace
> > according
> > to the xen coding standard.
> Why don't you put the .vimrc in your .. ?
> 
> Ian.
> 
My current directory layout is a "work" directory which contains
various projects (with different coding standards). Using "per-
directory" settings in my global .vimrc is possible but personally I
prefer using a local .vimrc which is easier to manage & migrate.

//Petre
> 
> This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 5/5] ARM: ITS: Expose ITS in the MADT table

[Andre Przywara]

Hi,

On 05/09/17 18:15, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> Add gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.
> 
> Signed-off-by: Manish Jaggi 
> ---
>  xen/arch/arm/gic-v3-its.c| 23 +++
>  xen/arch/arm/gic-v3.c|  1 +
>  xen/include/asm-arm/gic_v3_its.h |  8 
>  3 files changed, 32 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 0ab1466..bf84db8 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -1064,6 +1064,29 @@ void gicv3_its_acpi_init(void)
>  acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
>gicv3_its_acpi_probe, 0);
>  }
> +
> +unsigned long gicv3_its_make_hwdom_madt(const struct domain *d, u8 *base_ptr,
> +unsigned long offset)

What about we drop offset here and add it at the caller, then return
just the size of the ITS MADT size? Also base_ptr could be a void* then.

> +{
> +unsigned long i;
> +struct acpi_madt_generic_translator *fw_its;

If you make this either a "void *" or a "struct acpi_subtable_header *"
then you can save the rather ugly cast in the assignment below.

> +struct acpi_madt_generic_translator *hwdom_its;
> +
> +hwdom_its = (struct acpi_madt_generic_translator *)(base_ptr
> +   + offset);

If you drop offset as mentioned above and make base_ptr a void*, you can
save the cast.

> +
> +for ( i = 0; i < vgic_v3_its_count(d); i++ )
> +{
> +fw_its = (struct acpi_madt_generic_translator *)
> +acpi_table_get_entry_madt(
> +ACPI_MADT_TYPE_GENERIC_TRANSLATOR, i);
> +memcpy(hwdom_its, fw_its, sizeof(struct 
> acpi_madt_generic_translator));
> +hwdom_its++;
> +}
> +
> +return (offset + sizeof(struct acpi_madt_generic_translator)
> +   * vgic_v3_its_count(d));
> +}
>  #endif
>  
>  /*
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 3eb67f2..0392795 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1403,6 +1403,7 @@ static int gicv3_make_hwdom_madt(const struct domain 
> *d, u32 offset)
>  table_len += size;
>  }
>  
> +table_len = gicv3_its_make_hwdom_madt(d, base_ptr, table_len);

... and here you could mimic the other calls then:
table_len += gicv3_its_make_hwdom_madt(d, base_ptr + table_len);

(or directly return).

Cheers,
Andre.


>  return table_len;
>  }
>  
> diff --git a/xen/include/asm-arm/gic_v3_its.h 
> b/xen/include/asm-arm/gic_v3_its.h
> index 9cf18da..ae8a494 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -137,6 +137,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
>  
>  #ifdef CONFIG_ACPI
>  void gicv3_its_acpi_init(void);
> +unsigned long gicv3_its_make_hwdom_madt(const struct domain *d, u8 *base_ptr,
> +unsigned long offset);
>  #endif
>  
>  /* Deny iomem access for its */
> @@ -207,6 +209,12 @@ static inline void gicv3_its_dt_init(const struct 
> dt_device_node *node)
>  static inline void gicv3_its_acpi_init(void)
>  {
>  }
> +
> +unsigned long gicv3_its_make_hwdom_madt(struct domain *d, u8 *base_ptr,
> +unsigned long offset)
> +{
> +return 0;
> +}
>  #endif
>  
>  static inline int gicv3_its_deny_access(const struct domain *d)
> 

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

Re: [Xen-devel] [PATCH v3 3/5] ARM: ITS: Deny hardware domain access to ITS

[Andre Przywara]

Hi,

On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> This patch extends the gicv3_iomem_deny_access functionality by adding
> support for ITS region as well. Add function gicv3_its_deny_access.
> 
> Signed-off-by: Manish Jaggi 
> ---
>  xen/arch/arm/gic-v3-its.c| 22 ++
>  xen/arch/arm/gic-v3.c|  3 +++
>  xen/include/asm-arm/gic_v3_its.h |  9 +
>  3 files changed, 34 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 536b48d..0ab1466 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -20,6 +20,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -906,6 +907,27 @@ struct pending_irq *gicv3_assign_guest_event(struct 
> domain *d,
>  return pirq;
>  }
>  
> +int gicv3_its_deny_access(const struct domain *d)
> +{
> +int rc = 0;
> +unsigned long mfn, nr;
> +const struct host_its *its_data;
> +
> +list_for_each_entry( its_data, _its_list, entry )
> +{
> +mfn = paddr_to_pfn(its_data->addr);
> +nr = PFN_UP(ACPI_GICV3_ITS_MEM_SIZE);

Shouldn't this not only cover the ITS register frame, but also the
following 64K page containing the doorbell address? Otherwise we leave
the doorbell address open, which seems to be asking for trouble ...

Cheers,
Andre.

> +rc = iomem_deny_access(d, mfn, mfn + nr);
> +if ( rc )
> +{
> +printk( "iomem_deny_access failed for %lx:%lx \r\n", mfn, nr);
> +break;
> +}
> +}
> +
> +return rc;
> +}
> +
>  /*
>   * Create the respective guest DT nodes from a list of host ITSes.
>   * This copies the reg property, so the guest sees the ITS at the same 
> address
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 6f562f4..b3d605d 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1308,6 +1308,9 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  if ( rc )
>  return rc;
>  
> +if ( gicv3_its_deny_access(d) )
> +return rc;
> +
>  for ( i = 0; i < gicv3.rdist_count; i++ )
>  {
>  mfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
> diff --git a/xen/include/asm-arm/gic_v3_its.h 
> b/xen/include/asm-arm/gic_v3_its.h
> index 993819a..9cf18da 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -138,6 +138,10 @@ void gicv3_its_dt_init(const struct dt_device_node 
> *node);
>  #ifdef CONFIG_ACPI
>  void gicv3_its_acpi_init(void);
>  #endif
> +
> +/* Deny iomem access for its */
> +int gicv3_its_deny_access(const struct domain *d);
> +
>  bool gicv3_its_host_has_its(void);
>  
>  unsigned int vgic_v3_its_count(const struct domain *d);
> @@ -205,6 +209,11 @@ static inline void gicv3_its_acpi_init(void)
>  }
>  #endif
>  
> +static inline int gicv3_its_deny_access(const struct domain *d)
> +{
> +return 0;
> +}
> +
>  static inline bool gicv3_its_host_has_its(void)
>  {
>  return false;
> 

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

Re: [Xen-devel] [PATCH v3 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

[Andre Przywara]

Hi,

On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> estimate_acpi_efi_size needs to be updated to provide correct size of
> hardware domains MADT, which now adds ITS information as well.
> 
> Introducing gic_get_hwdom_madt_size.
> 
> Signed-off-by: Manish Jaggi 
> ---
>  xen/arch/arm/domain_build.c |  7 +--
>  xen/arch/arm/gic-v2.c   |  6 ++
>  xen/arch/arm/gic-v3.c   | 18 ++
>  xen/arch/arm/gic.c  | 11 +++
>  xen/include/asm-arm/gic.h   |  3 +++
>  5 files changed, 39 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 1bec4fa..5739ea4 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1806,12 +1806,7 @@ static int estimate_acpi_efi_size(struct domain *d, 
> struct kernel_info *kinfo)
>  acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
>  acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);
>  
> -madt_size = sizeof(struct acpi_table_madt)
> -+ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
> -+ sizeof(struct acpi_madt_generic_distributor);
> -if ( d->arch.vgic.version == GIC_V3 )
> -madt_size += sizeof(struct acpi_madt_generic_redistributor)
> - * d->arch.vgic.nr_regions;
> +madt_size = gic_get_hwdom_madt_size(d);
>  acpi_size += ROUNDUP(madt_size, 8);
>  
>  addr = acpi_os_get_root_pointer();
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index cbe71a9..737c50a 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1012,6 +1012,11 @@ static int gicv2_iomem_deny_access(const struct domain 
> *d)
>  return iomem_deny_access(d, mfn, mfn + nr);
>  }
>  
> +static unsigned long gicv2_get_hwdom_madt_size(const struct domain *d)
> +{
> +return 0;
> +}

Nothing too critical, but this looks a bit confusing, as the size of the
GIC part of the MADT isn't 0 even for GICv2. So either you rename it to
something containing "additional" or the like or you do what it says on
the tin and return the per-VCPU size and the size for the distributor
here (at the cost of copying this to the GICv3 code).

Cheers,
Andre.

> +
>  #ifdef CONFIG_ACPI
>  static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
>  {
> @@ -1248,6 +1253,7 @@ const static struct gic_hw_operations gicv2_ops = {
>  .read_apr= gicv2_read_apr,
>  .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
>  .make_hwdom_madt = gicv2_make_hwdom_madt,
> +.get_hwdom_madt_size = gicv2_get_hwdom_madt_size,
>  .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
>  .iomem_deny_access   = gicv2_iomem_deny_access,
>  .do_LPI  = gicv2_do_LPI,
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index b3d605d..3eb67f2 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1406,6 +1406,18 @@ static int gicv3_make_hwdom_madt(const struct domain 
> *d, u32 offset)
>  return table_len;
>  }
>  
> +static unsigned long gicv3_get_hwdom_madt_size(const struct domain *d)
> +{
> +unsigned long size;
> +size  = sizeof(struct acpi_madt_generic_redistributor)
> +* d->arch.vgic.nr_regions;
> +
> +size  += vgic_v3_its_count(d)
> +* sizeof(struct acpi_madt_generic_translator);
> +
> +return size;
> +}
> +
>  static int __init
>  gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>  const unsigned long end)
> @@ -1597,6 +1609,11 @@ static int gicv3_make_hwdom_madt(const struct domain 
> *d, u32 offset)
>  {
>  return 0;
>  }
> +
> +static u32 gicv3_get_hwdom_madt_size(const struct domain *d)
> +{
> +return 0;
> +}
>  #endif
>  
>  /* Set up the GIC */
> @@ -1698,6 +1715,7 @@ static const struct gic_hw_operations gicv3_ops = {
>  .secondary_init  = gicv3_secondary_cpu_init,
>  .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
>  .make_hwdom_madt = gicv3_make_hwdom_madt,
> +.get_hwdom_madt_size = gicv3_get_hwdom_madt_size,
>  .iomem_deny_access   = gicv3_iomem_deny_access,
>  .do_LPI  = gicv3_do_LPI,
>  };
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 6c803bf..9ffd33a 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -851,6 +851,17 @@ int gic_make_hwdom_madt(const struct domain *d, u32 
> offset)
>  return gic_hw_ops->make_hwdom_madt(d, offset);
>  }
>  
> +unsigned long gic_get_hwdom_madt_size(const struct domain *d)
> +{
> +unsigned long madt_size;
> +madt_size = sizeof(struct acpi_table_madt)
> ++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
> ++ sizeof(struct acpi_madt_generic_distributor)
> ++ gic_hw_ops->get_hwdom_madt_size(d);
> +
> +return madt_size;
> +}
> +
>  int 

Re: [Xen-devel] [PATCH v3 2/5] ARM: ITS: Populate host_its_list from ACPI MADT Table

[Andre Przywara]

Hi,

On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> Added gicv3_its_acpi_init to update host_its_list from MADT table.
> For ACPI, host_its structure  stores dt_node as NULL.
> 
> Signed-off-by: Manish Jaggi 
> ---
>  xen/arch/arm/gic-v3-its.c| 26 ++
>  xen/arch/arm/gic-v3.c|  2 ++
>  xen/include/asm-arm/gic_v3_its.h |  9 +
>  3 files changed, 37 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 61a6452..536b48d 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,7 @@
>  #include 
>  
>  #define ITS_CMD_QUEUE_SZSZ_1M
> +#define ACPI_GICV3_ITS_MEM_SIZE SZ_64K

Although this is used for ACPI only, this size is really the architected
size for the ITS register frame and thus should be named like this,
possibly GUEST_GICV3_ITS_SIZE or so (in xen/include/public/arch-arm.h).
Which actually makes me wonder why we would need to store this size in
the data structure in the first place ...

>  /*
>   * No lock here, as this list gets only populated upon boot while scanning
> @@ -1018,6 +1020,30 @@ void gicv3_its_dt_init(const struct dt_device_node 
> *node)
>  }
>  }
>  
> +#ifdef CONFIG_ACPI
> +int gicv3_its_acpi_probe(struct acpi_subtable_header *header,
> +const unsigned long end)

  w/s?
> +{
> +struct acpi_madt_generic_translator *its;
> +
> +its = (struct acpi_madt_generic_translator *)header;
> +if ( BAD_MADT_ENTRY(its, end) )
> +return -EINVAL;
> +
> +add_to_host_its_list(its->base_address,
> +ACPI_GICV3_ITS_MEM_SIZE, NULL);

  w/s?

> +
> +return 0;
> +}
> +
> +void gicv3_its_acpi_init(void)
> +{
> +/* Parse ITS information */
> +acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> +  gicv3_its_acpi_probe, 0);

w/s?

Cheers,
Andre.

> +}
> +#endif
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index f990eae..6f562f4 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1567,6 +1567,8 @@ static void __init gicv3_acpi_init(void)
>  
>  gicv3.rdist_stride = 0;
>  
> +gicv3_its_acpi_init();
> +
>  /*
>   * In ACPI, 0 is considered as the invalid address. However the rest
>   * of the initialization rely on the invalid address to be
> diff --git a/xen/include/asm-arm/gic_v3_its.h 
> b/xen/include/asm-arm/gic_v3_its.h
> index 1fac1c7..993819a 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -135,6 +135,9 @@ extern struct list_head host_its_list;
>  /* Parse the host DT and pick up all host ITSes. */
>  void gicv3_its_dt_init(const struct dt_device_node *node);
>  
> +#ifdef CONFIG_ACPI
> +void gicv3_its_acpi_init(void);
> +#endif
>  bool gicv3_its_host_has_its(void);
>  
>  unsigned int vgic_v3_its_count(const struct domain *d);
> @@ -196,6 +199,12 @@ static inline void gicv3_its_dt_init(const struct 
> dt_device_node *node)
>  {
>  }
>  
> +#ifdef CONFIG_ACPI
> +static inline void gicv3_its_acpi_init(void)
> +{
> +}
> +#endif
> +
>  static inline bool gicv3_its_host_has_its(void)
>  {
>  return false;
> 

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

Re: [Xen-devel] [PATCH v3 1/5] ARM: ITS: Introduce common function add_to_host_its_list

[Andre Przywara]

Hi,

On 05/09/17 18:14, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> add_to_host_its_list will update the host_its_list. This common
> function to be invoked from gicv3_its_dt_init and gic_v3_its_acpi_probe.
> 
> Signed-off-by: Manish Jaggi 

Makes sense.

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/arch/arm/gic-v3-its.c | 32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 2d36030..61a6452 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -976,11 +976,29 @@ int gicv3_its_make_hwdom_dt_nodes(const struct domain 
> *d,
>  return res;
>  }
>  
> +/* Common function for adding to host_its_list */
> +static void add_to_host_its_list(paddr_t addr, paddr_t size,
> + const struct dt_device_node *node)
> +{
> +struct host_its *its_data;
> +
> +its_data = xzalloc(struct host_its);
> +if ( !its_data )
> +panic("GICv3: Cannot allocate memory for ITS frame");
> +
> +its_data->addr = addr;
> +its_data->size = size;
> +its_data->dt_node = node;
> +
> +printk("GICv3: Found ITS @0x%lx\n", addr);
> +
> +list_add_tail(_data->entry, _its_list);
> +}
> +
>  /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. 
> */
>  void gicv3_its_dt_init(const struct dt_device_node *node)
>  {
>  const struct dt_device_node *its = NULL;
> -struct host_its *its_data;
>  
>  /*
>   * Check for ITS MSI subnodes. If any, add the ITS register
> @@ -996,17 +1014,7 @@ void gicv3_its_dt_init(const struct dt_device_node 
> *node)
>  if ( dt_device_get_address(its, 0, , ) )
>  panic("GICv3: Cannot find a valid ITS frame address");
>  
> -its_data = xzalloc(struct host_its);
> -if ( !its_data )
> -panic("GICv3: Cannot allocate memory for ITS frame");
> -
> -its_data->addr = addr;
> -its_data->size = size;
> -its_data->dt_node = its;
> -
> -printk("GICv3: Found ITS @0x%lx\n", addr);
> -
> -list_add_tail(_data->entry, _its_list);
> +add_to_host_its_list(addr, size, its);
>  }
>  }
>  
> 

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

[Xen-devel] Feature control on PV devices

[Joao Martins]

Hey!

We wanted to brought up this small proposal regarding the lack of
parameterization on PV devices on Xen.

Currently users don't have a way for enforce and control what
features/queues/etc the backend provides. So far there's only global parameters
on backends, and specs do not mention anything in this regard.

The most obvious example is netback/blkback max_queues module parameter where it
sets the limit the maximum queues for all devices which is not that flexible.
Other examples include controlling offloads visible by the NIC (e.g. disabling
checksum offload, disabling scather-gather), others more about I/O path (e.g.
disable blkif indirect descriptors, limit number of pages for the ring), or less
grant usage by minimizing number of queues/descriptors.

Of course there could be more examples, as this seems to be ortoghonal to the
kinds of PV backends we have. And seems like all features appear to be published
on the same xenbus state?

The idea to address this would be very simple:

- Toolstack when initializing device paths, writes additional entries in the
form of 'request-' = . These entries are only
visible by the backend and toolstack;

- Backend reads this entries and uses  as the value of
, which will then be visible on the frontend.

[ Removal of the 'request-*' xenstore entries could represent a feedback look
  that the backend indeed read and used the value. Or else it could simply be
  ignored. ]

And that's it.

In pratice user would do: E.g.

domain.cfg:
...
name = "guest"
kernel = "bzImage"
vif = ["bridge=br0,queues=2"]
disk = [
"format=raw,vdev=hda,access=rw,backendtype=phy,target=/dev/HostVG/XenGuest2,queues=1,max-ring-page-order=0"
]
...

Toolstack writes:

/local/domain/0/backend/vif/8/0/request-multi-queue-max-queues = 2
/local/domain/0/backend/vbd/8/51713/request-multi-queue-max-queues = 2
/local/domain/0/backend/vbd/8/51713/request-max-ring-page-order = 0

Backends reads and seeds with (and assuming it passes backend validation ofc):

/local/domain/0/backend/vif/8/0/multi-queue-max-queues = 2
/local/domain/0/backend/vbd/8/51713/multi-queue-max-queues = 2
/local/domain/0/backend/vbd/8/51713/max-ring-page-order = 0

The XL configuration entry for controlling these tunable are just examples it's
not clear the general preference for this. An alternative could be:

vif = ["bridge=br0,features=queues:2\\;max-ring-page-order:0"]

Which lets us have more generic feature control, without sticking to particular
features names.

Naturally libvirt could be a consumer of this (as it already has the 'queues'
and host 'tso4', 'tso6', etc in their XML schemas)

Thoughts? Do folks think the correct way of handling this?

Cheers,
Joao

[0] https://github.com/qemu/qemu/blob/master/hw/net/virtio-net.c#L2102

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

[Xen-devel] [PATCH] x86/mm: Allow map_domain_page_global() to be used during boot

[Andrew Cooper]

map_domain_page_global() uses vmap under the hood, which works fine even
during very early boot.  Relax the local_irq_is_enabled() part of the
assertion before Xen has finished booting.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/domain_page.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 0463e9a..b03c85d 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -305,7 +305,8 @@ int mapcache_vcpu_init(struct vcpu *v)
 
 void *map_domain_page_global(mfn_t mfn)
 {
-ASSERT(!in_irq() && local_irq_is_enabled());
+ASSERT(!in_irq() && (system_state < SYS_STATE_active ||
+ local_irq_is_enabled()));
 
 #ifdef NDEBUG
 if ( mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) )
-- 
2.1.4


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

[Xen-devel] [qemu-mainline test] 113114: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 113036

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 113036
 build-arm64-xsm   2 hosts-allocate  broken like 113036
 build-arm64-pvops 2 hosts-allocate  broken like 113036
 build-arm64   3 capture-logsbroken like 113036
 build-arm64-xsm   3 capture-logsbroken like 113036
 build-arm64-pvops 3 capture-logsbroken like 113036
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 113036
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113036
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113036
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113036
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113036
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub07d1c2f5607489d4d4a6a65ce36a3e896ac065e
baseline version:
 qemuu32f0f68bb77289b75a82925f712bb52e16eac3ba

Last test of basis   113036  2017-09-04 09:16:59 Z3 days
Failing since113044  2017-09-04 23:16:29 Z2 days5 attempts
Testing same since   113060  2017-09-05 23:44:28 Z1 days3 attempts


People who touched revisions under test:
  Andrew Jeffery 
  Andrew Jones 
  Artyom Tarasenko 
  Cao jin 
  Daniel P. 

Re: [Xen-devel] kernel panic with no call trace

[Minjun Hong]

Thank you for your replay even if this is quite late.
As you mention, I know there is an error (or some errors) but I cannot
guess where it is, so that I want to know where I should start debugging
from.
However, although I'm using serial console, I could get not enough clues
only from the kernel log:
1) I could get what line and file caused the panic by using the call trace
2) What linear address brings about this situation; Faulting linear address

I think, literally, the 'Faulting linear address' is key point because I
heard that it represents bad pointer.
With the pointer(it is just address and I cannot infer what it does mean),
is there any way to figure out its real data or line in C source code?
If you have any other approach that can be used in some cases like this,
could you please give me the guide?

Below is the kernel log from serial console:

(XEN) [ Xen-4.5.0  x86_64  debug=n  Not tainted ]
(XEN) CPU:2
(XEN) RIP:e008:[] csched_schedule+0x373/0x1180
(XEN) RFLAGS: 00010086   CONTEXT: hypervisor
(XEN) rax:    rbx: 830087ffa000   rcx: 830461d2
(XEN) rdx: 830088002c98   rsi: 830461d2   rdi: 
(XEN) rbp: 830461ce2ae0   rsp: 830461d27d10   r8:  001e582339ec
(XEN) r9:  0004   r10: 003c   r11: 0004
(XEN) r12: 0001   r13: 82d0803f26a0   r14: 830461c53000
(XEN) r15:    cr0: 8005003b   cr4: 003526f0
(XEN) cr3: 86077000   cr2: 830088002c98
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen stack trace from rsp=830461d27d10:
(XEN)830461d03950 82d0804081e0 830461c74068 830461d27de0
(XEN)830461c24c30 830461cec800 82d0804081e0 00060002
(XEN)830461ce29d0 830461d2 82d0804081e0 830461d3a720
(XEN)0002 830461d3a700 00c0 830461d27dd0
(XEN)830461d27e68 82d080408180 001e5c106499 01c9c380
(XEN)  8300864e3000 8302e1596fb0
(XEN)830461d27dd0 830461d27dd0 004b 
(XEN)  830461d3a738 8300864e3000
(XEN)82d0804081e0 830461d2e068 001e5c106499 830461d2e060
(XEN)82d0803f26a0 82d080128cb3 001e 830461d2e080
(XEN)82d080279944 82d08015f295 001e5c0504ce 830461d3ad80
(XEN)001e5c1054ba 82d08012f64e 82d0803f26a0 
(XEN)82d0803df880 0001 82d0803df780 
(XEN)830461d2 82d08012c03c  
(XEN)830461d2 830461d2e068 001e5b762541 830461d2e060
(XEN)82d0803f26a0 82d080162e3a  8300864e3000
(XEN)8300864e3000 8800f8bbbfd8  8800f8bbbfd8
(XEN)0003 8800f8bbbec0  0246
(XEN)7ff0   
(XEN)810013aa 0001  0001
(XEN) Xen call trace:
(XEN)[] csched_schedule+0x373/0x1180
(XEN)[] schedule+0xf3/0x590
(XEN)[] reprogram_timer+0x75/0xe0
(XEN)[] timer_softirq_action+0x13e/0x210
(XEN)[] __do_softirq+0x7c/0xd0
(XEN)[] idle_loop+0x3a/0x70
(XEN)
(XEN) Pagetable walk from 830088002c98:
(XEN)  L4[0x106] = 86075063 
(XEN)  L3[0x002] = 86071063 
(XEN)  L2[0x040] =  
(XEN)
(XEN) 
(XEN) Panic on CPU 2:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=]
(XEN) Faulting linear address: 830088002c98
(XEN) 
(XEN)
(XEN) Reboot in five seconds...
(XEN) Resetting with ACPI MEMORY or I/O RESET_REG.


I hope your help.

Sincerely,

On Wed, Sep 6, 2017 at 4:45 PM, Andrew Cooper 
wrote:

> On 06/09/2017 03:39, Minjun Hong wrote:
> > Hello~~
> > I'm struggling to resolve a kernel panic problem during developing
> > scheduler code.
> > But I have not made any progress since I can not get any meaningful
> > information from the serial log.
> > When the panic occurred, always there is no call trace and only panic
> > notification like following:
> >
> > (XEN)
> > (XEN) 
> > (XEN) Panic on CPU 0:
> > (XEN) cpu:20, vcpu:20 in csched_schedule(1891)
> > (XEN) cpu:21, vcpu:21 in csched_schedule(1891)
> > (XEN) cpumask_test_cpu(cpu, prv->in_cosched) in csched_schedule(1907)
> > (XEN) cpumask_test_cpu(cpu, prv->in_cosched) in csched_schedule(1907)
> > (XEN) cpumask_test_cpu(cpu, prv->in_cosched) in csched_schedule(1907)
> > (XEN) cpumask_test_cpu(cpu, prv->in_cosched) in csched_schedule(1907)
> > (XEN) FATAL PAGE FAULT
> > (XEN) [error_code=]
> > 

Re: [Xen-devel] [PATCH v10 1/3] gitignore: add local vimrc files

[Ian Jackson]

Petre Ovidiu PIRCALABU writes ("Re: [PATCH v10 1/3] gitignore: add local vimrc 
files"):
> On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> > OOI how does this work?
...
> I haven't added the file to the repository, just to .gitignore in order
> to mask it from git. It will help me very much to have it upstream
> because right now I have to cherry-pick it each time I create a local
> branch.
> I'm using neovim and 'MarcWeber/vim-addon-local-vimrc'. My local .vimrc
> is quite simple, just sets the alignment, tabs and tabspace according
> to the xen coding standard.

Why don't you put the .vimrc in your .. ?

Ian.

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

Re: [Xen-devel] [PATCH v5 11/11] vpci/msix: add MSI-X handlers

[Roger Pau Monné]

On Mon, Aug 14, 2017 at 03:28:50PM +0100, Roger Pau Monne wrote:
[...]
> +static void vpci_msix_control_write(struct pci_dev *pdev, unsigned int reg,
> +uint32_t val, void *data)
> +{
> +uint8_t seg = pdev->seg, bus = pdev->bus;
> +uint8_t slot = PCI_SLOT(pdev->devfn), func = PCI_FUNC(pdev->devfn);
> +struct vpci_msix *msix = data;
> +bool new_masked, new_enabled;
> +
> +new_masked = val & PCI_MSIX_FLAGS_MASKALL;
> +new_enabled = val & PCI_MSIX_FLAGS_ENABLE;
> +
> +/*
> + * According to the PCI 3.0 specification, switching the enable bit
> + * to 1 or the function mask bit to 0 should cause all the cached
> + * addresses and data fields to be recalculated. Xen implements this
> + * as disabling and enabling the entries.
> + *
> + * Note that the disable/enable sequence is only performed when the
> + * guest has written to the entry (ie: updated field set).
> + */
> +if ( new_enabled && !new_masked && (!msix->enabled || msix->masked) )
> +{
> +paddr_t table_base = pdev->vpci->header.bars[msix->table.bir].addr;
> +unsigned int i;
> +int rc;
> +
> +for ( i = 0; i < msix->max_entries; i++ )
> +{
> +if ( msix->entries[i].masked || !msix->entries[i].updated )
> +continue;
> +
> +rc = vpci_msix_arch_disable(>entries[i].arch, pdev);
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u: unable to disable entry %u: 
> %d\n",
> + seg, bus, slot, func, msix->entries[i].nr, rc);
> +return;
> +}
> +
> +rc = vpci_msix_arch_enable(>entries[i].arch, pdev,
> +   msix->entries[i].addr,
> +   msix->entries[i].data,
> +   msix->entries[i].nr, table_base);
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u: unable to enable entry %u: 
> %d\n",
> + seg, bus, slot, func, msix->entries[i].nr, rc);
> +/* Entry is likely not configured, skip it. */
> +continue;
> +}
> +
> +/*
> + * At this point the PIRQ is still masked. Unmask it, or else the
> + * guest won't receive interrupts. This is due to the
> + * disable/enable sequence performed above.
> + */
> +vpci_msix_arch_mask(>entries[i].arch, pdev, false);
> +
> +msix->entries[i].updated = false;
> +}
> +}

I've realized that this function is missing the unmapping/unbinding of
PIRQs when the guest disables MSIX. I've added this now and will be
part of the next iteration.

Roger.

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

Re: [Xen-devel] [PATCH v5 11/11] vpci/msix: add MSI-X handlers

[Jan Beulich]

>>> On 14.08.17 at 16:28,  wrote:
> +void vpci_msix_arch_mask(struct vpci_arch_msix_entry *arch,
> + struct pci_dev *pdev, bool mask)
> +{
> +if ( arch->pirq == INVALID_PIRQ )
> +return;

How come no similar guard is needed in vpci_msi_arch_mask()?

> +int vpci_msix_arch_enable(struct vpci_arch_msix_entry *arch,

Considering the first parameter's type, is the name actually
appropriate? From the parameter (and the code) I would
conclude you enable a single entry here only, not the entire
device. This may apply to functions further below, too.

> +  struct pci_dev *pdev, uint64_t address,
> +  uint32_t data, unsigned int entry_nr,
> +  paddr_t table_base)
> +{
> +struct domain *d = pdev->domain;
> +struct msi_info msi_info = {
> +.seg = pdev->seg,
> +.bus = pdev->bus,
> +.devfn = pdev->devfn,
> +.table_base = table_base,
> +.entry_nr = entry_nr,
> +};
> +xen_domctl_bind_pt_irq_t bind = {
> +.irq_type = PT_IRQ_TYPE_MSI,
> +.u.msi.gvec = msi_vector(data),
> +.u.msi.gflags = msi_flags(data, address),
> +};
> +int rc;
> +
> +ASSERT(arch->pirq == INVALID_PIRQ);
> +
> +/*
> + * Simple sanity check before trying to setup the interrupt.
> + * According to the Intel SDM, bits [31, 20] must contain the
> + * value 0xfee. This avoids needlessly setting up pirqs for entries
> + * the guest has not actually configured.
> + */
> +if ( (address & 0xfff0) != MSI_ADDR_HEADER )
> +return -EINVAL;

What about the upper half of the address? That needs to be zero,
I think.

> +rc = allocate_and_map_msi_pirq(d, -1, >pirq,
> +   MAP_PIRQ_TYPE_MSI, _info);
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u: unable to map MSI-X PIRQ entry %u: 
> %d\n",
> + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), entry_nr, rc);
> +return rc;
> +}
> +
> +bind.machine_irq = arch->pirq;
> +pcidevs_lock();
> +rc = pt_irq_create_bind(d, );
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u: unable to create MSI-X bind %u: %d\n",
> + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), entry_nr, rc);
> +spin_lock(>event_lock);
> +unmap_domain_pirq(d, arch->pirq);
> +spin_unlock(>event_lock);
> +pcidevs_unlock();
> +arch->pirq = INVALID_PIRQ;
> +return rc;
> +}
> +pcidevs_unlock();
> +
> +return 0;
> +}

Much of this looks pretty similar to the MSI counterpart. Can any
reasonable portion of this be factored out?

> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

No need to include xen/p2m-common.h then anymore, although for
a common source file it's probably not entirely right to include this
header at all.

> @@ -89,11 +90,45 @@ static int vpci_map_range(unsigned long s, unsigned long 
> e, void *data)
>  return modify_mmio(map->d, _gfn(s), _mfn(s), e - s + 1, map->map);
>  }
>  
> +static int vpci_unmap_msix(struct domain *d, struct vpci_msix_mem *msix)
> +{
> +unsigned long gfn;
> +
> +for ( gfn = PFN_DOWN(msix->addr); gfn <= PFN_UP(msix->addr + msix->size);

Missing a subtraction of 1 in the PFN_UP() invocation? And why <= ?

> @@ -102,6 +137,42 @@ static int vpci_modify_bar(struct domain *d, const 
> struct vpci_bar *bar,
>  if ( IS_ERR(mem) )
>  return PTR_ERR(mem);
>  
> +for ( i = 0; i < ARRAY_SIZE(bar->msix); i++ )
> +{
> +struct vpci_msix_mem *msix = bar->msix[i];
> +
> +if ( !msix || msix->addr == INVALID_PADDR )
> +continue;
> +
> +if ( map )
> +{
> +/*
> + * Make sure the MSI-X regions of the BAR are not mapped into the
> + * domain p2m, or else the MSI-X handlers are useless. Only do 
> this
> + * when mapping, since that's when the memory decoding on the
> + * device is enabled.
> + *
> + * This is required because iommu_inclusive_mapping might have
> + * mapped MSI-X regions into the guest p2m.
> + */
> +rc = vpci_unmap_msix(d, msix);
> +if ( rc )
> +{
> +rangeset_destroy(mem);
> +return rc;
> +}
> +}
> +
> +rc = rangeset_remove_range(mem, PFN_DOWN(msix->addr),
> +   PFN_DOWN(msix->addr + msix->size));
> +if ( rc )
> +{
> +rangeset_destroy(mem);
> +return rc;
> +}
> +
> +}

Why do you do this for the PBA regardless 

Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass

[Wei Liu]

On Thu, Sep 07, 2017 at 01:36:36AM +0200, Dario Faggioli wrote:
> On Wed, 2017-09-06 at 12:29 -0700, Stefano Stabellini wrote:
> > On Wed, 6 Sep 2017, Dario Faggioli wrote:
> > > 
> > > Or, in general, make sense out of the fact that the stack pointer
> > > register changes in such a way that, when we get back in
> > > do_softirq(),
> > > what's in the stack in the place where there was the 'cpu' local
> > > variable has (at least in some circumstances) changed?
> > 
> > I think yes, it could cause the smp_processor_id() mismatch.
> >
> Ok, then the patch was wrong (sorry again), and should stay reverted. 
> 
> I still find the comment very confusing (if correct at all), and I'll
> probably send a new patch to improve it.
> 

Yes please. :-)

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

Re: [Xen-devel] [PATCH v10 1/3] gitignore: add local vimrc files

[Wei Liu]

On Thu, Sep 07, 2017 at 03:36:00PM +, Petre Ovidiu PIRCALABU wrote:
> On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> > OOI how does this work?
> >
> > You put a .vimrc under xen.git?
> I haven't added the file to the repository, just to .gitignore in order
> to mask it from git. It will help me very much to have it upstream
> because right now I have to cherry-pick it each time I create a local
> branch.
> I'm using neovim and 'MarcWeber/vim-addon-local-vimrc'. My local .vimrc
> is quite simple, just sets the alignment, tabs and tabspace according
> to the xen coding standard.
> 

Thanks for the pointer.

I have no objection to this patch. Adding a new entry in .gitignore
which makes developers' life easier is a clear win to me.

Acked-by: Wei Liu 

> //Petre
> >
> > On Wed, Sep 06, 2017 at 04:48:24PM +0300, Petre Pircalabu wrote:
> > >
> > > Signed-off-by: Petre Pircalabu 
> > > ---
> > >  .gitignore | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/.gitignore b/.gitignore
> > > index 594ffd9..8af9c02 100644
> > > --- a/.gitignore
> > > +++ b/.gitignore
> > > @@ -27,6 +27,7 @@ cscope.in.out
> > >  cscope.out
> > >  cscope.po.out
> > >  .config
> > > +.vimrc
> > >
> > >  dist
> > >  stubdom/*.tar.gz
> 
> 
> This email was scanned by Bitdefender
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v10 1/3] gitignore: add local vimrc files

[Petre Ovidiu PIRCALABU]

On Jo, 2017-09-07 at 15:59 +0100, Wei Liu wrote:
> OOI how does this work?
>
> You put a .vimrc under xen.git?
I haven't added the file to the repository, just to .gitignore in order
to mask it from git. It will help me very much to have it upstream
because right now I have to cherry-pick it each time I create a local
branch.
I'm using neovim and 'MarcWeber/vim-addon-local-vimrc'. My local .vimrc
is quite simple, just sets the alignment, tabs and tabspace according
to the xen coding standard.

//Petre
>
> On Wed, Sep 06, 2017 at 04:48:24PM +0300, Petre Pircalabu wrote:
> >
> > Signed-off-by: Petre Pircalabu 
> > ---
> >  .gitignore | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/.gitignore b/.gitignore
> > index 594ffd9..8af9c02 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -27,6 +27,7 @@ cscope.in.out
> >  cscope.out
> >  cscope.po.out
> >  .config
> > +.vimrc
> >
> >  dist
> >  stubdom/*.tar.gz


This email was scanned by Bitdefender
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-smoke test] 113127: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   6 xen-installfail pass in 113126

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl 13 migrate-support-check fail in 113126 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 113126 never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  65c256266477e72f455a45a54597d5816646c74f
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z3 days
Failing since113052  2017-09-05 13:01:29 Z2 days   23 attempts
Testing same since   113097  2017-09-06 17:02:46 Z0 days   11 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs
broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken

Not pushing.


commit 65c256266477e72f455a45a54597d5816646c74f
Author: Yi Sun 
Date:   Mon Sep 4 19:01:44 2017 +0800

tools: change the type of '*nr' in 'libxl_psr_cat_get_info'

Due to historical reason, type of parameter '*nr' in 
'libxl_psr_cat_get_info'
is 'int'. But this is not right. It should be 'unsigned int'. This patch 
fixes
this and does related changes.

Suggested-by: Roger Pau Monné 
Signed-off-by: Yi Sun 
Acked-by: Wei Liu 

commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329
Author: Yi Sun 
Date:   Mon Sep 4 19:01:43 2017 +0800

tools: use '__i386__' and '__x86_64__' to replace PSR macros

The libxl interfaces and related functions are not necessary to be included 
by
'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86
macros. Furthermore, only compile 'xl_psr.c' under x86.

Suggested-by: Roger Pau Monné 
Suggested-by: Wei Liu 
Signed-off-by: Yi Sun 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 

commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5
Author: Jan Beulich 
Date:   Wed 

Re: [Xen-devel] [PATCH v5 10/11] vpci: add a priority parameter to the vPCI register initializer

[Jan Beulich]

>>> On 14.08.17 at 16:28,  wrote:
> This is needed for MSI-X, since MSI-X will need to be initialized
> before parsing the BARs, so that the header BAR handlers are aware of
> the MSI-X related holes and make sure they are not mapped in order for
> the trap handlers to work properly.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v4 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Roger Pau Monné]

On Thu, Sep 07, 2017 at 03:59:05PM +0100, Wei Liu wrote:
> On Thu, Sep 07, 2017 at 03:56:16PM +0100, Roger Pau Monné wrote:
> > On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
[...]
> > > +/* Make sure the page has not been allocated */
> > > +if ( gfn_eq(iorp->gfn, INVALID_GFN) )
> > > +return -EPERM;
> > > +
> > > +return 0;
> > > +}
> > > +
> > >  if ( d->is_dying )
> > >  return -EINVAL;
> > >  
> > > @@ -272,6 +281,57 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server 
> > > *s, bool buf)
> > >  return rc;
> > >  }
> > >  
> > > +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> > > +{
> > > +struct domain *currd = current->domain;
> > > +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> > > +
> > > +if ( iorp->page )
> > > +{
> > > +/* Make sure the page has not been mapped */
> > 
> > Maybe it's just me being slightly lost, but here you imply that
> > iorp->gfn being != INVALID_GFN means the page is mapped, while above
> > you mention allocated for the same check.
> > 
> > Is it because gfn has different usages depending on the context?
> > 
> 
> Haha, I'm not the only one who got confused while reading the patch. ;-)
> 
> That's because the "page" can be obtained via two different methods.
> 
> "Allocated" means getting it from xen heap, "mapped" means mapping guest
> page afaict.

Oh, thanks. I think the comment should be slightly expanded then to
give more context, or else someone else is likely to trip over this
again IMHO.

Roger.

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

Re: [Xen-devel] [PATCH v5 09/11] vpci/msi: add MSI handlers

[Jan Beulich]

>>> On 14.08.17 at 16:28,  wrote:
> +static unsigned int msi_flags(uint16_t data, uint64_t addr)
> +{
> +unsigned int rh, dm, dest_id, deliv_mode, trig_mode;
> +
> +rh = MASK_EXTR(addr, MSI_ADDR_REDIRECTION_MASK);
> +dm = MASK_EXTR(addr, MSI_ADDR_DESTMODE_MASK);
> +dest_id = MASK_EXTR(addr, MSI_ADDR_DEST_ID_MASK);
> +deliv_mode = MASK_EXTR(data, MSI_DATA_DELIVERY_MODE_MASK);
> +trig_mode = MASK_EXTR(data, MSI_DATA_TRIGGER_MASK);
> +
> +return (dest_id << GFLAGS_SHIFT_DEST_ID) | (rh << GFLAGS_SHIFT_RH) |
> +   (dm << GFLAGS_SHIFT_DM) | (deliv_mode << GFLAGS_SHIFT_DELIV_MODE) 
> |
> +   (trig_mode << GFLAGS_SHIFT_TRG_MODE);

This would need re-basing over the removal of those GFLAGS_*
values anyway, but do you really mean those? There's no domctl
involved here I think, and hence I think you rather mean the x86
architecture mandated macros found in asm-x86/msi.h. Or wait,
no, I've just found the caller - you instead want to name the
function msi_gflags() and perhaps add comment on why you
need to use the domctl constants here.

> +void vpci_msi_arch_mask(struct vpci_arch_msi *arch, struct pci_dev *pdev,

Presumably constification of pdev here and elsewhere will come as
a result of doing so at the callback layer. If not, helper functions
not needing to alter it should have it const nevertheless.

> +unsigned int entry, bool mask)
> +{
> +struct domain *d = pdev->domain;

This one probably can be const too.

> +int vpci_msi_arch_enable(struct vpci_arch_msi *arch, struct pci_dev *pdev,
> + uint64_t address, uint32_t data, unsigned int 
> vectors)
> +{
> +struct msi_info msi_info = {
> +.seg = pdev->seg,
> +.bus = pdev->bus,
> +.devfn = pdev->devfn,
> +.entry_nr = vectors,
> +};
> +unsigned int i;
> +int rc;
> +
> +ASSERT(arch->pirq == INVALID_PIRQ);
> +
> +/* Get a PIRQ. */
> +rc = allocate_and_map_msi_pirq(pdev->domain, -1, >pirq,
> +   MAP_PIRQ_TYPE_MULTI_MSI, _info);
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR, "%04x:%02x:%02x.%u: failed to map PIRQ: %d\n",
> + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), rc);
> +return rc;
> +}
> +
> +for ( i = 0; i < vectors; i++ )
> +{
> +xen_domctl_bind_pt_irq_t bind = {
> +.machine_irq = arch->pirq + i,
> +.irq_type = PT_IRQ_TYPE_MSI,
> +.u.msi.gvec = msi_vector(data) + i,

Isn't that rather msi_vector(data + i), i.e. wouldn't you better
increment data together with i?

> +.u.msi.gflags = msi_flags(data, address),
> +};
> +
> +pcidevs_lock();
> +rc = pt_irq_create_bind(pdev->domain, );
> +if ( rc )
> +{
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
> + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), arch->pirq + i, rc);
> +while ( bind.machine_irq-- )
> +pt_irq_destroy_bind(pdev->domain, );
> +spin_lock(>domain->event_lock);
> +unmap_domain_pirq(pdev->domain, arch->pirq);
> +spin_unlock(>domain->event_lock);
> +pcidevs_unlock();
> +arch->pirq = -1;

INVALID_PIRQ ?

> +int vpci_msi_arch_disable(struct vpci_arch_msi *arch, struct pci_dev *pdev,
> +  unsigned int vectors)
> +{
> +unsigned int i;
> +
> +ASSERT(arch->pirq != INVALID_PIRQ);
> +
> +pcidevs_lock();
> +for ( i = 0; i < vectors; i++ )
> +{
> +xen_domctl_bind_pt_irq_t bind = {
> +.machine_irq = arch->pirq + i,
> +.irq_type = PT_IRQ_TYPE_MSI,
> +};
> +int rc;
> +
> +rc = pt_irq_destroy_bind(pdev->domain, );
> +gdprintk(XENLOG_ERR,
> + "%04x:%02x:%02x.%u: failed to unbind PIRQ %u: %d\n",
> + pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), arch->pirq + i, rc);

Couldn't this be ASSERT(!rc)? Afaics all error paths in that function
are due to passing in invalid state or information.

> +static int vpci_msi_disable(struct pci_dev *pdev, struct vpci_msi *msi)
> +{
> +int ret;
> +
> +ASSERT(msi->enabled);
> +__msi_set_enable(pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> + PCI_FUNC(pdev->devfn), msi->pos, 0);
> +
> +ret = vpci_msi_arch_disable(>arch, pdev, msi->vectors);
> +if ( ret )
> +return ret;
> +
> +msi->enabled = false;
> +
> +return 0;
> +}

Please invert the if() condition and have both cases reach the final
return.

> +static void vpci_msi_control_write(struct pci_dev *pdev, unsigned int reg,
> +   uint32_t val, void *data)
> +{
> +struct 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 89796c69d9fdaa9bd13d37b6b1687df5e0104ed5
baseline version:
 ovmf b80a4097393c90d041b299ef628e6104612a2586

Last test of basis   113078  2017-09-06 11:47:39 Z1 days
Testing same since   113115  2017-09-07 01:18:59 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Ge Song 
  Laszlo Ersek 

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

Re: [Xen-devel] [PATCH 1/4] MAINTAINERS: orphan blktap2

[Wei Liu]

On Thu, Sep 07, 2017 at 12:04:21PM +0100, George Dunlap wrote:
> On 09/04/2017 02:44 PM, Wei Liu wrote:
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Andrew Cooper 
> > Cc: George Dunlap 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Stefano Stabellini 
> > Cc: Tim Deegan 
> > Cc: Wei Liu 
> > ---
> >  MAINTAINERS | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 5b9e1233a8..ca8cbf276e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -175,6 +175,10 @@ F: xen/drivers/char/pl011.c
> >  F: xen/drivers/char/scif-uart.c
> >  F: xen/drivers/passthrough/arm/
> >  
> > +BLOCKTAP
> 
> I think this should just be BLKTAP2.

OK.

> 
> > +S: Orphaned
> > +F: tools/blktap2/
> 
> Acked-by: George Dunlap 

Thanks.

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

Re: [Xen-devel] [PATCH v4 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Jan Beulich]

>>> On 07.09.17 at 16:51,  wrote:
> On 07/09/17 16:41, Roger Pau Monné wrote:
>> On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
>>> A subsequent patch will remove the current implicit limitation on creation
>>> of ioreq servers which is due to the allocation of gfns for the ioreq
>>> structures and buffered ioreq ring.
>>>
>>> It will therefore be necessary to introduce an explicit limit and, since
>>> this limit should be small, it simplifies the code to maintain an array of
>>> that size rather than using a list.
>>>
>>> Also, by reserving an array slot for the default server and populating
>>> array slots early in create, the need to pass an 'is_default' boolean
>>> to sub-functions can be avoided.
>>>
>>> Signed-off-by: Paul Durrant 
>> 
>> LGTM, just a couple of nitpicks, I think they can be fixed upon commit
>> if desired.
>> 
>> Reviewed-by: Roger Pau Monné 
>> 
>>> ---
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>>
>>> v4:
>>>  - Introduced more helper macros and relocated them to the top of the
>>>code.
>>>
>>> v3:
>>>  - New patch (replacing "move is_default into struct hvm_ioreq_server") in
>>>response to review comments.
>>> ---
>>>  xen/arch/x86/hvm/ioreq.c | 491 
> ++-
>>>  xen/include/asm-x86/hvm/domain.h |  11 +-
>>>  2 files changed, 235 insertions(+), 267 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
>>> index f2e0b3f74a..287572bd1f 100644
>>> --- a/xen/arch/x86/hvm/ioreq.c
>>> +++ b/xen/arch/x86/hvm/ioreq.c
>>> @@ -33,6 +33,22 @@
>>>  
>>>  #include 
>>>  
>>> +#define SET_IOREQ_SERVER(d, id, s) \
>>> +(d)->arch.hvm_domain.ioreq_server.server[id] = (s)
>> 
>> Are the parentheses around s required?
>> 
>>> +
>>> +#define GET_IOREQ_SERVER(d, id) \
>>> +(((id) < MAX_NR_IOREQ_SERVERS) ? \
>>> + (d)->arch.hvm_domain.ioreq_server.server[id] : \
>>> + NULL)
>>> +
>>> +#define FOR_EACH_IOREQ_SERVER(d, id, s) \
>>> +for ( (id) = 0, (s) = GET_IOREQ_SERVER((d), (id)); \
>>> +  (id) < MAX_NR_IOREQ_SERVERS; \
>>> +  (id)++, (s) = GET_IOREQ_SERVER((d), (id)) )
>> 
>> Same here about the parentheses around s, d and id in the
>> GET_IOREQ_SERVER calls. In fact you could compact the afterthought as:
>> 
>> s = GET_IOREQ_SERVER(d, ++(id))
> 
> Uuh, this would be wrong: id is used twice in GET_IOREQ_SERVER(), so it
> would be incremented twice...

Which suggests that GET_IOREQ_SERVER() might better use a local
variable.

Btw, somewhere on the path here Paul and Roger have got dropped
from the list of recipients...

Jan

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

[Xen-devel] [linux-linus test] 113104: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-xsm  broken
 build-arm64-pvopsbroken
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 113031
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113031

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 113067 pass in 
113104
 test-armhf-armhf-xl-xsm   6 xen-installfail pass in 113067
 test-amd64-amd64-xl-qemut-debianhvm-amd64 17 guest-stopfail pass in 113067

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 113031
 build-arm64-pvops 2 hosts-allocate  broken like 113031
 build-arm64-xsm   3 capture-logsbroken like 113031
 build-arm64-pvops 3 capture-logsbroken like 113031
 build-arm64   2 hosts-allocate  broken like 113031
 build-arm64   3 capture-logsbroken like 113031
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 113031
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
113031
 test-armhf-armhf-xl-rtds 12 guest-start fail in 113067 like 113031
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 113067 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 113067 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113031
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113031
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113031
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113031
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 

Re: [Xen-devel] [PATCH v10 2/3] x86emul: New return code for unimplemented instruction

[Jan Beulich]

>>> On 07.09.17 at 16:26,  wrote:
> After discussing with Andrew I'm willing to agree with the changes
> you do here, with one extra requirement: At least on non-debug
> builds X86EMUL_UNIMPLEMENTED should always result in #UD being
> raised by the final consumer of it. It should never, like would be
> the case with the changes you do to vmx/realmode.c, result in
> the domain being crashed. Please change that one and check
> carefully whether there are any other similar cases.

Oh, and please make the comment next to the definition of
X86EMUL_UNIMPLEMENTED also say so.

Jan


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

Re: [Xen-devel] [PATCH v4 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Roger Pau Monné]

On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
> ... XENMEM_resource_ioreq_server
> 
> This patch adds support for a new resource type that can be mapped using
> the XENMEM_acquire_resource memory op.
> 
> If an emulator makes use of this resource type then, instead of mapping
> gfns, the IOREQ server will allocate pages from the heap. These pages
> will never be present in the P2M of the guest at any point and so are
> not vulnerable to any direct attack by the guest. They are only ever
> accessible by Xen and any domain that has mapping privilege over the
> guest (which may or may not be limited to the domain running the emulator).
> 
> NOTE: Use of the new resource type is not compatible with use of
>   XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
>   set.
> 
> Signed-off-by: Paul Durrant 
> Acked-by: George Dunlap 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Ian Jackson 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  xen/arch/x86/hvm/ioreq.c| 123 
> +++-
>  xen/arch/x86/mm.c   |  27 +
>  xen/include/asm-x86/hvm/ioreq.h |   2 +
>  xen/include/public/hvm/dm_op.h  |   4 ++
>  xen/include/public/memory.h |   3 +
>  5 files changed, 158 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index 158bfbba32..f4c06a7a2a 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -250,6 +250,15 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
> bool buf)
>  struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
>  int rc;
>  
> +if ( iorp->page )
> +{
> +/* Make sure the page has not been allocated */
> +if ( gfn_eq(iorp->gfn, INVALID_GFN) )
> +return -EPERM;
> +
> +return 0;
> +}
> +
>  if ( d->is_dying )
>  return -EINVAL;
>  
> @@ -272,6 +281,57 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
> bool buf)
>  return rc;
>  }
>  
> +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> +{
> +struct domain *currd = current->domain;
> +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> +
> +if ( iorp->page )
> +{
> +/* Make sure the page has not been mapped */

Maybe it's just me being slightly lost, but here you imply that
iorp->gfn being != INVALID_GFN means the page is mapped, while above
you mention allocated for the same check.

Is it because gfn has different usages depending on the context?

> +if ( !gfn_eq(iorp->gfn, INVALID_GFN) )
> +return -EPERM;
[...]
> +mfn_t hvm_get_ioreq_server_frame(struct domain *d, ioservid_t id,
> + unsigned int idx)
> +{
> +struct hvm_ioreq_server *s;
> +mfn_t mfn = INVALID_MFN;
> +
> +spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
> +
> +s = d->arch.hvm_domain.ioreq_server.server[id];

Can't you use GET_IOREQ_SERVER here?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v4 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Roger Pau Monné]

On Thu, Sep 07, 2017 at 04:51:53PM +0200, Juergen Gross wrote:
> On 07/09/17 16:41, Roger Pau Monné wrote:
> > On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
> >> A subsequent patch will remove the current implicit limitation on creation
> >> of ioreq servers which is due to the allocation of gfns for the ioreq
> >> structures and buffered ioreq ring.
> >>
> >> It will therefore be necessary to introduce an explicit limit and, since
> >> this limit should be small, it simplifies the code to maintain an array of
> >> that size rather than using a list.
> >>
> >> Also, by reserving an array slot for the default server and populating
> >> array slots early in create, the need to pass an 'is_default' boolean
> >> to sub-functions can be avoided.
> >>
> >> Signed-off-by: Paul Durrant 
> > 
> > LGTM, just a couple of nitpicks, I think they can be fixed upon commit
> > if desired.
> > 
> > Reviewed-by: Roger Pau Monné 
> > 
> >> ---
> >> Cc: Jan Beulich 
> >> Cc: Andrew Cooper 
> >>
> >> v4:
> >>  - Introduced more helper macros and relocated them to the top of the
> >>code.
> >>
> >> v3:
> >>  - New patch (replacing "move is_default into struct hvm_ioreq_server") in
> >>response to review comments.
> >> ---
> >>  xen/arch/x86/hvm/ioreq.c | 491 
> >> ++-
> >>  xen/include/asm-x86/hvm/domain.h |  11 +-
> >>  2 files changed, 235 insertions(+), 267 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> >> index f2e0b3f74a..287572bd1f 100644
> >> --- a/xen/arch/x86/hvm/ioreq.c
> >> +++ b/xen/arch/x86/hvm/ioreq.c
> >> @@ -33,6 +33,22 @@
> >>  
> >>  #include 
> >>  
> >> +#define SET_IOREQ_SERVER(d, id, s) \
> >> +(d)->arch.hvm_domain.ioreq_server.server[id] = (s)
> > 
> > Are the parentheses around s required?
> > 
> >> +
> >> +#define GET_IOREQ_SERVER(d, id) \
> >> +(((id) < MAX_NR_IOREQ_SERVERS) ? \
> >> + (d)->arch.hvm_domain.ioreq_server.server[id] : \
> >> + NULL)
> >> +
> >> +#define FOR_EACH_IOREQ_SERVER(d, id, s) \
> >> +for ( (id) = 0, (s) = GET_IOREQ_SERVER((d), (id)); \
> >> +  (id) < MAX_NR_IOREQ_SERVERS; \
> >> +  (id)++, (s) = GET_IOREQ_SERVER((d), (id)) )
> > 
> > Same here about the parentheses around s, d and id in the
> > GET_IOREQ_SERVER calls. In fact you could compact the afterthought as:
> > 
> > s = GET_IOREQ_SERVER(d, ++(id))
> 
> Uuh, this would be wrong: id is used twice in GET_IOREQ_SERVER(), so it
> would be incremented twice...

Heh, right, the dangers of macro expansion. GET_IOREQ_SERVER does more
than simply fetching the struct from the array.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v10 1/3] gitignore: add local vimrc files

[Wei Liu]

OOI how does this work?

You put a .vimrc under xen.git?

On Wed, Sep 06, 2017 at 04:48:24PM +0300, Petre Pircalabu wrote:
> Signed-off-by: Petre Pircalabu 
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 594ffd9..8af9c02 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -27,6 +27,7 @@ cscope.in.out
>  cscope.out
>  cscope.po.out
>  .config
> +.vimrc
>  
>  dist
>  stubdom/*.tar.gz
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH v4 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Wei Liu]

On Thu, Sep 07, 2017 at 03:56:16PM +0100, Roger Pau Monné wrote:
> On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
> > ... XENMEM_resource_ioreq_server
> > 
> > This patch adds support for a new resource type that can be mapped using
> > the XENMEM_acquire_resource memory op.
> > 
> > If an emulator makes use of this resource type then, instead of mapping
> > gfns, the IOREQ server will allocate pages from the heap. These pages
> > will never be present in the P2M of the guest at any point and so are
> > not vulnerable to any direct attack by the guest. They are only ever
> > accessible by Xen and any domain that has mapping privilege over the
> > guest (which may or may not be limited to the domain running the emulator).
> > 
> > NOTE: Use of the new resource type is not compatible with use of
> >   XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
> >   set.
> > 
> > Signed-off-by: Paul Durrant 
> > Acked-by: George Dunlap 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Ian Jackson 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Stefano Stabellini 
> > Cc: Tim Deegan 
> > Cc: Wei Liu 
> > ---
> >  xen/arch/x86/hvm/ioreq.c| 123 
> > +++-
> >  xen/arch/x86/mm.c   |  27 +
> >  xen/include/asm-x86/hvm/ioreq.h |   2 +
> >  xen/include/public/hvm/dm_op.h  |   4 ++
> >  xen/include/public/memory.h |   3 +
> >  5 files changed, 158 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> > index 158bfbba32..f4c06a7a2a 100644
> > --- a/xen/arch/x86/hvm/ioreq.c
> > +++ b/xen/arch/x86/hvm/ioreq.c
> > @@ -250,6 +250,15 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server 
> > *s, bool buf)
> >  struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> >  int rc;
> >  
> > +if ( iorp->page )
> > +{
> > +/* Make sure the page has not been allocated */
> > +if ( gfn_eq(iorp->gfn, INVALID_GFN) )
> > +return -EPERM;
> > +
> > +return 0;
> > +}
> > +
> >  if ( d->is_dying )
> >  return -EINVAL;
> >  
> > @@ -272,6 +281,57 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server 
> > *s, bool buf)
> >  return rc;
> >  }
> >  
> > +static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> > +{
> > +struct domain *currd = current->domain;
> > +struct hvm_ioreq_page *iorp = buf ? >bufioreq : >ioreq;
> > +
> > +if ( iorp->page )
> > +{
> > +/* Make sure the page has not been mapped */
> 
> Maybe it's just me being slightly lost, but here you imply that
> iorp->gfn being != INVALID_GFN means the page is mapped, while above
> you mention allocated for the same check.
> 
> Is it because gfn has different usages depending on the context?
> 

Haha, I'm not the only one who got confused while reading the patch. ;-)

That's because the "page" can be obtained via two different methods.

"Allocated" means getting it from xen heap, "mapped" means mapping guest
page afaict.

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

[Xen-devel] [linux-3.18 test] 113110: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64-pvopsbroken
 build-arm64-xsm  broken
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  6 xen-install  fail in 113072 pass in 113110
 test-armhf-armhf-xl-rtds  7 xen-boot fail in 113072 pass in 113110
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail in 
113072 pass in 113110
 test-armhf-armhf-xl   7 xen-boot   fail pass in 113072

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 112102
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 113072 blocked in 
112102
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 113072 
blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 113072 
like 112102
 test-armhf-armhf-xl 13 migrate-support-check fail in 113072 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 113072 never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-check

Re: [Xen-devel] [PATCH 1/2 v3] xenfb: Use Input Handlers directly

[Anthony PERARD]

On Mon, Aug 21, 2017 at 04:12:27PM -0700, Stefano Stabellini wrote:
> Anthony,
> 
> The code looks good. I tested this patch with Linux guests and seems to
> work OK, can you also confirm?

I've tested with Linux as well, an HVM guess, I did not spot any issue.

But, the code compiles with warnings...

In file included from 
/root/build/qemu/include/standard-headers/linux/input.h:16:0,
 from hw/display/xenfb.c:41:
/root/build/qemu/include/standard-headers/linux/input-event-codes.h:88:0: 
error: "KEY_BACKSPACE" redefined [-Werror]
 #define KEY_BACKSPACE  14
 
In file included from /root/build/qemu/include/ui/console.h:342:0,
 from hw/display/xenfb.c:31:
/usr/include/curses.h:1494:0: note: this is the location of the previous 
definition
 #define KEY_BACKSPACE 0407  /* backspace key */
 
In file included from 
/root/build/qemu/include/standard-headers/linux/input.h:16:0,
 from hw/display/xenfb.c:41:
/root/build/qemu/include/standard-headers/linux/input-event-codes.h:102:0: 
error: "KEY_ENTER" redefined [-Werror]
 #define KEY_ENTER  28
 
In file included from /root/build/qemu/include/ui/console.h:342:0,
 from hw/display/xenfb.c:31:
/usr/include/curses.h:1512:0: note: this is the location of the previous 
definition
 #define KEY_ENTER 0527  /* enter/send key */
 
In file included from 
/root/build/qemu/include/standard-headers/linux/input.h:16:0,
 from hw/display/xenfb.c:41:
/root/build/qemu/include/standard-headers/linux/input-event-codes.h:107:0: 
error: "KEY_F" redefined [-Werror]
 #define KEY_F   33
 
In file included from /root/build/qemu/include/ui/console.h:342:0,
 from hw/display/xenfb.c:31:
/usr/include/curses.h:1496:0: note: this is the location of the previous 
definition
 #define KEY_F(n) (KEY_F0+(n)) /* Value of function key n */
[...]

And a lot more...

-- 
Anthony PERARD

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

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

[Wei Liu]

On Thu, Sep 07, 2017 at 02:52:49PM +0100, George Dunlap wrote:
> On 09/01/2017 04:00 PM, Wei Liu wrote:
> > On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
> >> +### Direct-boot kernel image format
> >> +
> >> +Supported, x86: bzImage
> > 
> > Do you mean booting a PV guest? If so there are a few more formats.
> > 
> >> +Supported, ARM32: zImage
> >> +Supported, ARM64: Image [XXX - Not sure if this is correct]
> >> +
> >> +Format which the toolstack accept for direct-boot kernels
> > [...]
> >> +### JSON support for xl
> >> +
> >> +Status: Preview
> >> +
> > 
> > What is this?
> 
> JSON output; e.g., `xl list -l`.
> 
> Perhaps this should be called 'JSON output support'. :-)
> 

OK. Anyway, no security support for this please. I'm not even very sure
if the output is going to be stable.

> >> +### AHCI support for xl
> >> +
> >> +Status, x86: Supported
> >> +
> > 
> > There is only one knob to change, I'm not sure whether makes sense to
> > list it separately.
> > 
> >> +### Soft-reset for xl
> >> +
> >> +Status: Supported
> >> +
> > 
> > We never tested this in osstest so I'm not sure about if this is the
> > correct status. Furthermore there is also moving parts in hypervisor.
> 
> Hmm, maybe this would go better under a hypervisor section somewhere; as
> you say, the core functionality doesn't reside in xl, xl just enables it.
> 

A bit more than that, there are moving parts in libxl to handle that as
well -- some initialisation needs to be skipped or whatever, some can't.

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

Re: [Xen-devel] [PATCH v4 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Juergen Gross]

On 07/09/17 16:41, Roger Pau Monné wrote:
> On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
>> A subsequent patch will remove the current implicit limitation on creation
>> of ioreq servers which is due to the allocation of gfns for the ioreq
>> structures and buffered ioreq ring.
>>
>> It will therefore be necessary to introduce an explicit limit and, since
>> this limit should be small, it simplifies the code to maintain an array of
>> that size rather than using a list.
>>
>> Also, by reserving an array slot for the default server and populating
>> array slots early in create, the need to pass an 'is_default' boolean
>> to sub-functions can be avoided.
>>
>> Signed-off-by: Paul Durrant 
> 
> LGTM, just a couple of nitpicks, I think they can be fixed upon commit
> if desired.
> 
> Reviewed-by: Roger Pau Monné 
> 
>> ---
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>>
>> v4:
>>  - Introduced more helper macros and relocated them to the top of the
>>code.
>>
>> v3:
>>  - New patch (replacing "move is_default into struct hvm_ioreq_server") in
>>response to review comments.
>> ---
>>  xen/arch/x86/hvm/ioreq.c | 491 
>> ++-
>>  xen/include/asm-x86/hvm/domain.h |  11 +-
>>  2 files changed, 235 insertions(+), 267 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
>> index f2e0b3f74a..287572bd1f 100644
>> --- a/xen/arch/x86/hvm/ioreq.c
>> +++ b/xen/arch/x86/hvm/ioreq.c
>> @@ -33,6 +33,22 @@
>>  
>>  #include 
>>  
>> +#define SET_IOREQ_SERVER(d, id, s) \
>> +(d)->arch.hvm_domain.ioreq_server.server[id] = (s)
> 
> Are the parentheses around s required?
> 
>> +
>> +#define GET_IOREQ_SERVER(d, id) \
>> +(((id) < MAX_NR_IOREQ_SERVERS) ? \
>> + (d)->arch.hvm_domain.ioreq_server.server[id] : \
>> + NULL)
>> +
>> +#define FOR_EACH_IOREQ_SERVER(d, id, s) \
>> +for ( (id) = 0, (s) = GET_IOREQ_SERVER((d), (id)); \
>> +  (id) < MAX_NR_IOREQ_SERVERS; \
>> +  (id)++, (s) = GET_IOREQ_SERVER((d), (id)) )
> 
> Same here about the parentheses around s, d and id in the
> GET_IOREQ_SERVER calls. In fact you could compact the afterthought as:
> 
> s = GET_IOREQ_SERVER(d, ++(id))

Uuh, this would be wrong: id is used twice in GET_IOREQ_SERVER(), so it
would be incremented twice...


Juergen

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

Re: [Xen-devel] [PATCH] x86/page: Implement {get, set}_pte_flags() as static inlines

[Wei Liu]

On Thu, Sep 07, 2017 at 02:39:57PM +0100, Andrew Cooper wrote:
> This resolves 11 Coverity issues along the lines of the following:
> 
> 1600for ( i = 0; i < NR_RESERVED_GDT_PAGES; i++ )
> 
> CID: Operands don't affect result
> (CONSTANT_EXPRESSION_RESULT)result_independent_of_operands: ((33U /* 1U |
> 0x20U */) | (({...}) ? 8388608U /* 1U << 23 */ : 0) | 0x40U | 2U) & 4095
> is always 0x63 regardless of the values of its operands. This occurs as
> the bitwise second operand of "|".
> 
> 1601l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,
> 1602  l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR_RW));
> 
> This is presumably because once preprocessed, the association of joint logic
> inside {get,set}_pte_flags() is lost.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:16PM +0100, Paul Durrant wrote:
>  
> +mfn_t hvm_get_ioreq_server_frame(struct domain *d, ioservid_t id,
> + unsigned int idx)
> +{
> +struct hvm_ioreq_server *s;
> +mfn_t mfn = INVALID_MFN;
> +
> +spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
> +
> +s = d->arch.hvm_domain.ioreq_server.server[id];
> +

Check id < MAX_NR_IOREQ_SERVERS before getting s?

> +if ( id >= MAX_NR_IOREQ_SERVERS || !s || IS_DEFAULT(s) )
> +goto out;
> +
> +if ( hvm_ioreq_server_alloc_pages(s) )
> +goto out;
> +
> +if ( idx == 0 )
> +mfn = _mfn(page_to_mfn(s->bufioreq.page));
> +else if ( idx == 1 )
> +mfn = _mfn(page_to_mfn(s->ioreq.page));

Does the caller care about the order? If so this should be documented?

The rest looks sensible but I haven't reviewed in detail.

> +
> + out:
> +spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
> +
> +return mfn;
> +}
> +

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

Re: [Xen-devel] [PATCH v4 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Roger Pau Monné]

On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
> A subsequent patch will remove the current implicit limitation on creation
> of ioreq servers which is due to the allocation of gfns for the ioreq
> structures and buffered ioreq ring.
> 
> It will therefore be necessary to introduce an explicit limit and, since
> this limit should be small, it simplifies the code to maintain an array of
> that size rather than using a list.
> 
> Also, by reserving an array slot for the default server and populating
> array slots early in create, the need to pass an 'is_default' boolean
> to sub-functions can be avoided.
> 
> Signed-off-by: Paul Durrant 

LGTM, just a couple of nitpicks, I think they can be fixed upon commit
if desired.

Reviewed-by: Roger Pau Monné 

> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> 
> v4:
>  - Introduced more helper macros and relocated them to the top of the
>code.
> 
> v3:
>  - New patch (replacing "move is_default into struct hvm_ioreq_server") in
>response to review comments.
> ---
>  xen/arch/x86/hvm/ioreq.c | 491 
> ++-
>  xen/include/asm-x86/hvm/domain.h |  11 +-
>  2 files changed, 235 insertions(+), 267 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> index f2e0b3f74a..287572bd1f 100644
> --- a/xen/arch/x86/hvm/ioreq.c
> +++ b/xen/arch/x86/hvm/ioreq.c
> @@ -33,6 +33,22 @@
>  
>  #include 
>  
> +#define SET_IOREQ_SERVER(d, id, s) \
> +(d)->arch.hvm_domain.ioreq_server.server[id] = (s)

Are the parentheses around s required?

> +
> +#define GET_IOREQ_SERVER(d, id) \
> +(((id) < MAX_NR_IOREQ_SERVERS) ? \
> + (d)->arch.hvm_domain.ioreq_server.server[id] : \
> + NULL)
> +
> +#define FOR_EACH_IOREQ_SERVER(d, id, s) \
> +for ( (id) = 0, (s) = GET_IOREQ_SERVER((d), (id)); \
> +  (id) < MAX_NR_IOREQ_SERVERS; \
> +  (id)++, (s) = GET_IOREQ_SERVER((d), (id)) )

Same here about the parentheses around s, d and id in the
GET_IOREQ_SERVER calls. In fact you could compact the afterthought as:

s = GET_IOREQ_SERVER(d, ++(id))

But that's just a nit.

>  int hvm_create_ioreq_server(struct domain *d, domid_t domid,
> @@ -685,52 +674,67 @@ int hvm_create_ioreq_server(struct domain *d, domid_t 
> domid,
>  ioservid_t *id)
>  {
>  struct hvm_ioreq_server *s;
> +unsigned int i;
>  int rc;
>  
>  if ( bufioreq_handling > HVM_IOREQSRV_BUFIOREQ_ATOMIC )
>  return -EINVAL;
>  
> -rc = -ENOMEM;
>  s = xzalloc(struct hvm_ioreq_server);
>  if ( !s )
> -goto fail1;
> +return -ENOMEM;
>  
>  domain_pause(d);
>  spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
>  
> -rc = -EEXIST;
> -if ( is_default && d->arch.hvm_domain.default_ioreq_server != NULL )
> -goto fail2;
> -
> -rc = hvm_ioreq_server_init(s, d, domid, is_default, bufioreq_handling,
> -   next_ioservid(d));
> -if ( rc )
> -goto fail3;
> -
> -list_add(>list_entry,
> - >arch.hvm_domain.ioreq_server.list);
> -
>  if ( is_default )
>  {
> -d->arch.hvm_domain.default_ioreq_server = s;
> -hvm_ioreq_server_enable(s, true);
> +i = DEFAULT_IOSERVID;
> +
> +rc = -EEXIST;
> +if ( GET_IOREQ_SERVER(d, i) )
> +goto fail;
> +}
> +else
> +{
> +for ( i = 0; i < MAX_NR_IOREQ_SERVERS; i++ )
> +{
> +if ( i != DEFAULT_IOSERVID &&
> + !GET_IOREQ_SERVER(d, i) )

No need for the newline, the condition fits in a single line.

And since you have the macros, this could also be written in terms of
FOR_EACH_IOREQ_SERVER. Not really sure it's worth it anyway, you would
have to introduce another struct hvm_ioreq_server pointer here.

> +break;
> +}
> +
> +rc = -ENOSPC;
> +if ( i >= MAX_NR_IOREQ_SERVERS )
> +goto fail;
>  }
>  
> +SET_IOREQ_SERVER(d, i, s);
> +
> +rc = hvm_ioreq_server_init(s, d, domid, bufioreq_handling, i);
> +if ( rc )
> +goto fail;
> +
> +if ( IS_DEFAULT(s) )
> +hvm_ioreq_server_enable(s);
> +
>  if ( id )
> -*id = s->id;
> +*id = i;
> +
> +d->arch.hvm_domain.ioreq_server.count++;
>  
>  spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
>  domain_unpause(d);
>  
>  return 0;
>  
> - fail3:
> - fail2:
> + fail:
> +SET_IOREQ_SERVER(d, i, NULL);
> +
>  spin_unlock_recursive(>arch.hvm_domain.ioreq_server.lock);
>  domain_unpause(d);
>  
>  xfree(s);
> - fail1:
>  return rc;
>  }
>  
> @@ -741,35 +745,30 @@ int hvm_destroy_ioreq_server(struct domain *d, 
> ioservid_t id)
>  
>  spin_lock_recursive(>arch.hvm_domain.ioreq_server.lock);
>  
> -rc = -ENOENT;
> -list_for_each_entry ( s,
> - 

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

[George Dunlap]

On 09/07/2017 02:57 PM, Roger Pau Monné wrote:
> On Thu, Sep 07, 2017 at 11:49:00AM +0100, George Dunlap wrote:
>> On 08/31/2017 12:25 PM, Roger Pau Monne wrote:
>>> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:

[snip]

 +### x86/PVH dom0
>>>   ^ v2
 +
 +Status: Experimental
>>>
>>> The status of this is just "not finished". We need at least the PCI
>>> emulation series for having a half-functional PVHv2 Dom0.
>>
>> From the definition of 'Experimental':
>>
>> Functional completeness: No
>> Functional stability: Here be dragons
>> Interface stability: Not stable
>> Security supported: No
>>
>> "Not finished" -> Functional completeness: No -> Experimental.
>>
>> If there's no way of doing anything with dom0 at all we should probably
>> just remove it from the list.
> 
> Right now it should be removed according to the logic above.

Fair enough.

 +### Online resize of virtual disks
 +
 +Status: Supported
>>>
>>> That pretty much depends on where you are actually storing your disks
>>> I guess. I'm not sure we want to make such compromises.
>>
>> What do you mean?
> 
> I'm not sure online resizing is something that needs spelling out
> separately, it's part of how the block protocol works, just like
> indirect descriptors or persistent grants (which are also not listed
> here, and I think that's fine).
> 
 +### x86/HVM iPXE
 +
 +Status: Supported, with caveats
 +
 +Booting a guest via PXE.
 +PXE inherently places full trust of the guest in the network,
 +and so should only be used
 +when the guest network is under the same administrative control
 +as the guest itself.
>>>
>>> Hm, not sure why this needs to be spelled out, it's just like running
>>> any bootloader/firmware inside a HVM guest, which I'm quite sure we
>>> are not going to list here.
>>>
>>> Ie: I don't see us listing OVMF, SeaBIOS or ROMBIOS, simply because
>>> they run inside the guest, so if they are able to cause security
>>> issues, anything else is also capable of causing them.
>>
>> Well iPXE is a feature, so we have to say something about it; and there
>> was a long discussion at the Summit about whether we should list iPXE as
>> "security supported", because *by design* it just runs random code that
>> someone sends it over the network.  But if we say it's not supported, it
>> makes it sound like we think you shouldn't use it.
>>
>> Above was the agreed-upon compromise: to say it was supported but warn
>> people what "supported" means.
> 
> Hm, I'm still not sure this should be explicitly listed here.
> 
> Running random code inside of a guest is not a problem from Xen's PoV,
> and we would never issue a XSA, unless such code is able to break
> outside of the guest, in which case it doesn't matter whether the code
> has been randomly fetched from the network.

That's not true at all.  There are two security boundaries within the
guest: user space -> kernel space, and outside -> [anything].  If there
was a bug in the QEMU network card which allowed a crafted packet to
write into unauthorized memory in the guest, that would be a security
vulnerability, as would a bug which allowed a guest user to make
unauthorized changes to the guest kernel memory (or unauthorized access
to guest devices, ).

> IMHO iPXE is just like any other firmware that Xen supports, such as
> OVMF/SeaBIOS/ROMBIOS, and I don't see them listed here. I'm not sure
> in which way iPXE is special from the other ones that requires such an
> entry in the support document.

Well first of all, the purpose of this document is in fact in part to
enumerate features, not only to talk about security support.  As such,
we probably should list OVMF / BIOS booting as features. :-)

Secondly, I agree that it's hard to imagine what a genuine security bug
in one of these things (iPXE, BIOS, OVMF) would look like.  However, *if
we did find* a bug in one of those pieces of code that allowed an entity
(either guest user or someone not in the guest at all) to make
unauthorized changes, we would definitely need to issue an XSA for it.
That is what "security supported" means.

[snip]

> From a Xen PoV, they are just HVM OSes.  Some of them make use of more
> PV interfaces than others, but all HVM guests have the same set of
> interfaces available to them, and thus the same surface of attack.

Similar to the argument above: XSAs will not only be issued for
violations of the guest -> Xen privilege boundary, but also for the
guest user -> guest kernel privilege boundary.  If one of the
PVHVM-related features has a bug such that it allows a user -> kernel
escalation, we will issue an XSA for it.

> I don't think it makes sense to list PVHVM as a guest type in the list
> of supported features.

Maybe we should group these as "PVHVM acceleration" and put them in a
different section, rather than calling them a separate guest type.

[snip]

 +### ARM/SMMU
 +
 +Status: 

Re: [Xen-devel] [PATCH v10 2/3] x86emul: New return code for unimplemented instruction

[Andrew Cooper]

On 06/09/17 14:48, Petre Pircalabu wrote:
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 64454c7..8a6eb74 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2044,6 +2044,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned 
> long gla)
>  switch ( rc )
>  {
>  case X86EMUL_UNHANDLEABLE:
> +case X86EMUL_UNIMPLEMENTED:
>  hvm_dump_emulation_state(XENLOG_G_WARNING, "MMCFG", );

Please modify hvm_dump_emulation_state to pass rc in, and distinguish
UNHANDLEABLE vs UNIMPLEMENTED in the printed message.

Similarly for other diagnostic messages.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/page: Implement {get, set}_pte_flags() as static inlines

[Jan Beulich]

>>> On 07.09.17 at 15:39,  wrote:
> --- a/xen/include/asm-x86/x86_64/page.h
> +++ b/xen/include/asm-x86/x86_64/page.h
> @@ -121,8 +121,16 @@ typedef l4_pgentry_t root_pgentry_t;
>   */
>  
>  /* Extract flags into 24-bit integer, or turn 24-bit flags into a pte mask. 
> */
> -#define get_pte_flags(x) (((int)((x) >> 40) & ~0xFFF) | ((int)(x) & 0xFFF))
> -#define put_pte_flags(x) (((intpte_t)((x) & ~0xFFF) << 40) | ((x) & 0xFFF))
> +#ifndef __ASSEMBLY__
> +static inline unsigned int get_pte_flags(intpte_t x)
> +{
> +return ((x >> 40) & ~0xfff) | (x & 0xfff);
> +}
> +static inline intpte_t put_pte_flags(unsigned int x)
> +{
> +return (((intpte_t)x & ~0xfff) << 40) | (x & 0xfff);
> +}
> +#endif

With ideally a blank line added between the two
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 26/27 v8] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

[Andre Przywara]

Hi,

On 28/08/17 09:56, Bhupinder Thakur wrote:
> This patch fixes the issue observed when pl011 patches were tested on
> the junos hardware by Andre/Julien. It was observed that when large output is
> generated such as on running 'find /', output was getting truncated 
> intermittently
> due to OUT ring buffer getting full.
> 
> This issue was due to the fact that the SBSA UART driver expects that when
> a TX interrupt is asserted then the FIFO queue should be atleast half empty 
> and
> that it can write N bytes in the FIFO, where N is half the FIFO queue size, 
> without
> the bytes getting dropped due to FIFO getting full.
> 
> This requirement is as per section 3.4.2 of [1], which is:
> 
> ---
> UARTTXINTR
> 
> If the FIFOs are enabled and the transmit FIFO reaches the programmed
> trigger level. When this happens, the transmit interrupt is asserted HIGH. The
> transmit interrupt is cleared by writing data to the transmit FIFO until it
> becomes greater than the trigger level, or by clearing the interrupt.
> ---
> 
> The SBSA UART fifo size is 32 bytes and so it expects that space for 16 bytes
> should be available when TX interrupt is asserted.
> 
> The pl011 emulation logic was asserting the TX interrupt as soon as
> any space became available in the FIFO and the SBSA UART driver tried to write
> more data (upto 16 bytes) in the FIFO expecting that there is enough space
> available.
> 
> The fix was to ensure that the TX interriupt is raised only when there
> is space available for 16 bytes or more in the FIFO.
> 
> [1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> CC: Julien Grall 
> CC: Andre Przywara 
> CC: Stefano Stabellini 
> 
>  xen/arch/arm/vpl011.c | 29 +++--
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/vpl011.c b/xen/arch/arm/vpl011.c
> index 56d9cbe..1e72fca 100644
> --- a/xen/arch/arm/vpl011.c
> +++ b/xen/arch/arm/vpl011.c
> @@ -152,12 +152,20 @@ static void vpl011_write_data(struct domain *d, uint8_t 
> data)
>  else
>  gprintk(XENLOG_ERR, "vpl011: Unexpected OUT ring buffer full\n");
>  
> -if ( xencons_queued(out_prod, out_cons, sizeof(intf->out)) ==
> - sizeof (intf->out) )
> -{
> -vpl011->uartfr |= TXFF;
> +/*
> + * Ensure that there is space for atleast 16 bytes before asserting the
> + * TXI interrupt status bit because the SBSA UART driver may write
> + * 16 bytes (i.e. half the SBSA UART fifo size of 32) on getting
> + * a TX interrupt.
> + */
> +if ( xencons_queued(out_prod, out_cons, sizeof(intf->out)) <=
> + (sizeof (intf->out) - 16) )
> +vpl011->uartris |= TXI;
> +else if ( xencons_queued(out_prod, out_cons, sizeof(intf->out)) !=
> +  sizeof (intf->out) )

Now this is really hard to read. Can't you use:

fifo_level = xencons_queued(out_prod, out_cons, sizeof(intf->out));

Also I think you could start the patch a few lines above, where you
check for any free space in the buffer.

>  vpl011->uartris &= ~TXI;
> -}
> +else
> +vpl011->uartfr |= TXFF;

And I believe we should separate the FIFO full condition from the
interrupt condition. I think it should more look like:

vpl011->uartfr |= BUSY;
vpl011->uartfr &= ~TXFE;

if ( fifo_level == sizeof(intf->out) )
vpl011->uartfr |= TXFF;

if ( fifo_level >= sizeof(intf->out) - 16 )
vpl011->uartris &= ~TXI;

Which is much easier to read and understand, also follows the spec
closely. The "16" should be either expressed at FIFOSIZE / 2 or
explained in a comment.

>  
>  vpl011->uartfr |= BUSY;
>  
> @@ -368,7 +376,16 @@ static void vpl011_data_avail(struct domain *d)
>  if ( out_ring_qsize != sizeof(intf->out) )
>  {
>  vpl011->uartfr &= ~TXFF;
> -vpl011->uartris |= TXI;
> +
> +/*
> + * Ensure that there is space for atleast 16 bytes before asserting 
> the
> + * TXI interrupt status bit because the SBSA UART driver may write 
> upto
> + * 16 bytes (i.e. half the SBSA UART fifo size of 32) on getting
> + * a TX interrupt.

The comment sounds a bit like this is hack, where it actually is a
totally legit spec requirement (the interrupt is asserted/deasserted
around the *trigger level*, which is half way by default and always half
for the SBSA).

Also I think the same logic/fix needs to be applied to the receiving side.

And while I see that Julien requested a follow-up patch, I believe this
should eventually be squashed into 02/27, to not have wrong code in the
repo. But can could be done at commit time, I guess.

Cheers,
Andre.

> + */

Re: [Xen-devel] [PATCH v4 6/8] xen: add new domctl hypercall to set grant table resource limits

[Daniel De Graaf]

On 09/07/2017 09:47 AM, Juergen Gross wrote:

Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 


I just realized that this only allows dom0 to set dom0's limit. You
also need to add set_gnttab_limits to the permissions allowed by
create_domain_common in xen.if for this to be useful.

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

Re: [Xen-devel] [PATCH v4 8/8] libxl: add libxl support for setting grant table resource limits

[Wei Liu]

On Thu, Sep 07, 2017 at 03:47:35PM +0200, Juergen Gross wrote:
> Add new domain config items for setting the limits for the maximum
> numbers of grant table frames and maptrack frames of a domain.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Paul Durrant 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 6/8] xen: add new domctl hypercall to set grant table resource limits

[Daniel De Graaf]

On 09/07/2017 09:47 AM, Juergen Gross wrote:

Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 


Acked-by: Daniel De Graaf 


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

Re: [Xen-devel] [PATCH v10 2/3] x86emul: New return code for unimplemented instruction

[Jan Beulich]

>>> On 06.09.17 at 15:48,  wrote:
> Enforce the distinction between an instruction not implemented by the
> emulator and the failure to emulate that instruction by defining a new
> return code, X86EMUL_UNIMPLEMENTED.
> 
> This value should only be returned by the core emulator only if it fails to
> properly decode the current instruction's opcode, and not by any of other
> functions, such as the x86_emulate_ops or the hvm_io_ops callbacks.
> 
> e.g. hvm_process_io_incercept should not return X86EMUL_UNIMPLEMENTED.
> The return value of this function depends on either the return code of
> one of the hvm_io_ops handlers (read/write) or the value returned by
> hvm_copy_guest_from_phys / hvm_copy_to_guest_phys.
> 
> Similary, none of this functions should not return X86EMUL_UNIMPLEMENTED.
>  - hvmemul_do_io
>  - hvm_send_buffered_ioreq
>  - hvm_send_ioreq
>  - hvm_broadcast_ioreq
>  - hvmemul_do_io_buffer
>  - hvmemul_validate

Granted hvm_io_intercept() is only a relatively thin wrapper
around hvm_process_io_incercept(), but for completeness it
would have been nice to be included here too. Additionally it
would have helped reviewing as well as future development if you
had added ASSERT()s to this effect to all consumers where you
don't add a check for X86EMUL_UNIMPLEMENTED.

> Signed-off-by: Petre Pircalabu 
> Reviewed-by: Paul Durrant 

The code in v10 changed from v9 or whichever earlier version
Paul had give his R-b on. You should have removed it for that
reason or, if he had given it for a limited range of the patch
which did not change, you should have indicated which range
that was.

Also somewhere here I'm missing a summary of the changes
from v9. Putting it in the overview mail is nice, but for
reviewing purposes it is far more useful to be right in the
affected patch.

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c

After discussing with Andrew I'm willing to agree with the changes
you do here, with one extra requirement: At least on non-debug
builds X86EMUL_UNIMPLEMENTED should always result in #UD being
raised by the final consumer of it. It should never, like would be
the case with the changes you do to vmx/realmode.c, result in
the domain being crashed. Please change that one and check
carefully whether there are any other similar cases.

Jan


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

Re: [Xen-devel] [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Wei Liu]

On Thu, Sep 07, 2017 at 01:29:12PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 07 September 2017 13:16
> > To: Paul Durrant 
> > Cc: Wei Liu ; xen-de...@lists.xenproject.org; Ian
> > Jackson ; Andrew Cooper
> > ; George Dunlap
> > ; Jan Beulich ; Konrad
> > Rzeszutek Wilk ; Stefano Stabellini
> > ; Tim (Xen.org) 
> > Subject: Re: [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they
> > are actually requsted
> > 
> > On Thu, Sep 07, 2017 at 01:03:46PM +0100, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > > Sent: 07 September 2017 13:00
> > > > To: Paul Durrant 
> > > > Cc: xen-de...@lists.xenproject.org; Ian Jackson
> > ;
> > > > Wei Liu ; Andrew Cooper
> > > > ; George Dunlap
> > > > ; Jan Beulich ; Konrad
> > > > Rzeszutek Wilk ; Stefano Stabellini
> > > > ; Tim (Xen.org) 
> > > > Subject: Re: [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until
> > they
> > > > are actually requsted
> > > >
> > > > On Tue, Sep 05, 2017 at 12:37:15PM +0100, Paul Durrant wrote:
> > > > > A subsequent patch will introduce a new scheme to allow an emulator
> > to
> > > > > map ioreq server pages directly from Xen rather than the guest P2M.
> > > > >
> > > > > This patch lays the groundwork for that change by deferring mapping of
> > > > > gfns until their values are requested by an emulator. To that end, the
> > > > > pad field of the xen_dm_op_get_ioreq_server_info structure is re-
> > > > purposed
> > > > > to a flags field and new flag, XEN_DMOP_no_gfns, defined which
> > modifies
> > > > the
> > > > > behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to
> > > > avoid
> > > > > requesting the gfn values.
> > > > >
> > > > > Signed-off-by: Paul Durrant 
> > > > > Reviewed-by: Roger Pau Monné 
> > > > > ---
> > > > > Cc: Ian Jackson 
> > > > > Cc: Wei Liu 
> > > > > Cc: Andrew Cooper 
> > > > > Cc: George Dunlap 
> > > > > Cc: Jan Beulich 
> > > > > Cc: Konrad Rzeszutek Wilk 
> > > > > Cc: Stefano Stabellini 
> > > > > Cc: Tim Deegan 
> > > > >
> > > > > v3:
> > > > >  - Updated in response to review comments from Wei and Roger.
> > > > >  - Added a HANDLE_BUFIOREQ macro to make the code neater.
> > > > >  - This patch no longer introduces a security vulnerability since 
> > > > > there
> > > > >is now an explicit limit on the number of ioreq servers that may be
> > > > >created for any one domain.
> > > > > ---
> > > > >  tools/libs/devicemodel/core.c   |  8 +
> > > > >  tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
> > > > >  xen/arch/x86/hvm/dm.c   |  9 --
> > > > >  xen/arch/x86/hvm/ioreq.c| 41 
> > > > > +
> > > > >  xen/include/asm-x86/hvm/domain.h|  2 +-
> > > > >  xen/include/public/hvm/dm_op.h  | 32 
> > > > > +++
> > > > >  6 files changed, 59 insertions(+), 39 deletions(-)
> > > > >
> > > > > diff --git a/tools/libs/devicemodel/core.c
> > b/tools/libs/devicemodel/core.c
> > > > > index fcb260d29b..28958934bf 100644
> > > > > --- a/tools/libs/devicemodel/core.c
> > > > > +++ b/tools/libs/devicemodel/core.c
> > > > > @@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
> > > > >
> > > > >  data->id = id;
> > > > >
> > > > > +/*
> > > > > + * If the caller is not requesting gfn values then instruct the
> > > > > + * hypercall not to retrieve them as this may cause them to be
> > > > > + * mapped.
> > > > > + */
> > > > > +if (!ioreq_gfn && !bufioreq_gfn)
> > > > > +data->flags |= XEN_DMOP_no_gfns;
> > > > > +
> > > >
> > > > Sorry for not having noticed this earlier.
> > > >
> > > > This is a slight change to a stable API. The new functionality is an
> > > > extension of the old. I would suggest you bump the minor number of this
> > > > library as well.
> > > >
> > >
> > > I don't believe there is an API change here. The code always coped with
> > NULL being passed, it just wasn't documented. Or is there something else I'm
> > missing?
> > >
> > 
> > There is.  The original code copes with NULL as in "I doesn't care,
> > hypervisor will deal with it"; the new code actually gives NULL another
> > meaning.
> > 
> > Suppose 

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

[Roger Pau Monné]

On Thu, Sep 07, 2017 at 11:49:00AM +0100, George Dunlap wrote:
> On 08/31/2017 12:25 PM, Roger Pau Monne wrote:
> > On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
> >> +### x86/PV-on-HVM
> > 
> > Do we really consider this a guest type? From both Xen and the
> > toolstack PoV this is just a HVM guest. What's more, I'm not really
> > sure xl/libxl has the right options to create a HVM guest _without_
> > exposing any PV interfaces.
> > 
> > Ie: can a HMV guest without PV timers and PV event channels
> > actually be created? Or even without having the MSR to initialize the
> > hypercall page.
> 
> This document has its sources in the "feature support" page.  "PVHVM" is
> a collective term that was used at the time for exposing a number of
> individual interfaces to the guest; I think a lot of that work happened
> around the 4.2-4.3 timeframe.  And *one* of the goals, if I understand
> correctly, is to allow the automatic generation of such a table from the
> Xen sources.
> 
> It may be that we don't need to mention this as a separate feature
> anymore; or it may be that we can categorize this differently somehow --
> I'm open to suggestions here.

We marketed this as PVHVM, but I think this term applies to OSes
rather than Xen guest types.

From a Xen PoV, they are just HVM OSes.  Some of them make use of more
PV interfaces than others, but all HVM guests have the same set of
interfaces available to them, and thus the same surface of attack.

I don't think it makes sense to list PVHVM as a guest type in the list
of supported features.

> >> +### x86/PVH dom0
> >   ^ v2
> >> +
> >> +Status: Experimental
> > 
> > The status of this is just "not finished". We need at least the PCI
> > emulation series for having a half-functional PVHv2 Dom0.
> 
> From the definition of 'Experimental':
> 
> Functional completeness: No
> Functional stability: Here be dragons
> Interface stability: Not stable
> Security supported: No
> 
> "Not finished" -> Functional completeness: No -> Experimental.
> 
> If there's no way of doing anything with dom0 at all we should probably
> just remove it from the list.

Right now it should be removed according to the logic above.

> >> +### ACPI guest
> >> +
> >> +Status, ARM: Preview
> >Status: Supported
> > 
> > HVM guests have been using ACPI for a long time on x86.
> 
> You mean 'Status, x86 HVM: Supported', I take it?

Right.

> >> +### Online resize of virtual disks
> >> +
> >> +Status: Supported
> > 
> > That pretty much depends on where you are actually storing your disks
> > I guess. I'm not sure we want to make such compromises.
> 
> What do you mean?

I'm not sure online resizing is something that needs spelling out
separately, it's part of how the block protocol works, just like
indirect descriptors or persistent grants (which are also not listed
here, and I think that's fine).

> >> +### x86/HVM iPXE
> >> +
> >> +Status: Supported, with caveats
> >> +
> >> +Booting a guest via PXE.
> >> +PXE inherently places full trust of the guest in the network,
> >> +and so should only be used
> >> +when the guest network is under the same administrative control
> >> +as the guest itself.
> > 
> > Hm, not sure why this needs to be spelled out, it's just like running
> > any bootloader/firmware inside a HVM guest, which I'm quite sure we
> > are not going to list here.
> > 
> > Ie: I don't see us listing OVMF, SeaBIOS or ROMBIOS, simply because
> > they run inside the guest, so if they are able to cause security
> > issues, anything else is also capable of causing them.
> 
> Well iPXE is a feature, so we have to say something about it; and there
> was a long discussion at the Summit about whether we should list iPXE as
> "security supported", because *by design* it just runs random code that
> someone sends it over the network.  But if we say it's not supported, it
> makes it sound like we think you shouldn't use it.
> 
> Above was the agreed-upon compromise: to say it was supported but warn
> people what "supported" means.

Hm, I'm still not sure this should be explicitly listed here.

Running random code inside of a guest is not a problem from Xen's PoV,
and we would never issue a XSA, unless such code is able to break
outside of the guest, in which case it doesn't matter whether the code
has been randomly fetched from the network.

IMHO iPXE is just like any other firmware that Xen supports, such as
OVMF/SeaBIOS/ROMBIOS, and I don't see them listed here. I'm not sure
in which way iPXE is special from the other ones that requires such an
entry in the support document.

> >> +### ARM/SMMU
> >> +
> >> +Status: Supported, with caveats
> >> +
> >> +Only ARM SMMU hardware is supported; non-ARM SMMU hardware is not 
> >> supported.
> > 
> > I'm not sure of the purpose of this sentence, it's quite clear that
> > the SMMU is only supported if available. Also, I'm not sure this
> > should be spelled out in this document, x86 

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

On 07/09/2017, 14:24, "Andrew Cooper"  wrote:
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:

Have you encountered the netbsd rumpkernel project?  I don't it
referenced in your text (apologies if I've missed it).


http://events.linuxfoundation.org/sites/events/files/slides/xdps15-talk-final_0.pdf
is a presentation on from a previous Xen Developer Summit, and

One particular need build solution there was to not alter the build
system of the individual apps, and pass in the rest of the microkernel
as a cross-compile environment.  It's not entirely clear how you plan to
do this part of the building, but anything which involves modifying the
end applications is going to cause a non-trivial maintenance burden.

I don’t think we have to answer design questions up-front. Although it may make 
sense, to track some key open design and architectural decisions in a section 
at the end of the document, such that they are not forgotten.

> [Attachment: unicore-oneslider.pdf]
>
>
> Figure 1. Unicore architecture.
>
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux;

On the x86 Xen side of things, you should treat PV and HVM guests as
different platforms, and their tradeoffs are quite different.

The one semi-supported microkernel in the Xen world is stub-qemu, and in
principle this does give better isolation than qemu running in dom0, but
it also exposes other attack surfaces.  If you assume an HVM guest has
compromised its stub-qemu, it means that security issues exposed only to
PV guests are within the reach of an HVM guest.  In this circumstance,
having an HVM stub qemu would give the system a reduced attack surface
compared to a PV stub qemu.

I think this question could also be treated like an open design/architecture 
decision which should be recorded.

Lars

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

[Xen-devel] [xen-unstable-smoke test] 113126: trouble: broken/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-arm64-arm64-xl-xsm  broken
 build-arm64-pvopsbroken

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 113039
 build-arm64-pvops 3 capture-logsbroken like 113039
 build-arm64   2 hosts-allocate  broken like 113039
 build-arm64   3 capture-logsbroken like 113039
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  65c256266477e72f455a45a54597d5816646c74f
baseline version:
 xen  6dfb43d6f2cd8ea6274d203ca00ecfc7c565f11a

Last test of basis   113039  2017-09-04 15:02:08 Z2 days
Failing since113052  2017-09-05 13:01:29 Z2 days   22 attempts
Testing same since   113097  2017-09-06 17:02:46 Z0 days   10 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Andrew Cooper 
  Jan Beulich 
  Olaf Hering 
  Tamas K Lengyel 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



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

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

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

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

broken-job build-arm64 broken
broken-job test-arm64-arm64-xl-xsm broken
broken-job build-arm64-pvops broken
broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.


commit 65c256266477e72f455a45a54597d5816646c74f
Author: Yi Sun 
Date:   Mon Sep 4 19:01:44 2017 +0800

tools: change the type of '*nr' in 'libxl_psr_cat_get_info'

Due to historical reason, type of parameter '*nr' in 
'libxl_psr_cat_get_info'
is 'int'. But this is not right. It should be 'unsigned int'. This patch 
fixes
this and does related changes.

Suggested-by: Roger Pau Monné 
Signed-off-by: Yi Sun 
Acked-by: Wei Liu 

commit 5fe3e6a74afa21dd4f4abc18b47ed0f2e1550329
Author: Yi Sun 
Date:   Mon Sep 4 19:01:43 2017 +0800

tools: use '__i386__' and '__x86_64__' to replace PSR macros

The libxl interfaces and related functions are not necessary to be included 
by
'LIBXL_HAVE_PSR_CMT' and 'LIBXL_HAVE_PSR_CAT'. So replace them to common x86
macros. Furthermore, only compile 'xl_psr.c' under x86.

Suggested-by: Roger Pau Monné 
Suggested-by: Wei Liu 
Signed-off-by: Yi Sun 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 

commit 0829a6bdbdc6b79990bd0668e847275b6a2717e5
Author: Jan Beulich 
Date:   Wed Sep 6 12:32:00 2017 +0200

x86: introduce and use setup_force_cpu_cap()

For XEN_SMEP and XEN_SMAP to not be cleared while bringing up APs we'd
need to clone the respective hack used for CPUID_FAULTING. Introduce an
inverse 

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

[George Dunlap]

On 09/01/2017 04:00 PM, Wei Liu wrote:
> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
>> +### Direct-boot kernel image format
>> +
>> +Supported, x86: bzImage
> 
> Do you mean booting a PV guest? If so there are a few more formats.
> 
>> +Supported, ARM32: zImage
>> +Supported, ARM64: Image [XXX - Not sure if this is correct]
>> +
>> +Format which the toolstack accept for direct-boot kernels
> [...]
>> +### JSON support for xl
>> +
>> +Status: Preview
>> +
> 
> What is this?

JSON output; e.g., `xl list -l`.

Perhaps this should be called 'JSON output support'. :-)

>> +### AHCI support for xl
>> +
>> +Status, x86: Supported
>> +
> 
> There is only one knob to change, I'm not sure whether makes sense to
> list it separately.
> 
>> +### Soft-reset for xl
>> +
>> +Status: Supported
>> +
> 
> We never tested this in osstest so I'm not sure about if this is the
> correct status. Furthermore there is also moving parts in hypervisor.

Hmm, maybe this would go better under a hypervisor section somewhere; as
you say, the core functionality doesn't reside in xl, xl just enables it.

Strangely enough, we don't have a simple 'hypervisor' section.

>> +### Online resize of virtual disks
>> +
>> +Status: Supported
> 
> What is this? Is this part of the PV block protocol?

I think so, yes.

 -George

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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Lars Kurth]

Hi all,

there is a technical issue which still needs resolving: we need a Sponsor. I am 
thinking of Wei – he would qualify as a Hypervisor Leadership team member and 
it would have the benefit of making sure that the MiniOS angle is covered. I 
asked Wei, and he will get back to us once he read the proposal.

I also want to highlight this proposal at the next AB board meeting, Sept 19th. 
It would be good, if most feedback could be given in the next week, such that 
a) we have time to make mods, b) I have a good baseline to share with the AB. I 
would need to share an updated proposal on the 18th at the latest.

Technically, the subproject does not need AB approval, as there is no financial 
impact, but it is always good to have it. 

Regards
Lars

On 07/09/2017, 11:26, "Felipe Huici"  wrote:

Dear all,

Following up on discussions that Simon Kuenzer had with several of you at
the last Xen summit, we’re now submitting a Xen subproject proposal based
on our Unicore work. Could you please review it?

Thanks,

Felipe Huici & Simon Kuenzer - NEC Labs Heidelberg.


PROPOSAL: Unicore
=

Roles
-
Project Leads: Simon Kuenzer  (main lead)
   Felipe Huici  (co-lead)
   Florian Schmidt  (co-lead)
Project Mentor:  Lars Kurth 
Project Sponsor: -To be found-

Background
--
In recent years, several papers and projects dedicated to unikernels have
shown the immense potential for performance gains that these have. By
leveraging specialization and the use of minimalistic OSes, unikernels are
able to yield impressive numbers, including fast instantiation times (tens
of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
high network throughput (10-40 Gb/s), and high consolidation (e.g., being
able to run thousands of instances on a single commodity server), not to
mention a reduced attack surface and the potential for easier
certification. Unikernel projects worthy of mention include MirageOS,
ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.

The fundamental drawback of unikernels is that they require that
applications be manually ported to the underlying minimalistic OS (e.g.
having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
requires both expert work and often considerable amount of time. In
essence, we need to pick between either high performance with unikernels,
or no porting effort but decreased performance and decreased efficiency
with standard OS/VM images. The goal of this proposal is to change this
status quo by providing a highly configurable unikernel code base; we call
this base Unicore.

This project also aims to concentrate the various efforts currently going
on in the Xen community regarding minimalistic OSes (essentially different
variants of MiniOS). We think that splitting the community across these
variants is counter-productive and hope that Unicore will provide a common
place for all or most improvements and customizations of minimalistic
OSes. The long term goal is to replace something like MiniOS with a tool
that can automatically build such a minimalistic OS.

Unicore - The "Unikernel Core"
-
The high level goal of Unicore is to be able to build unikernels targeted
at specific applications without requiring the time-consuming, expert work
that building such a unikernel requires today. An additional goal (or
hope) of Unicore is that all developers interested in unikernel
development would contribute by supplying libraries rather than working on
independent projects with different code bases as it is done now. The main
idea behind Unicore is depicted in Figure 1 and consists of two basic
components:
 

[Attachment: unicore-oneslider.pdf]


Figure 1. Unicore architecture.

 
Library pools would contain libraries that the user of Unicore can select
from to create the unikernel. From the bottom up, library pools are
organized into (1) the architecture library tool, containing libraries
specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
virtualization) and user-space Linux; and (3) the main library pool,
containing a rich set of functionality to build the unikernel from. This
last library includes drivers (both virtual such as netback/netfront and
physical such as ixgbe), filesystems, memory allocators, schedulers,
network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
Python interpreter and debugging 

[Xen-devel] [PATCH v4 4/8] xen: make grant resource limits per domain

[Juergen Gross]

Instead of using the same global resource limits of grant tables (max.
number of grant frames, max. number of maptrack frames) for all domains
make these limits per domain. This will allow setting individual limits
in the future. For now initialize the per domain limits with the global
values.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
---
V3:
- correct error message (Paul Durrant)
---
 xen/common/grant_table.c | 82 ++--
 1 file changed, 45 insertions(+), 37 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 29e7fa539b..ff735a4b47 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -71,6 +71,9 @@ struct grant_table {
  * what version to use yet.
  */
 unsigned  gt_version;
+/* Resource limits of the domain. */
+unsigned int  max_grant_frames;
+unsigned int  max_maptrack_frames;
 };
 
 #ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
@@ -287,8 +290,8 @@ num_act_frames_from_sha_frames(const unsigned int num)
 return DIV_ROUND_UP(num * sha_per_page, ACGNT_PER_PAGE);
 }
 
-#define max_nr_active_grant_frames \
-num_act_frames_from_sha_frames(max_grant_frames)
+#define max_nr_active_grant_frames(gt) \
+num_act_frames_from_sha_frames(gt->max_grant_frames)
 
 static inline unsigned int
 nr_active_grant_frames(struct grant_table *gt)
@@ -526,7 +529,7 @@ get_maptrack_handle(
  * out of memory, try stealing an entry from another VCPU (in case the
  * guest isn't mapping across its VCPUs evenly).
  */
-if ( nr_maptrack_frames(lgt) < max_maptrack_frames )
+if ( nr_maptrack_frames(lgt) < lgt->max_maptrack_frames )
 new_mt = alloc_xenheap_page();
 
 if ( !new_mt )
@@ -1664,14 +1667,15 @@ grant_table_init(struct domain *d)
 if ( gt->nr_grant_frames )
 return 0;
 
-gt->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
+gt->nr_grant_frames = min_t(unsigned int, INITIAL_NR_GRANT_FRAMES,
+  gt->max_grant_frames);
 
 /* Active grant table. */
 if ( (gt->active = xzalloc_array(struct active_grant_entry *,
- max_nr_active_grant_frames)) == NULL )
+ max_nr_active_grant_frames(gt))) == NULL )
 goto no_mem_1;
 for ( i = 0;
-  i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+  i < num_act_frames_from_sha_frames(gt->nr_grant_frames); i++ )
 {
 if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
 goto no_mem_2;
@@ -1681,14 +1685,14 @@ grant_table_init(struct domain *d)
 }
 
 /* Tracking of mapped foreign frames table */
-gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
+gt->maptrack = vzalloc(gt->max_maptrack_frames * sizeof(*gt->maptrack));
 if ( gt->maptrack == NULL )
 goto no_mem_2;
 
 /* Shared grant table. */
-if ( (gt->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL )
+if ( (gt->shared_raw = xzalloc_array(void *, gt->max_grant_frames)) == 
NULL )
 goto no_mem_3;
-for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+for ( i = 0; i < gt->nr_grant_frames; i++ )
 {
 if ( (gt->shared_raw[i] = alloc_xenheap_page()) == NULL )
 goto no_mem_4;
@@ -1697,11 +1701,11 @@ grant_table_init(struct domain *d)
 
 /* Status pages for grant table - for version 2 */
 gt->status = xzalloc_array(grant_status_t *,
-   grant_to_status_frames(max_grant_frames));
+   grant_to_status_frames(gt->max_grant_frames));
 if ( gt->status == NULL )
 goto no_mem_4;
 
-for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+for ( i = 0; i < gt->nr_grant_frames; i++ )
 gnttab_create_shared_page(d, gt, i);
 
 gt->nr_status_frames = 0;
@@ -1709,7 +1713,7 @@ grant_table_init(struct domain *d)
 return 0;
 
  no_mem_4:
-for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+for ( i = 0; i < gt->nr_grant_frames; i++ )
 free_xenheap_page(gt->shared_raw[i]);
 xfree(gt->shared_raw);
 gt->shared_raw = NULL;
@@ -1718,7 +1722,7 @@ grant_table_init(struct domain *d)
 gt->maptrack = NULL;
  no_mem_2:
 for ( i = 0;
-  i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+  i < num_act_frames_from_sha_frames(gt->nr_grant_frames); i++ )
 free_xenheap_page(gt->active[i]);
 xfree(gt->active);
 gt->active = NULL;
@@ -1743,7 +1747,7 @@ gnttab_grow_table(struct domain *d, unsigned int 
req_nr_frames)
 return 0;
 }
 
-ASSERT(req_nr_frames <= max_grant_frames);
+ASSERT(req_nr_frames <= gt->max_grant_frames);
 
 gdprintk(XENLOG_INFO,
 "Expanding dom (%d) grant table from 

[Xen-devel] [PATCH v4 8/8] libxl: add libxl support for setting grant table resource limits

[Juergen Gross]

Add new domain config items for setting the limits for the maximum
numbers of grant table frames and maptrack frames of a domain.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
---
V4:
- rename configuration items to use max_ prefixes (Wei Liu)
---
 docs/man/xl.cfg.pod.5.in| 15 +++
 tools/libxl/libxl.h |  6 ++
 tools/libxl/libxl_dom.c |  8 
 tools/libxl/libxl_types.idl |  3 +++
 tools/xl/xl_parse.c |  5 +
 tools/xl/xl_sxp.c   |  2 ++
 6 files changed, 39 insertions(+)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 79cb2eaea7..caa674d59d 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -444,6 +444,21 @@ unpausing the domain. With a properly constructed security 
policy (such
 as nomigrate_t in the example policy), this can be used to build a
 domain whose memory is not accessible to the toolstack domain.
 
+=item 

[Xen-devel] [PATCH v4 0/8] xen: better grant v2 support

[Juergen Gross]

Currently Linux has no support for grant v2 as this would reduce the
maximum number of active grants by a factor of 2 compared to v1,
because the number of possible grants are limited by the allowed number
of grant frames and grant entries of v2 need twice as much bytes as
those of v1.

Unfortunately grant v2 is the only way to support either guests with
more than 16TB memory size or PV guests with memory above the 16TB
border, as grant v1 limits the frame number to be 32 bits wide.

In order to remove the disadvantage of grant v2 this patch series
adds support for setting per-domain values regarding grant limits.
Additionally the default limit of grant frames is doubled in case
of hosts with memory above the 16TB border.

Changes in V4:
- patch 3: make ret more local (Wei Liu)
- patch 7: use domid_t (Wei Liu)
- patch 8: rename configuration items to use max_ prefixes (Wei Liu)

Changes in V3:
- patch 1: update commit message
- patch 3: move call of grant_table_init() from gnttab_setup_table() to
  gnttab_grow_table() (Paul Durrant)
- patch 4: correct error message (Paul Durrant)
- patch 6: rename *gnttbl* to *gnttab* (Paul Durrant)

Changes in V2:
- add per-domain grant limits instead of different v1 and v2 limits
- double default limit for huge hosts

Juergen Gross (8):
  xen: move XENMAPSPACE_grant_table code into grant_table.c
  xen: clean up grant_table.h
  xen: delay allocation of grant table sub structures
  xen: make grant resource limits per domain
  xen: double default grant frame limit for huge hosts
  xen: add new domctl hypercall to set grant table resource limits
  libxc: add libxc support for setting grant table resource limits
  libxl: add libxl support for setting grant table resource limits

 docs/man/xl.cfg.pod.5.in|  15 ++
 tools/flask/policy/modules/dom0.te  |   2 +-
 tools/libxc/include/xenctrl.h   |  14 ++
 tools/libxc/xc_domain.c |  13 ++
 tools/libxl/libxl.h |   6 +
 tools/libxl/libxl_dom.c |   8 +
 tools/libxl/libxl_types.idl |   3 +
 tools/xl/xl_parse.c |   5 +
 tools/xl/xl_sxp.c   |   2 +
 xen/arch/arm/mm.c   |  36 +---
 xen/arch/x86/mm.c   |  41 +
 xen/common/domain.c |  17 +-
 xen/common/domctl.c |   6 +
 xen/common/grant_table.c| 354 +++-
 xen/include/asm-arm/grant_table.h   |   7 +
 xen/include/asm-x86/grant_table.h   |   5 +
 xen/include/public/domctl.h |   9 +
 xen/include/xen/grant_table.h   |  91 +
 xen/xsm/flask/hooks.c   |   3 +
 xen/xsm/flask/policy/access_vectors |   2 +
 20 files changed, 401 insertions(+), 238 deletions(-)

-- 
2.12.3


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

[Xen-devel] [PATCH v4 2/8] xen: clean up grant_table.h

[Juergen Gross]

Many definitions can be moved from xen/grant_table.h to
common/grant_table.c now, as they are no longer used in other sources.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
---
 xen/common/grant_table.c  | 83 --
 xen/include/xen/grant_table.h | 84 ---
 2 files changed, 81 insertions(+), 86 deletions(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 4c2e9e40a5..4520e36d90 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -40,6 +40,44 @@
 #include 
 #include 
 
+/* Per-domain grant information. */
+struct grant_table {
+/*
+ * Lock protecting updates to grant table state (version, active
+ * entry list, etc.)
+ */
+percpu_rwlock_t   lock;
+/* Table size. Number of frames shared with guest */
+unsigned int  nr_grant_frames;
+/* Shared grant table (see include/public/grant_table.h). */
+union {
+void **shared_raw;
+struct grant_entry_v1 **shared_v1;
+union grant_entry_v2 **shared_v2;
+};
+/* Number of grant status frames shared with guest (for version 2) */
+unsigned int  nr_status_frames;
+/* State grant table (see include/public/grant_table.h). */
+grant_status_t   **status;
+/* Active grant table. */
+struct active_grant_entry **active;
+/* Mapping tracking table per vcpu. */
+struct grant_mapping **maptrack;
+unsigned int  maptrack_limit;
+/* Lock protecting the maptrack limit */
+spinlock_tmaptrack_lock;
+/*
+ * The defined versions are 1 and 2.  Set to 0 if we don't know
+ * what version to use yet.
+ */
+unsigned  gt_version;
+};
+
+#ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
+/* Default maximum size of a grant table. [POLICY] */
+#define DEFAULT_MAX_NR_GRANT_FRAMES   32
+#endif
+
 unsigned int __read_mostly max_grant_frames;
 integer_param("gnttab_max_frames", max_grant_frames);
 
@@ -118,6 +156,18 @@ struct grant_mapping {
 uint32_t pad;   /* round size to a power of 2 */
 };
 
+/* Number of grant table frames. Caller must hold d's grant table lock. */
+static inline unsigned int nr_grant_frames(const struct grant_table *gt)
+{
+return gt->nr_grant_frames;
+}
+
+/* Number of status grant table frames. Caller must hold d's gr. table lock.*/
+static inline unsigned int nr_status_frames(const struct grant_table *gt)
+{
+return gt->nr_status_frames;
+}
+
 #define MAPTRACK_PER_PAGE (PAGE_SIZE / sizeof(struct grant_mapping))
 #define maptrack_entry(t, e) \
 ((t)->maptrack[(e)/MAPTRACK_PER_PAGE][(e)%MAPTRACK_PER_PAGE])
@@ -197,7 +247,27 @@ static inline void act_set_gfn(struct active_grant_entry 
*act, gfn_t gfn)
 #endif
 }
 
-DEFINE_PERCPU_RWLOCK_GLOBAL(grant_rwlock);
+static DEFINE_PERCPU_RWLOCK_GLOBAL(grant_rwlock);
+
+static inline void grant_read_lock(struct grant_table *gt)
+{
+percpu_read_lock(grant_rwlock, >lock);
+}
+
+static inline void grant_read_unlock(struct grant_table *gt)
+{
+percpu_read_unlock(grant_rwlock, >lock);
+}
+
+static inline void grant_write_lock(struct grant_table *gt)
+{
+percpu_write_lock(grant_rwlock, >lock);
+}
+
+static inline void grant_write_unlock(struct grant_table *gt)
+{
+percpu_write_unlock(grant_rwlock, >lock);
+}
 
 static inline void gnttab_flush_tlb(const struct domain *d)
 {
@@ -250,6 +320,15 @@ static inline void active_entry_release(struct 
active_grant_entry *act)
 spin_unlock(>lock);
 }
 
+#define GRANT_STATUS_PER_PAGE (PAGE_SIZE / sizeof(grant_status_t))
+#define GRANT_PER_PAGE (PAGE_SIZE / sizeof(grant_entry_v2_t))
+/* Number of grant table status entries. Caller must hold d's gr. table lock.*/
+static inline unsigned int grant_to_status_frames(unsigned int grant_frames)
+{
+return (grant_frames * GRANT_PER_PAGE + GRANT_STATUS_PER_PAGE - 1) /
+GRANT_STATUS_PER_PAGE;
+}
+
 /* Check if the page has been paged out, or needs unsharing.
If rc == GNTST_okay, *page contains the page struct with a ref taken.
Caller must do put_page(*page).
@@ -1580,7 +1659,7 @@ gnttab_unpopulate_status_frames(struct domain *d, struct 
grant_table *gt)
  * Grow the grant table. The caller must hold the grant table's
  * write lock before calling this function.
  */
-int
+static int
 gnttab_grow_table(struct domain *d, unsigned int req_nr_frames)
 {
 struct grant_table *gt = d->grant_table;
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 43ec6c4d80..43b07e60c5 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -29,66 +29,9 @@
 #include 
 #include 
 
-#ifndef DEFAULT_MAX_NR_GRANT_FRAMES /* to allow arch to override */
-/* Default maximum size of a grant table. [POLICY] */
-#define DEFAULT_MAX_NR_GRANT_FRAMES   32
-#endif
 /* 

[Xen-devel] [PATCH v4 1/8] xen: move XENMAPSPACE_grant_table code into grant_table.c

[Juergen Gross]

The x86 and arm versions of XENMAPSPACE_grant_table handling are nearly
identical. Move the code into a function in grant_table.c and add an
architecture dependant hook to handle the differences.

Switch to mfn_t in order to be more type safe.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
---
V3:
- update commit message

V2:
- rebased to staging
---
 xen/arch/arm/mm.c | 36 --
 xen/arch/x86/mm.c | 41 ++-
 xen/common/grant_table.c  | 38 
 xen/include/asm-arm/grant_table.h |  7 +++
 xen/include/asm-x86/grant_table.h |  5 +
 xen/include/xen/grant_table.h |  3 +++
 6 files changed, 67 insertions(+), 63 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index b39677eac9..3db0e3bdea 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1229,39 +1229,11 @@ int xenmem_add_to_physmap_one(
 switch ( space )
 {
 case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
-(idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-}
-
-if ( !mfn_eq(mfn, INVALID_MFN) )
-{
-d->arch.grant_table_gfn[idx] = gfn;
-
-t = p2m_ram_rw;
-}
-
-grant_write_unlock(d->grant_table);
+rc = gnttab_map_frame(d, idx, gfn, );
+if ( rc )
+return rc;
 
-if ( mfn_eq(mfn, INVALID_MFN) )
-return -EINVAL;
+t = p2m_ram_rw;
 
 break;
 case XENMAPSPACE_shared_info:
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index e5a029c9be..3d899e4a8e 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4631,40 +4631,19 @@ int xenmem_add_to_physmap_one(
 {
 struct page_info *page = NULL;
 unsigned long gfn = 0; /* gcc ... */
-unsigned long prev_mfn, mfn = 0, old_gpfn;
+unsigned long prev_mfn, old_gpfn;
 int rc = 0;
+mfn_t mfn = INVALID_MFN;
 p2m_type_t p2mt;
 
 switch ( space )
 {
 case XENMAPSPACE_shared_info:
 if ( idx == 0 )
-mfn = virt_to_mfn(d->shared_info);
+mfn = _mfn(virt_to_mfn(d->shared_info));
 break;
 case XENMAPSPACE_grant_table:
-grant_write_lock(d->grant_table);
-
-if ( d->grant_table->gt_version == 0 )
-d->grant_table->gt_version = 1;
-
-if ( d->grant_table->gt_version == 2 &&
- (idx & XENMAPIDX_grant_table_status) )
-{
-idx &= ~XENMAPIDX_grant_table_status;
-if ( idx < nr_status_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->status[idx]);
-}
-else
-{
-if ( (idx >= nr_grant_frames(d->grant_table)) &&
- (idx < max_grant_frames) )
-gnttab_grow_table(d, idx + 1);
-
-if ( idx < nr_grant_frames(d->grant_table) )
-mfn = virt_to_mfn(d->grant_table->shared_raw[idx]);
-}
-
-grant_write_unlock(d->grant_table);
+gnttab_map_frame(d, idx, gpfn, );
 break;
 case XENMAPSPACE_gmfn_range:
 case XENMAPSPACE_gmfn:
@@ -4681,8 +4660,8 @@ int xenmem_add_to_physmap_one(
 }
 if ( !get_page_from_mfn(_mfn(idx), d) )
 break;
-mfn = idx;
-page = mfn_to_page(_mfn(mfn));
+mfn = _mfn(idx);
+page = mfn_to_page(mfn);
 break;
 }
 case XENMAPSPACE_gmfn_foreign:
@@ -4691,7 +4670,7 @@ int xenmem_add_to_physmap_one(
 break;
 }
 
-if ( !paging_mode_translate(d) || (mfn == 0) )
+if ( !paging_mode_translate(d) || mfn_eq(mfn, INVALID_MFN) )
 {
 rc = -EINVAL;
 goto put_both;
@@ -4715,16 +4694,16 @@ int xenmem_add_to_physmap_one(
 goto put_both;
 
 /* Unmap from old location, if any. */
-old_gpfn = get_gpfn_from_mfn(mfn);
+old_gpfn = get_gpfn_from_mfn(mfn_x(mfn));
 ASSERT( old_gpfn != SHARED_M2P_ENTRY );
 if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
 ASSERT( old_gpfn 

[Xen-devel] [PATCH v4 3/8] xen: delay allocation of grant table sub structures

[Juergen Gross]

Delay the allocation of the grant table sub structures in order to
allow modifying parameters needed for sizing of these structures at a
per domain basis. Either do it from gnttab_setup_table() or just
before the domain is started the first time.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
---
V4:
- make ret more local (Wei Liu)

V3:
- move call of grant_table_init() from gnttab_setup_table() to
  gnttab_grow_table() (Paul Durrant)
---
 xen/common/domain.c   |  17 +-
 xen/common/grant_table.c  | 138 --
 xen/include/xen/grant_table.h |   2 +
 3 files changed, 96 insertions(+), 61 deletions(-)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 5aebcf265f..983f3336a9 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -363,6 +363,9 @@ struct domain *domain_create(domid_t domid, unsigned int 
domcr_flags,
 goto fail;
 init_status |= INIT_gnttab;
 
+if ( domid == 0 && grant_table_init(d) )
+goto fail;
+
 poolid = 0;
 
 err = -ENOMEM;
@@ -998,7 +1001,8 @@ int __domain_pause_by_systemcontroller(struct domain *d,
 prev = cmpxchg(>controller_pause_count, old, new);
 } while ( prev != old );
 
-pause_fn(d);
+if ( pause_fn )
+pause_fn(d);
 
 return 0;
 }
@@ -1029,8 +1033,17 @@ int domain_unpause_by_systemcontroller(struct domain *d)
  * Creation is considered finished when the controller reference count
  * first drops to 0.
  */
-if ( new == 0 )
+if ( new == 0 && !d->creation_finished )
+{
+int ret = grant_table_init(d);
+
+if ( ret )
+{
+__domain_pause_by_systemcontroller(d, NULL);
+return ret;
+}
 d->creation_finished = true;
+}
 
 domain_unpause(d);
 
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 4520e36d90..29e7fa539b 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1655,6 +1655,78 @@ gnttab_unpopulate_status_frames(struct domain *d, struct 
grant_table *gt)
 gt->nr_status_frames = 0;
 }
 
+int
+grant_table_init(struct domain *d)
+{
+struct grant_table *gt = d->grant_table;
+unsigned int i, j;
+
+if ( gt->nr_grant_frames )
+return 0;
+
+gt->nr_grant_frames = INITIAL_NR_GRANT_FRAMES;
+
+/* Active grant table. */
+if ( (gt->active = xzalloc_array(struct active_grant_entry *,
+ max_nr_active_grant_frames)) == NULL )
+goto no_mem_1;
+for ( i = 0;
+  i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+{
+if ( (gt->active[i] = alloc_xenheap_page()) == NULL )
+goto no_mem_2;
+clear_page(gt->active[i]);
+for ( j = 0; j < ACGNT_PER_PAGE; j++ )
+spin_lock_init(>active[i][j].lock);
+}
+
+/* Tracking of mapped foreign frames table */
+gt->maptrack = vzalloc(max_maptrack_frames * sizeof(*gt->maptrack));
+if ( gt->maptrack == NULL )
+goto no_mem_2;
+
+/* Shared grant table. */
+if ( (gt->shared_raw = xzalloc_array(void *, max_grant_frames)) == NULL )
+goto no_mem_3;
+for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+{
+if ( (gt->shared_raw[i] = alloc_xenheap_page()) == NULL )
+goto no_mem_4;
+clear_page(gt->shared_raw[i]);
+}
+
+/* Status pages for grant table - for version 2 */
+gt->status = xzalloc_array(grant_status_t *,
+   grant_to_status_frames(max_grant_frames));
+if ( gt->status == NULL )
+goto no_mem_4;
+
+for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+gnttab_create_shared_page(d, gt, i);
+
+gt->nr_status_frames = 0;
+
+return 0;
+
+ no_mem_4:
+for ( i = 0; i < INITIAL_NR_GRANT_FRAMES; i++ )
+free_xenheap_page(gt->shared_raw[i]);
+xfree(gt->shared_raw);
+gt->shared_raw = NULL;
+ no_mem_3:
+vfree(gt->maptrack);
+gt->maptrack = NULL;
+ no_mem_2:
+for ( i = 0;
+  i < num_act_frames_from_sha_frames(INITIAL_NR_GRANT_FRAMES); i++ )
+free_xenheap_page(gt->active[i]);
+xfree(gt->active);
+gt->active = NULL;
+ no_mem_1:
+gt->nr_grant_frames = 0;
+return -ENOMEM;
+}
+
 /*
  * Grow the grant table. The caller must hold the grant table's
  * write lock before calling this function.
@@ -1665,6 +1737,12 @@ gnttab_grow_table(struct domain *d, unsigned int 
req_nr_frames)
 struct grant_table *gt = d->grant_table;
 unsigned int i, j;
 
+if ( !gt->nr_grant_frames && grant_table_init(d) )
+{
+gdprintk(XENLOG_INFO, "Allocation failure in grant table init.\n");
+return 0;
+}
+
 ASSERT(req_nr_frames <= max_grant_frames);
 
 gdprintk(XENLOG_INFO,
@@ -3380,75 +3458,17 @@ grant_table_create(
 struct domain *d)
 {
 struct 

[Xen-devel] [PATCH v4 7/8] libxc: add libxc support for setting grant table resource limits

[Juergen Gross]

Add a new libxc function xc_domain_set_gnttbl_limits() setting the
limits for the maximum numbers of grant table frames and maptrack
frames of a domain.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Acked-by: Wei Liu 
---
V4:
- use domid_t (Wei Liu)
---
 tools/libxc/include/xenctrl.h | 14 ++
 tools/libxc/xc_domain.c   | 13 +
 2 files changed, 27 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 43151cb415..ab34fb4f70 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1064,6 +1064,20 @@ int xc_domain_set_virq_handler(xc_interface *xch, 
uint32_t domid, int virq);
 int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t domid,
  uint32_t max_port);
 
+/**
+ * Set the maximum number of grant frames and/or maptrack frames a domain
+ * can have. Can only be used at domain setup time. A zero value means
+ * no change.
+ *
+ * @param xch a handle to an open hypervisor interface
+ * @param domid the domain id
+ * @param grant_frames max. number of grant frames
+ * @param maptrack_frames max. number of maptrack frames
+ */
+int xc_domain_set_gnttab_limits(xc_interface *xch, domid_t domid,
+uint32_t grant_frames,
+uint32_t maptrack_frames);
+
 /*
  * CPUPOOL MANAGEMENT FUNCTIONS
  */
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 3bab4e8bab..41b42d6637 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2268,6 +2268,19 @@ int xc_domain_set_max_evtchn(xc_interface *xch, uint32_t 
domid,
 return do_domctl(xch, );
 }
 
+int xc_domain_set_gnttab_limits(xc_interface *xch, domid_t domid,
+uint32_t grant_frames,
+uint32_t maptrack_frames)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_set_gnttab_limits;
+domctl.domain = domid;
+domctl.u.set_gnttab_limits.grant_frames = grant_frames;
+domctl.u.set_gnttab_limits.maptrack_frames = maptrack_frames;
+return do_domctl(xch, );
+}
+
 /* Plumbing Xen with vNUMA topology */
 int xc_domain_setvnuma(xc_interface *xch,
uint32_t domid,
-- 
2.12.3


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

[Xen-devel] [PATCH v4 6/8] xen: add new domctl hypercall to set grant table resource limits

[Juergen Gross]

Add a domctl hypercall to set the domain's resource limits regarding
grant tables. It is accepted only as long as neither
gnttab_setup_table() has been called for the domain, nor the domain
has started to run.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
---
V3:
- rename *gnttbl* to *gnttab* (Paul Durrant)
---
 tools/flask/policy/modules/dom0.te  |  2 +-
 xen/common/domctl.c |  6 ++
 xen/common/grant_table.c| 26 ++
 xen/include/public/domctl.h |  9 +
 xen/include/xen/grant_table.h   |  2 ++
 xen/xsm/flask/hooks.c   |  3 +++
 xen/xsm/flask/policy/access_vectors |  2 ++
 7 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/tools/flask/policy/modules/dom0.te 
b/tools/flask/policy/modules/dom0.te
index 338caaf41e..1643b400f0 100644
--- a/tools/flask/policy/modules/dom0.te
+++ b/tools/flask/policy/modules/dom0.te
@@ -39,7 +39,7 @@ allow dom0_t dom0_t:domain {
 };
 allow dom0_t dom0_t:domain2 {
set_cpuid gettsc settsc setscheduler set_max_evtchn set_vnumainfo
-   get_vnumainfo psr_cmt_op psr_cat_op
+   get_vnumainfo psr_cmt_op psr_cat_op set_gnttab_limits
 };
 allow dom0_t dom0_t:resource { add remove };
 
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 42658e5744..58381f8fe9 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1149,6 +1150,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 copyback = 1;
 break;
 
+case XEN_DOMCTL_set_gnttab_limits:
+ret = grant_table_set_limits(d, op->u.set_gnttab_limits.grant_frames,
+ op->u.set_gnttab_limits.maptrack_frames);
+break;
+
 default:
 ret = arch_do_domctl(op, d, u_domctl);
 break;
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c00119f2fe..83f1a9dd34 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3667,6 +3667,32 @@ void grant_table_init_vcpu(struct vcpu *v)
 v->maptrack_tail = MAPTRACK_TAIL;
 }
 
+int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
+   unsigned int maptrack_frames)
+{
+struct grant_table *gt = d->grant_table;
+int ret = -EBUSY;
+
+if ( !gt )
+return -EEXIST;
+
+grant_write_lock(gt);
+
+if ( gt->nr_grant_frames )
+goto unlock;
+
+ret = 0;
+if ( grant_frames )
+gt->max_grant_frames = grant_frames;
+if ( maptrack_frames )
+gt->max_maptrack_frames = maptrack_frames;
+
+ unlock:
+grant_write_unlock(gt);
+
+return ret;
+}
+
 #ifdef CONFIG_HAS_MEM_SHARING
 int mem_sharing_gref_to_gfn(struct grant_table *gt, grant_ref_t ref,
 gfn_t *gfn, uint16_t *status)
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 50ff58f5b9..f7e3509c27 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1163,6 +1163,13 @@ struct xen_domctl_psr_cat_op {
 typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
 
+struct xen_domctl_set_gnttab_limits {
+uint32_t grant_frames; /* IN: if 0, dont change */
+uint32_t maptrack_frames;  /* IN: if 0, dont change */
+};
+typedef struct xen_domctl_set_gnttab_limits xen_domctl_set_gnttab_limits_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_set_gnttab_limits_t);
+
 struct xen_domctl {
 uint32_t cmd;
 #define XEN_DOMCTL_createdomain   1
@@ -1240,6 +1247,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_monitor_op77
 #define XEN_DOMCTL_psr_cat_op78
 #define XEN_DOMCTL_soft_reset79
+#define XEN_DOMCTL_set_gnttab_limits 80
 #define XEN_DOMCTL_gdbsx_guestmemio1000
 #define XEN_DOMCTL_gdbsx_pausevcpu 1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
@@ -1302,6 +1310,7 @@ struct xen_domctl {
 struct xen_domctl_psr_cmt_oppsr_cmt_op;
 struct xen_domctl_monitor_opmonitor_op;
 struct xen_domctl_psr_cat_oppsr_cat_op;
+struct xen_domctl_set_gnttab_limits set_gnttab_limits;
 uint8_t pad[128];
 } u;
 };
diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h
index 84a8d61616..dd9aa3b9ee 100644
--- a/xen/include/xen/grant_table.h
+++ b/xen/include/xen/grant_table.h
@@ -40,6 +40,8 @@ int grant_table_init(
 void grant_table_destroy(
 struct domain *d);
 void grant_table_init_vcpu(struct vcpu *v);
+int grant_table_set_limits(struct domain *d, unsigned int grant_frames,
+   unsigned int maptrack_frames);
 
 /*
  * Check if domain has active grants and log first 10 

[Xen-devel] [PATCH v4 5/8] xen: double default grant frame limit for huge hosts

[Juergen Gross]

In case a system has memory above the 16TB boundary double the default
grant frame number limit per domain. This ensures a pv domain can still
establish the same number of grants even if it is required to use
version 2 grants which need twice the space of v1 grants.

Signed-off-by: Juergen Gross 
Reviewed-by: Paul Durrant 
Reviewed-by: Wei Liu 
---
 xen/common/grant_table.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index ff735a4b47..c00119f2fe 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3824,8 +3824,15 @@ static int __init gnttab_usage_init(void)
 {
 BUILD_BUG_ON(DEFAULT_MAX_MAPTRACK_FRAMES < DEFAULT_MAX_NR_GRANT_FRAMES);
 
+/*
+ * In case grant v2 is required for pv domains to reference any possible
+ * memory page (i.e. memory is installed above 16TB boundary) double the
+ * grant frame limit. This will allow a guest using v2 grants without
+ * having to lower the number of usable grants.
+ */
 if ( !max_grant_frames )
-max_grant_frames = DEFAULT_MAX_NR_GRANT_FRAMES;
+max_grant_frames = ((max_page >> 32) ? 2 : 1) *
+   DEFAULT_MAX_NR_GRANT_FRAMES;
 
 if ( !max_maptrack_frames )
 max_maptrack_frames = DEFAULT_MAX_MAPTRACK_FRAMES;
-- 
2.12.3


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

[Xen-devel] [PATCH] x86/page: Implement {get, set}_pte_flags() as static inlines

[Andrew Cooper]

This resolves 11 Coverity issues along the lines of the following:

1600for ( i = 0; i < NR_RESERVED_GDT_PAGES; i++ )

CID: Operands don't affect result
(CONSTANT_EXPRESSION_RESULT)result_independent_of_operands: ((33U /* 1U |
0x20U */) | (({...}) ? 8388608U /* 1U << 23 */ : 0) | 0x40U | 2U) & 4095
is always 0x63 regardless of the values of its operands. This occurs as
the bitwise second operand of "|".

1601l1e_write(pl1e + FIRST_RESERVED_GDT_PAGE + i,
1602  l1e_from_pfn(mfn + i, __PAGE_HYPERVISOR_RW));

This is presumably because once preprocessed, the association of joint logic
inside {get,set}_pte_flags() is lost.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/include/asm-x86/x86_64/page.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/xen/include/asm-x86/x86_64/page.h 
b/xen/include/asm-x86/x86_64/page.h
index 1151ce9..1fe4531 100644
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -121,8 +121,16 @@ typedef l4_pgentry_t root_pgentry_t;
  */
 
 /* Extract flags into 24-bit integer, or turn 24-bit flags into a pte mask. */
-#define get_pte_flags(x) (((int)((x) >> 40) & ~0xFFF) | ((int)(x) & 0xFFF))
-#define put_pte_flags(x) (((intpte_t)((x) & ~0xFFF) << 40) | ((x) & 0xFFF))
+#ifndef __ASSEMBLY__
+static inline unsigned int get_pte_flags(intpte_t x)
+{
+return ((x >> 40) & ~0xfff) | (x & 0xfff);
+}
+static inline intpte_t put_pte_flags(unsigned int x)
+{
+return (((intpte_t)x & ~0xfff) << 40) | (x & 0xfff);
+}
+#endif
 
 /*
  * Protection keys define a new 4-bit protection key field
-- 
2.1.4


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

Re: [Xen-devel] [RFC] Unicore Subproject Proposal

[Andrew Cooper]

On 07/09/17 11:25, Felipe Huici wrote:
> Background
> --
> In recent years, several papers and projects dedicated to unikernels have
> shown the immense potential for performance gains that these have. By
> leveraging specialization and the use of minimalistic OSes, unikernels are
> able to yield impressive numbers, including fast instantiation times (tens
> of milliseconds or less), tiny memory footprints (a few MBs or even KBs),
> high network throughput (10-40 Gb/s), and high consolidation (e.g., being
> able to run thousands of instances on a single commodity server), not to
> mention a reduced attack surface and the potential for easier
> certification. Unikernel projects worthy of mention include MirageOS,
> ClickOS, Erlang on Xen, OSv, HALVM, and Minicache, among others.
>
> The fundamental drawback of unikernels is that they require that
> applications be manually ported to the underlying minimalistic OS (e.g.
> having to port nginx, snort, mysql or memcached to MiniOS or OSv); this
> requires both expert work and often considerable amount of time. In
> essence, we need to pick between either high performance with unikernels,
> or no porting effort but decreased performance and decreased efficiency
> with standard OS/VM images. The goal of this proposal is to change this
> status quo by providing a highly configurable unikernel code base; we call
> this base Unicore.
>
> This project also aims to concentrate the various efforts currently going
> on in the Xen community regarding minimalistic OSes (essentially different
> variants of MiniOS). We think that splitting the community across these
> variants is counter-productive and hope that Unicore will provide a common
> place for all or most improvements and customizations of minimalistic
> OSes. The long term goal is to replace something like MiniOS with a tool
> that can automatically build such a minimalistic OS.

I thoroughly approve of a project along these lines.  Microkernels have
huge potential to offer, but they are sufficiently complicated to work
with that very few people can.

>
> Unicore - The "Unikernel Core"
> -
> The high level goal of Unicore is to be able to build unikernels targeted
> at specific applications without requiring the time-consuming, expert work
> that building such a unikernel requires today. An additional goal (or
> hope) of Unicore is that all developers interested in unikernel
> development would contribute by supplying libraries rather than working on
> independent projects with different code bases as it is done now. The main
> idea behind Unicore is depicted in Figure 1 and consists of two basic
> components:

Have you encountered the netbsd rumpkernel project?  I don't it
referenced in your text (apologies if I've missed it).

http://events.linuxfoundation.org/sites/events/files/slides/xdps15-talk-final_0.pdf
is a presentation on from a previous Xen Developer Summit, and

One particular need build solution there was to not alter the build
system of the individual apps, and pass in the rest of the microkernel
as a cross-compile environment.  It's not entirely clear how you plan to
do this part of the building, but anything which involves modifying the
end applications is going to cause a non-trivial maintenance burden.

>  
>
> [Attachment: unicore-oneslider.pdf]
>
>
> Figure 1. Unicore architecture.
>
>  
> Library pools would contain libraries that the user of Unicore can select
> from to create the unikernel. From the bottom up, library pools are
> organized into (1) the architecture library tool, containing libraries
> specific to a computer architecture (e.g., x86_64, ARM32 or MIPS); (2) the
> platform tool, where target platforms can be Xen, KVM, bare metal (i.e. no
> virtualization) and user-space Linux;

On the x86 Xen side of things, you should treat PV and HVM guests as
different platforms, and their tradeoffs are quite different.

The one semi-supported microkernel in the Xen world is stub-qemu, and in
principle this does give better isolation than qemu running in dom0, but
it also exposes other attack surfaces.  If you assume an HVM guest has
compromised its stub-qemu, it means that security issues exposed only to
PV guests are within the reach of an HVM guest.  In this circumstance,
having an HVM stub qemu would give the system a reduced attack surface
compared to a PV stub qemu.

>  and (3) the main library pool,
> containing a rich set of functionality to build the unikernel from. This
> last library includes drivers (both virtual such as netback/netfront and
> physical such as ixgbe), filesystems, memory allocators, schedulers,
> network stacks, standard libs (e.g. libc, openssl, etc.), runtimes (e.g. a
> Python interpreter and debugging and profiling tools. These pools of
> libraries constitute a code base for creating unikernels. As shown, a
> library can be relatively large (e.g libc) or quite small (a scheduler),
> which should allow for a fair amount 

Re: [Xen-devel] ARM64:Porting xen to new hardware

[bharat gohil]

Hello Olensandr,

I able to boot xen and trying to boot dom0 but there are no console log for
dom0.

following log for xen and it stuck booting dom0.

(XEN) I/O virtualisation disabled
(XEN) build-id: 7c2a3c70fb94754801d18c4cb9e3db3ffa01d8c4
(XEN) alternatives: Patching with alt table 400d2e08 ->
400d32dc
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 40148158
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x004800-0x005000 (128MB)
(XEN) Grant table range: 0x00bfe0-0x00bfe65000
(XEN) Loading zImage from 40148158 to
4808-4948
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x4fe0-0x4fe0f31e
(XEN) Scrubbing Free RAM on 1 nodes using 3 CPUs
(XEN) ..done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input
to Xen)
(XEN) Freed 272kB init memory.

I have done all the xen configuration in linux kernel 4.9. This kernel
booting fine without xen.

following are the DTB changes,

chosen {
#address-cells = <1>;
#size-cells = <1>;
bootargs = "console=dtuart dtuart=serial0 dom0_mem=128M";
stdout-path = "serial0";
module: module@0 {
compatible = "xen,linux-zimage", "xen,multiboot-module";
reg = <0x40148158 0x140>;
bootargs = "console=hvc0,921600n8 earlyprintk=xen debug
ignore_loglevel rw root=/dev/mmcblk0p7";
};

};

Can you tell me how to debug dom0 booting or anything which i can check?


Thanks,
Bharat

On Wed, Sep 6, 2017 at 3:49 PM, Oleksandr Tyshchenko 
wrote:

> Hi Bharat
>
> On Wed, Sep 6, 2017 at 10:01 AM, bharat gohil  wrote:
> > Hello Oleksandr,
> >
> > Thank you very much.It resolved my issue.
> Sounds great!
>
> >
> > Thanks,
> > Bharat
> >
> > On Mon, Sep 4, 2017 at 6:24 PM, Oleksandr Tyshchenko <
> olekst...@gmail.com>
> > wrote:
> >>
> >> Hi Bharat
> >>
> >> On Mon, Sep 4, 2017 at 7:13 AM, bharat gohil 
> wrote:
> >> > Hello Oleksandr,
> >> >
> >> > I have corrected  GIC settings but no success.Following line disappear
> >> > from
> >> > log.
> >> >>>XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
> 0x2000
> >> >
> >> > Is anything else which can I try.
> >> >
> >> > I don’t know much about xen internal for ARM architecture. As you
> >> > mentioned,
> >> >>>Wrong GIC settings might lead to that IPIs won't work as expected.
> And
> >> >>>boot CPU will get stuck waiting for another CPU.
> >> >
> >> > Can you explain it with some boot sequence and relation with IPI?
> >>
> >> Well, we faced similar issue with R-Car Gen3 H3 SoC. Xen hung at
> >> smp_call_function (one CPU didn't receive interrupt from another one).
> >> Next patch helped us to fix this issue:
> >> https://patchwork.kernel.org/patch/9163065/
> >>
> >> I assume the SoC you are working with has "arm,gic-400" compatible GIC.
> >> Can you take a look at the patch, maybe it is your case too.
> >>
> >> >
> >> > Thanks,
> >> > Bharat
> >> >
> >> >
> >> > On Thu, Aug 31, 2017 at 5:28 PM, Oleksandr Tyshchenko
> >> > 
> >> > wrote:
> >> >>
> >> >> On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil 
> >> >> wrote:
> >> >> > Hello Oleksandr,
> >> >> Hi Bharat
> >> >>
> >> >> >
> >> >> > I had removed A72 cluster and tried to boot only two A35 but I got
> >> >> > same
> >> >> > error.
> >> >> >
> >> >> > Is anything added or missing in A35 compare to A53?
> >> >> Unfortunately, I don't know.
> >> >>
> >> >> BTW, did you check your GIC settings in the device-tree?
> >> >>
> >> >> >
> >> >> > Regards,
> >> >> > Bharat
> >> >> >
> >> >> > On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil 
> >> >> > wrote:
> >> >> >>
> >> >> >> Hello Oleksandr,
> >> >> >> Thank you very much for your input.
> >> >> >>
> >> >> >> Yes. agree. I will check by removing A72 core from DT.
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Bharat
> >> >> >>
> >> >> >> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
> >> >> >>  wrote:
> >> >> >>>
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> Not sure that I am a competent person, just my assumptions.
> >> >> >>>
> >> >> >>> CCed ARM guys.
> >> >> >>>
> >> >> >>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil <
> ghl.b...@gmail.com>
> >> >> >>> wrote:
> >> >> >>> > Hello All
> >> >> >>> >
> >> >> >>> > I am trying to run Xen on new hardware which has two A35 and
> one
> >> >> >>> > A72
> >> >> >>> > core.
> >> >> >>> > Xen booted intially but it hangs at
> >> >> >>> > smp_call_function(setup_virt_paging_one,
> >> >> >>> > (void *)val, 1) function call.
> >> >> >>>
> >> >> >>> It might be a consequence of that CPU cores are different. And
> they
> >> >> >>> might have different set of 

Re: [Xen-devel] [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 September 2017 13:16
> To: Paul Durrant 
> Cc: Wei Liu ; xen-de...@lists.xenproject.org; Ian
> Jackson ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) 
> Subject: Re: [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they
> are actually requsted
> 
> On Thu, Sep 07, 2017 at 01:03:46PM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Wei Liu [mailto:wei.l...@citrix.com]
> > > Sent: 07 September 2017 13:00
> > > To: Paul Durrant 
> > > Cc: xen-de...@lists.xenproject.org; Ian Jackson
> ;
> > > Wei Liu ; Andrew Cooper
> > > ; George Dunlap
> > > ; Jan Beulich ; Konrad
> > > Rzeszutek Wilk ; Stefano Stabellini
> > > ; Tim (Xen.org) 
> > > Subject: Re: [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until
> they
> > > are actually requsted
> > >
> > > On Tue, Sep 05, 2017 at 12:37:15PM +0100, Paul Durrant wrote:
> > > > A subsequent patch will introduce a new scheme to allow an emulator
> to
> > > > map ioreq server pages directly from Xen rather than the guest P2M.
> > > >
> > > > This patch lays the groundwork for that change by deferring mapping of
> > > > gfns until their values are requested by an emulator. To that end, the
> > > > pad field of the xen_dm_op_get_ioreq_server_info structure is re-
> > > purposed
> > > > to a flags field and new flag, XEN_DMOP_no_gfns, defined which
> modifies
> > > the
> > > > behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to
> > > avoid
> > > > requesting the gfn values.
> > > >
> > > > Signed-off-by: Paul Durrant 
> > > > Reviewed-by: Roger Pau Monné 
> > > > ---
> > > > Cc: Ian Jackson 
> > > > Cc: Wei Liu 
> > > > Cc: Andrew Cooper 
> > > > Cc: George Dunlap 
> > > > Cc: Jan Beulich 
> > > > Cc: Konrad Rzeszutek Wilk 
> > > > Cc: Stefano Stabellini 
> > > > Cc: Tim Deegan 
> > > >
> > > > v3:
> > > >  - Updated in response to review comments from Wei and Roger.
> > > >  - Added a HANDLE_BUFIOREQ macro to make the code neater.
> > > >  - This patch no longer introduces a security vulnerability since there
> > > >is now an explicit limit on the number of ioreq servers that may be
> > > >created for any one domain.
> > > > ---
> > > >  tools/libs/devicemodel/core.c   |  8 +
> > > >  tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
> > > >  xen/arch/x86/hvm/dm.c   |  9 --
> > > >  xen/arch/x86/hvm/ioreq.c| 41 
> > > > +
> > > >  xen/include/asm-x86/hvm/domain.h|  2 +-
> > > >  xen/include/public/hvm/dm_op.h  | 32 
> > > > +++
> > > >  6 files changed, 59 insertions(+), 39 deletions(-)
> > > >
> > > > diff --git a/tools/libs/devicemodel/core.c
> b/tools/libs/devicemodel/core.c
> > > > index fcb260d29b..28958934bf 100644
> > > > --- a/tools/libs/devicemodel/core.c
> > > > +++ b/tools/libs/devicemodel/core.c
> > > > @@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
> > > >
> > > >  data->id = id;
> > > >
> > > > +/*
> > > > + * If the caller is not requesting gfn values then instruct the
> > > > + * hypercall not to retrieve them as this may cause them to be
> > > > + * mapped.
> > > > + */
> > > > +if (!ioreq_gfn && !bufioreq_gfn)
> > > > +data->flags |= XEN_DMOP_no_gfns;
> > > > +
> > >
> > > Sorry for not having noticed this earlier.
> > >
> > > This is a slight change to a stable API. The new functionality is an
> > > extension of the old. I would suggest you bump the minor number of this
> > > library as well.
> > >
> >
> > I don't believe there is an API change here. The code always coped with
> NULL being passed, it just wasn't documented. Or is there something else I'm
> missing?
> >
> 
> There is.  The original code copes with NULL as in "I doesn't care,
> hypervisor will deal with it"; the new code actually gives NULL another
> meaning.
> 
> Suppose an application that is compiled for this version,
> which discovered that passing NULL has behaviour A and then, when it
> runs on a previous version of this library (it would happily do so
> because MAJOR.MINOR has not changed) and gets behaviour B.
> 
> Does that make sense?

I don't 

[Xen-devel] Audio device Passthrough in ARM

[Ajmal M Ali]

I have installed Xen 4.8.0 on an Ubuntu PC and I was able to get audio in
Domain U using PCI passthrough by hot-plugging the audio device controller
to Domain U using xl and loading the corresponding PCI frontend and backend
modules[https://wiki.xenproject.org/wiki/Xen_PCI_Passthrough].

I wish to do the same for R-Car H3(arm64). But I was unable to select the
PCI frontend and backend module during kernel building since PCI can only
be selected for x86 architecture.

In R-Car H3, the I2C bus is responsible to transfer sound signals from SoC
to Codec. Would I have to do pass-through for I2C in order to enable sound
in Domain U? Has anyone ever done or tried it before? Is there any other
way to enable sound in Domain U?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Wei Liu]

On Thu, Sep 07, 2017 at 01:03:46PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 07 September 2017 13:00
> > To: Paul Durrant 
> > Cc: xen-de...@lists.xenproject.org; Ian Jackson ;
> > Wei Liu ; Andrew Cooper
> > ; George Dunlap
> > ; Jan Beulich ; Konrad
> > Rzeszutek Wilk ; Stefano Stabellini
> > ; Tim (Xen.org) 
> > Subject: Re: [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they
> > are actually requsted
> > 
> > On Tue, Sep 05, 2017 at 12:37:15PM +0100, Paul Durrant wrote:
> > > A subsequent patch will introduce a new scheme to allow an emulator to
> > > map ioreq server pages directly from Xen rather than the guest P2M.
> > >
> > > This patch lays the groundwork for that change by deferring mapping of
> > > gfns until their values are requested by an emulator. To that end, the
> > > pad field of the xen_dm_op_get_ioreq_server_info structure is re-
> > purposed
> > > to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies
> > the
> > > behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to
> > avoid
> > > requesting the gfn values.
> > >
> > > Signed-off-by: Paul Durrant 
> > > Reviewed-by: Roger Pau Monné 
> > > ---
> > > Cc: Ian Jackson 
> > > Cc: Wei Liu 
> > > Cc: Andrew Cooper 
> > > Cc: George Dunlap 
> > > Cc: Jan Beulich 
> > > Cc: Konrad Rzeszutek Wilk 
> > > Cc: Stefano Stabellini 
> > > Cc: Tim Deegan 
> > >
> > > v3:
> > >  - Updated in response to review comments from Wei and Roger.
> > >  - Added a HANDLE_BUFIOREQ macro to make the code neater.
> > >  - This patch no longer introduces a security vulnerability since there
> > >is now an explicit limit on the number of ioreq servers that may be
> > >created for any one domain.
> > > ---
> > >  tools/libs/devicemodel/core.c   |  8 +
> > >  tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
> > >  xen/arch/x86/hvm/dm.c   |  9 --
> > >  xen/arch/x86/hvm/ioreq.c| 41 
> > > +
> > >  xen/include/asm-x86/hvm/domain.h|  2 +-
> > >  xen/include/public/hvm/dm_op.h  | 32 +++
> > >  6 files changed, 59 insertions(+), 39 deletions(-)
> > >
> > > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
> > > index fcb260d29b..28958934bf 100644
> > > --- a/tools/libs/devicemodel/core.c
> > > +++ b/tools/libs/devicemodel/core.c
> > > @@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
> > >
> > >  data->id = id;
> > >
> > > +/*
> > > + * If the caller is not requesting gfn values then instruct the
> > > + * hypercall not to retrieve them as this may cause them to be
> > > + * mapped.
> > > + */
> > > +if (!ioreq_gfn && !bufioreq_gfn)
> > > +data->flags |= XEN_DMOP_no_gfns;
> > > +
> > 
> > Sorry for not having noticed this earlier.
> > 
> > This is a slight change to a stable API. The new functionality is an
> > extension of the old. I would suggest you bump the minor number of this
> > library as well.
> > 
> 
> I don't believe there is an API change here. The code always coped with NULL 
> being passed, it just wasn't documented. Or is there something else I'm 
> missing?
> 

There is.  The original code copes with NULL as in "I doesn't care,
hypervisor will deal with it"; the new code actually gives NULL another
meaning.

Suppose an application that is compiled for this version,
which discovered that passing NULL has behaviour A and then, when it
runs on a previous version of this library (it would happily do so
because MAJOR.MINOR has not changed) and gets behaviour B.

Does that make sense?

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

Re: [Xen-devel] [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Paul Durrant]

> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 07 September 2017 13:00
> To: Paul Durrant 
> Cc: xen-de...@lists.xenproject.org; Ian Jackson ;
> Wei Liu ; Andrew Cooper
> ; George Dunlap
> ; Jan Beulich ; Konrad
> Rzeszutek Wilk ; Stefano Stabellini
> ; Tim (Xen.org) 
> Subject: Re: [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they
> are actually requsted
> 
> On Tue, Sep 05, 2017 at 12:37:15PM +0100, Paul Durrant wrote:
> > A subsequent patch will introduce a new scheme to allow an emulator to
> > map ioreq server pages directly from Xen rather than the guest P2M.
> >
> > This patch lays the groundwork for that change by deferring mapping of
> > gfns until their values are requested by an emulator. To that end, the
> > pad field of the xen_dm_op_get_ioreq_server_info structure is re-
> purposed
> > to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies
> the
> > behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to
> avoid
> > requesting the gfn values.
> >
> > Signed-off-by: Paul Durrant 
> > Reviewed-by: Roger Pau Monné 
> > ---
> > Cc: Ian Jackson 
> > Cc: Wei Liu 
> > Cc: Andrew Cooper 
> > Cc: George Dunlap 
> > Cc: Jan Beulich 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Stefano Stabellini 
> > Cc: Tim Deegan 
> >
> > v3:
> >  - Updated in response to review comments from Wei and Roger.
> >  - Added a HANDLE_BUFIOREQ macro to make the code neater.
> >  - This patch no longer introduces a security vulnerability since there
> >is now an explicit limit on the number of ioreq servers that may be
> >created for any one domain.
> > ---
> >  tools/libs/devicemodel/core.c   |  8 +
> >  tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
> >  xen/arch/x86/hvm/dm.c   |  9 --
> >  xen/arch/x86/hvm/ioreq.c| 41 
> > +
> >  xen/include/asm-x86/hvm/domain.h|  2 +-
> >  xen/include/public/hvm/dm_op.h  | 32 +++
> >  6 files changed, 59 insertions(+), 39 deletions(-)
> >
> > diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
> > index fcb260d29b..28958934bf 100644
> > --- a/tools/libs/devicemodel/core.c
> > +++ b/tools/libs/devicemodel/core.c
> > @@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
> >
> >  data->id = id;
> >
> > +/*
> > + * If the caller is not requesting gfn values then instruct the
> > + * hypercall not to retrieve them as this may cause them to be
> > + * mapped.
> > + */
> > +if (!ioreq_gfn && !bufioreq_gfn)
> > +data->flags |= XEN_DMOP_no_gfns;
> > +
> 
> Sorry for not having noticed this earlier.
> 
> This is a slight change to a stable API. The new functionality is an
> extension of the old. I would suggest you bump the minor number of this
> library as well.
> 

I don't believe there is an API change here. The code always coped with NULL 
being passed, it just wasn't documented. Or is there something else I'm missing?

> The rest looks good to me.

Thanks,

  Paul

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

Re: [Xen-devel] [PATCH v4 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:15PM +0100, Paul Durrant wrote:
> A subsequent patch will introduce a new scheme to allow an emulator to
> map ioreq server pages directly from Xen rather than the guest P2M.
> 
> This patch lays the groundwork for that change by deferring mapping of
> gfns until their values are requested by an emulator. To that end, the
> pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
> to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
> behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
> requesting the gfn values.
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> 
> v3:
>  - Updated in response to review comments from Wei and Roger.
>  - Added a HANDLE_BUFIOREQ macro to make the code neater.
>  - This patch no longer introduces a security vulnerability since there
>is now an explicit limit on the number of ioreq servers that may be
>created for any one domain.
> ---
>  tools/libs/devicemodel/core.c   |  8 +
>  tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
>  xen/arch/x86/hvm/dm.c   |  9 --
>  xen/arch/x86/hvm/ioreq.c| 41 
> +
>  xen/include/asm-x86/hvm/domain.h|  2 +-
>  xen/include/public/hvm/dm_op.h  | 32 +++
>  6 files changed, 59 insertions(+), 39 deletions(-)
> 
> diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
> index fcb260d29b..28958934bf 100644
> --- a/tools/libs/devicemodel/core.c
> +++ b/tools/libs/devicemodel/core.c
> @@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
>  
>  data->id = id;
>  
> +/*
> + * If the caller is not requesting gfn values then instruct the
> + * hypercall not to retrieve them as this may cause them to be
> + * mapped.
> + */
> +if (!ioreq_gfn && !bufioreq_gfn)
> +data->flags |= XEN_DMOP_no_gfns;
> +

Sorry for not having noticed this earlier.

This is a slight change to a stable API. The new functionality is an
extension of the old. I would suggest you bump the minor number of this
library as well.

The rest looks good to me.

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

Re: [Xen-devel] [PATCH v4 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Jan Beulich]

>>> On 07.09.17 at 13:36,  wrote:
> On Thu, Sep 07, 2017 at 12:18:25PM +0100, Paul Durrant wrote:
>> Ok, if you think it's necessary. (This is a tools-only hypercall and the 
> ranges are supplied by privcmd, allocated in kernel).
> 
> IMHO we should allow for use case for semi-trusted users of this
> hypercall in the future.

There are many other Dom0-only hypercalls where we don't apply
relaxed checking, so the one here shouldn't be an exception.

Jan


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

Re: [Xen-devel] [PATCH v2 2/2] hvmloader: clone REP INSW test from REP INSB one

[Andrew Cooper]

On 07/09/17 11:02, Jan Beulich wrote:
> This also covers an individual string insn access crossing a page
> boundary.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

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

[Jan Beulich]

>>> On 07.09.17 at 13:31,  wrote:
> On 08/31/2017 01:46 PM, Jan Beulich wrote:
> On 31.08.17 at 12:27,  wrote:
>>> +### Live Patching
>>> +
>>> +Status: Supported, x86 only
>>> +
>>> +Compile time disabled
>> 
>> Bu we're settled to change that, aren't we? It was even meant to be
>> so in 4.9, but then didn't make it.
> 
> Change the compile time disabling?  I don't really know. :-)

Yeah, well, that series is taking awfully long to become ready to go
in. Konrad?

> What gets checked in should ideally be true at the time it's checked in.

Agreed.

>>> +### Virtual Machine Introspection
>>> +
>>> +Status: Supported, x86 only
>> 
>> Including security support?
> 
> Not sure, actually.  Opinions?

So far it was my understanding that this is at best preview.

>>> +### x86/Advanced Vector eXtension
>>> +
>>> +Status: Supported
>> 
>> How fine-grained do we want this document to be? If this one is a
>> valid entry, then many other CPUID bits will need to have entries
>> too.
> 
> Well remember that this list came from the "Feature support matrix",
> which was also meant to announce / brag about new features we were
> developing.
> 
> This is already really long.  Anything that comes accessible to guests
> by default (which AVX instructions are) must be supported (including
> security support).  I wonder if there's a better way to specify this
> sort of thing.

One option may be to refer to public/arch-x86/cpufeatureset.h,
but of course that would require it to gain support annotations,
which in turn may be ugly. Short of enumerating all supported
CPUID flags here, I can't think of better alternatives.

Jan


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

Re: [Xen-devel] [PATCH v4 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:09PM +0100, Paul Durrant wrote:
> A previous patch added support for priv-mapping guest resources directly
> (rather than having to foreign-map, which requires P2M modification for
> HVM guests).
> 
> This patch makes use of the new API to seed the guest grant table unless
> the underlying infrastructure (i.e. privcmd) doesn't support it, in which
> case the old scheme is used.
> 
> NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
>   actually unnecessary, as the grant table has already been seeded
>   by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().
> 
> Signed-off-by: Paul Durrant 
> Acked-by: Marek Marczykowski-Górecki 
> Reviewed-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 03/12] tools/libxenforeignmemory: add support for resource mapping

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:07PM +0100, Paul Durrant wrote:
> A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
> resources for direct priv-mapping.
> 
> This patch adds new functionality into libxenforeignmemory to make use
> of a new privcmd ioctl [1] that uses the new memory op to make such
> resources available via mmap(2).
> 
> [1] 
> http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 04/12] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:08PM +0100, Paul Durrant wrote:
> By using a static inline stub in private.h for OS where this functionality
> is not implemented, the various duplicate stubs in the OS-specific source
> modules can be avoided.
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 09/12] x86/hvm/ioreq: simplify code and use consistent naming

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:13PM +0100, Paul Durrant wrote:
> This patch re-works much of the ioreq server initialization and teardown
> code:
> 
> - The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
>   to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
>   separately by outer functions.
> - Several functions now test the validity of the hvm_ioreq_page gfn value
>   to determine whether they need to act. This means can be safely called
>   for the bufioreq page even when it is not used.
> - hvm_add/remove_ioreq_gfn() simply return in the case of the default
>   IOREQ server so callers no longer need to test before calling.
> - hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
>   to mirror the existing hvm_ioreq_server_unmap_pages().
> 
> All of this significantly shortens the code.
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 10/12] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:14PM +0100, Paul Durrant wrote:
> This patch adjusts the ioreq server code to use type-safe gfn_t values
> where possible. No functional change.
> 
> Signed-off-by: Paul Durrant 
> Reviewed-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/HVM: correct repeat count update in linear->phys translation

[Jan Beulich]

>>> On 07.09.17 at 13:35,  wrote:
> On 07/09/17 12:24, Jan Beulich wrote:
> On 07.09.17 at 13:15,  wrote:
>>> On 07/09/17 11:41, Jan Beulich wrote:
 For the insn emulator's fallback logic in REP MOVS/STOS/INS/OUTS
 handling to work correctly, *reps must not be set to zero when
 returning X86EMUL_UNHANDLEABLE.

 Signed-off-by: Jan Beulich 
>>> Why is this?  In the case that X86EMUL_UNHANDLEABLE is returned, the
>>> emulator appears to override nr_reps to 1.
>> Where did you see that? What we have is
>>
>> if ( (nr_reps > 1 || rc == X86EMUL_UNHANDLEABLE) && ops->rep_ins )
>> rc = ops->rep_ins(port, dst.mem.seg, dst.mem.off, dst.bytes,
>>   _reps, ctxt);
>> if ( nr_reps >= 1 && rc == X86EMUL_UNHANDLEABLE )
>> {
>> fail_if(!ops->read_io || !ops->write);
>> if ( (rc = ops->read_io(port, dst.bytes, , ctxt)) != 0 )
>> goto done;
>> nr_reps = 0;
>> }
> 
> Ah - the INS/OUTS handing is different to the MOVS/STOS, where the
> MOVS/STOS does cope fine with reps being zero.

Oh, right.

> With a suitable adjustment to the commit message, Reviewed-by: Andrew
> Cooper 

I'd just dropped the MOVS/STOS from the text, but left it unchanged
otherwise.

Jan


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

Re: [Xen-devel] [PATCH v4 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Wei Liu]

On Tue, Sep 05, 2017 at 12:37:12PM +0100, Paul Durrant wrote:
> A subsequent patch will remove the current implicit limitation on creation
> of ioreq servers which is due to the allocation of gfns for the ioreq
> structures and buffered ioreq ring.
> 
> It will therefore be necessary to introduce an explicit limit and, since
> this limit should be small, it simplifies the code to maintain an array of
> that size rather than using a list.
> 
> Also, by reserving an array slot for the default server and populating
> array slots early in create, the need to pass an 'is_default' boolean
> to sub-functions can be avoided.
> 
> Signed-off-by: Paul Durrant 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 02/11] vpci: introduce basic handlers to trap accesses to the PCI config space

[Jan Beulich]

>>> On 07.09.17 at 13:30,  wrote:
> On Thu, Sep 07, 2017 at 03:06:50AM -0600, Jan Beulich wrote:
>> >>> On 06.09.17 at 17:40,  wrote:
>> > On Mon, Sep 04, 2017 at 09:38:11AM -0600, Jan Beulich wrote:
>> >> >>> On 14.08.17 at 16:28,  wrote:
>> >> > Changes since v4:
>> >> >[...]
>> >> > * Hypervisor code:
>> >> >[...]
>> >> >  - Constify the data opaque parameter of read handlers.
>> >> 
>> >> Is that a good idea? Such callbacks should generally be allowed to
>> >> modify their state even if the operation is just a read - think of a
>> >> private lock or statistics/debugging data to be updated.
>> > 
>> > Right now the consistency of the opaque data is kept by the global
>> > vpci lock, which I like because it makes the code simpler. If the
>> > opaque data is not constified for the read handlers then I would be
>> > against using a read/write lock.
>> > 
>> > Statistic/debug data IMHO should be kept in a separate structure with
>> > it's own lock, that's referenced by the opaque data. This would allow
>> > Xen to not allocate this for non-debug builds, reducing memory
>> > footprint and lock contention in production.
>> 
>> I don't like this, as it makes adding such transiently needlessly
>> hard (as one would need to drop all the const-s or cast them away).
> 
> Hm, I'm not sure I follow. I was thinking of something along the lines
> of:
> 
> struct vpci_msi_stats {...};
> 
> struct vpci_msi {
> [...]
> struct vpci_msi_stats *stats;
> };
> 
> Then you can easily have a handler like:
> 
> static void vpci_msi_reg(..., const void *data)
> {
> const struct vpci_msi *msi = data;
> struct vpci_msi_stats *stats = msi->stats;
> [...]
> }
> 
> That should work AFAICT.

Sure, but the structure needs allocating. Which again is something
I wouldn't want to have to worry about when adding _temporary_
debugging or statistics code. But this is all moot anyway with ...

>> Would it be an
>> alternative to make the (spin) lock per-device rather than per-
>> domain? That might also be a good idea for pass-through (as there
>> Dom0 as well as the owning DomU fundamentally have access to
>> the config space of a device, and they'd better be synchronized).
> 
> That would also work, then I agree it should be a spin lock and the
> const from the read handlers can be dropped. Unless you say otherwise
> I'm going to implement this.

... this.

Jan


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