Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Alexey G]

 If the actual SMI source is not related to some place in the NMI
 handler code but was eg. due to some SMI timer, lowering NMI
 watchdog frequency might not fix the issue completely, but lower
 its reproducibility (perhaps to some very rare occurrences). So
 it's better be sure what was the real source of SMI.
 
>>>
>>> This *is* related to this instruction - it was confirmed
>>> empirically. Removing this instruction stops SMIs from occurring
>>> and effectively removes the issue leaving the frequency unchanged.  
>> 
>> Hmm, it would be interesting to know for what evil purpose does it
>> need to trap I/O port 61h.
>> BTW, on which motherboard model the issue was reproduced?
>>   
>
>The issue has been reported for some Dell/Huawei Skylake platforms (one
>of them PowerEdge R740 to be precise) but I don't think the others are
>unaffected (the issue supposedly originates from Intel's reference
>code)
>- the default BIOS setup indeed matters.

Here is a bit of info you might find useful. I did a quick research on
my test system (Gigabyte GA-H270M-D3H) in order to confirm if BIOS traps
I/O port 61h (NMI status) and for what purposes.

Well, turns out it really does.
Moreover, it's actually the only fixed I/O port location trapped by SMI
I/O traps on this system. Few others are simply 'allocated' ones,
meaning the real I/O port address being trapped is chosen dynamically by
supplying Address=0 to a corresponding call to EFI I/O Trap interface
function -- such I/O traps may be used as interfaces with a SMI handler
in a manner similar to the SW SMI interface.

The EFI module responsible for installing port 61h SMI I/O Trap is
PchInitSmm in my case. The related code is:
...
mov eax, 61h
lea r9, qword_5778
mov [rsp+98h+io_trap_ctx.io_address], ax
mov rax, cs:pIoTrapIF
lea r8, [rsp+98h+io_trap_ctx]
lea rdx, Port61h_IoTrapHandler
mov rcx, rax
mov [rsp+98h+io_trap_ctx.trap_type], ebp  ; trap reads
mov [rsp+98h+io_trap_ctx.io_len], bp  ; ebp=1
callqword ptr [rax]
...

The actual handler (named Port61h_IoTrapHandler in the above code) is
fairly lightweight and does a bit of useless black magic.

First, there is a loop for all CPUs which finds which CPU actually
caused trapped I/O operation by reading NMI status port.

Then it reads the original port 61h value and set NMI_SC bit4 to its
inverted previous state for the selected CPU' bit. And then updated AL
register value is returned to the NMI_SC-reading user code (via
patching RAX register value in SMRAM saved state):

; ebp = 61h, rbx = CPU index
...
mov edx, ebp
in  al, dx

mov r8, cs:bmNmiRefTogglesForCpus
mov rcx, rbx
mov edx, 1
shl edx, cl
mov r9, rbx
movsxd  rcx, edx
mov dl, al
and al, 0EFh
xor r8, rcx
or  dl, 10h
mov cs:bmNmiRefTogglesForCpus, r8
and r8, rcx
movzx   ecx, al
movzx   eax, dl
testr8, r8
mov edx, 1
cmovnz  ecx, eax
lea rax, [rsp+58h+al_to_return]
lea r8d, [rdx+25h]  ; EFI_SMM_SAVE_STATE_REGISTER_RAX
mov [rsp+58h+func_arg0], rax
mov rax, cs:pEFI_SMM_CPU_PROTOCOL_GUID_IF
mov [rsp+58h+al_to_return], cl
mov rcx, rax
callqword ptr [rax+8] ; WriteSaveState
...

So, the only purpose of this stuff is emulating REF_TOGGLE bit toggling
logic (simply by alternating ones and zeros on each NMI_SC read),
nothing more. Sort of workaround for some legacy code which depends on
REF_TOGGLE rolling (which is now being marked Reserved in docs).

On this particular system SMI I/O trap for port 61h neither do anything
time-consuming nor anything really useful. That Dell system must have
something similar (thanks to common EFI ref code from Intel Igor
mentioned), leaving the question why port 61h reading is so slow there.

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 118607
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 118607

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

version targeted for testing:
 xen  d87cfb59b42832920f4cf3392dccfa5b8736b699
baseline version:
 xen  1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0

Last test of basis   118607  2018-02-06 05:47:11 Z1 days
Testing same since   118622  2018-02-06 19:15:37 Z0 days1 attempts

Re: [Xen-devel] Xen ARM community call Tuesday 13th February 5PM UTC

[Edgar Iglesias]

Hi, this time works for me.

If there's time I'd like to discuss the timing of re-submitting the Xilinx EEMI 
power-management mediator.
Also, there were some questions in the previous review. Some are straight 
forward but some were around the configuration-less approach so I thought I 
could explain our approach and get feedback, perhaps someone has better ideas. 
I'll probably need 10 - 15min for that.

Thanks,
Edgar

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 06 February 2018 2:12
> To: Stefano Stabellini ; xen-devel  de...@lists.xenproject.org>; Lars Kurth ; Edgar
> Iglesias ; Stewart Hildebrand
> ; anastassios.na...@onapp.com;
> vfac...@de.adit-jv.com; Jarvis Roach ;
> Volodymyr Babchuk ; Artem Mygaiev
> ; mirela.simono...@aggios.com;
> davorin.mi...@aggios.com; robin.randh...@arm.com
> Subject: Xen ARM community call Tuesday 13th February 5PM UTC
> 
> Hi all,
> 
> I would suggest to have the next community call on Tuesday 13th February
> 5pm GMT. Does it sound good?
> 
> Do you have any specific topic you would like to discuss?
> 
> Cheers,
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  14d91c353e19b7085fdbb7b2dcc43f3355665670
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   95 days
Failing since115733  2017-11-10 17:19:59 Z   88 days  110 attempts
Testing same since   118140  2018-01-17 05:09:48 Z   20 days   31 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Marcel Apfelbaum 
  Michael S. Tsirkin 
  Paul Menzel 
  Stefan Berger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit 14d91c353e19b7085fdbb7b2dcc43f3355665670
Author: Marcel Apfelbaum 
Date:   Thu Jan 11 22:15:12 2018 +0200

pci: fix 'io hints' capability for RedHat PCI bridges

Commit ec6cb17f (pci: enable RedHat PCI bridges to reserve additional
 resources on PCI init)
added a new vendor specific PCI capability for RedHat PCI bridges
allowing them to reserve additional buses and/or IO/MEM space.

When adding the IO hints PCI capability to the pcie-root-port
without specifying a value for bus reservation, the subordinate bus
computation is wrong and the guest kernel gets messed up.

Fix it by returning to prev code if the value for bus
reservation is not set.

Removed also a wrong debug print "PCI: invalid QEMU resource reserve
cap offset" which appears if the 'IO hints' capability is not present.

Acked-by: Michael S. Tsirkin 

Re: [Xen-devel] [GSOC] Xen on ARM: create multiple guests from device tree

[Stefano Stabellini]

On Tue, 6 Feb 2018, Denis Obrezkov wrote:
> > Hello Denis,
> >
> Hello Stefano,
> > it is great to see interest in Xen on ARM and this project!
> >
> > Unfortunately RPi3 can't run Xen as far as I know due to their non-ARM
> > interrupt controller without virtualization support. Otherwise it would
> > have been a good dev board. The BeagleBoard doesn't have processors with
> > virtualization support so it cannot run Xen either (it needs an Cortex
> > A7 or A15).
> I have RPi2 and it has Cortex A7 AFAIK.
> >
> > But that's not a problem, because the latest QEMU (2.11) can run Xen
> > just fine. Build QEMU with --target-list=aarch64-softmmu, then you can
> > run it with:
> >
> > qemu-system-aarch64 -machine virt,gic_version=3 \
> > -machine virtualization=true \
> > -cpu cortex-a57 -machine type=virt \
> > -smp 4 -m 2048 \
> > -serial stdio -monitor none \
> > -bios /path/QEMU_EFI.fd \
> > -netdev user,id=hostnet0 -device virtio-net-device,netdev=hostnet0 \
> > -drive if=none,file=$DISK1,id=hd0 -device virtio-blk-device,drive=hd0
> >
> > Where DISK1 is your EFI ready disk image and QEMU_EFI.fd can be
> > downloaded from:
> >
> > http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-AARCH64/RELEASE_GCC5/QEMU_EFI.fd
> >
> > See the following for more detailed information:
> >
> > https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/qemu-system-aarch64
> >
> > Give it a try and let me know if you have any issues.
> >
> > Cheers,
> >
> > Stefano
> 
> I was able to boot to uefi shell. What can I do further? What is my
> overall goal? To build and run several instances of Linux? Make a
> patch?

Good! Please compile Xen for ARM64 and try to boot Xen and Dom0 with it.
Once you have Xen and Dom0 up and running, you can try to create a small
guest and start that as well. It will help you setup your build and test
environments.

To build Xen for ARM64, you can use native compilation inside the
qemu-system-aarch64 emulation, but it is slow. Otherwise you can use
chroot and qemu-aarch64-static (the qemu-user aarch64 target, statically
compiled). For example give a look at:

https://wiki.debian.org/Arm64Qemu


The end goal of the project is to be able to boot two domains directly
from Xen. Typically, Xen boots Dom0, then only once Dom0 is fully up and
running, a second domain can be created and that is done via the Xen
tools (xl). However, it is not always necessary to wait until Dom0 is
fully booted before starting a second guest. In many embedded
environments, you only have two or three guests in total to deal with.
It would be better to create them all in parallel directly from Xen. It
would drastically shorten the boot time.

Device tree is used to describe the hardware available on the platform.
It comes into play in this project because it is the best way to pass
the required information to Xen, so that Xen knows it needs to boot a
second guest in addition to Dom0.

Before we start the main project though, we usually ask candidates to
send a patch to fix a small issue just to show that they managed to
setup a dev and test environment correctly. We'll come back with a list
of potential small issues to fix shortly.


> I have also proposed to make a port of xen for qemu-system-riscv (it
> should be ready in Q2.2018) to people from riscv but I haven't
> received any answer.Anyway, I would like to work with xen on embedded
> platforms.

That would be awesome, but I don't think that a project like porting Xen
to riscv would fit in a GSoC project :-)

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 qemuu2b3805f370521deacab974b9c9ca07d2319a8890
baseline version:
 qemuuf24ee107a07f093bd7ed475dd48d7ba57ea3d8fe

Last test of basis   118600  2018-02-05 22:44:17 Z1 days
Testing same since   118613  2018-02-06 11:17:51 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Stefan Berger 

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

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

[Dario Faggioli]

On Tue, 2018-02-06 at 17:02 +, George Dunlap wrote:
> On 02/06/2018 06:18 AM, Juergen Gross wrote:
> > On 05/02/18 17:53, Dario Faggioli wrote:
> > > 
> > > Considering we're releasing in June, but freezing in March, do we
> > > think
> > >  it is still early enough?
> 
> > The 4.11 release is completely dominated by Meltdown/Spectre
> > mitigation
> > work. So either 4.11 will be a security focused version or we need
> > to
> > extend the development phase.
> 
> Personally I could go either way on this.  So unless someone wants to
> argue for switching now (or we significantly extend the development
> window), let's plan on leaving this for post-4.11.
> 
Yes, I agree.

And if we don't switch now, I think we should say that, unless someone
argues against your reasoning in your other email, and convince us,
we'll switch as soon as 4.12 is branched (or perhaps as soon as 4.11 is
released?).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58
baseline version:
 xen  d87cfb59b42832920f4cf3392dccfa5b8736b699

Last test of basis   118620  2018-02-06 17:02:07 Z0 days
Testing same since   118626  2018-02-06 20:01:03 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Wei Liu 
  Zhongze Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   d87cfb59b4..30cbd0c83e  30cbd0c83ef3d0edac2d5bcc41a9a2b7a843ae58 -> smoke

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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Michael Young]

On Tue, 6 Feb 2018, Wei Liu wrote:


On Tue, Jan 30, 2018 at 10:55:47PM +, Michael Young wrote:

Xen built with ocaml 4.06 gives errors such as
Error: This expression has type bytes but an expression was
expected of type string
as Byte and safe-strings which were introduced in 4.02 are the
default in 4.06.
This patch which is partly by Richard W.M. Jones of Red Hat
from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
fixes these issues.

Signed-off-by: Michael Young 
Reviewed-by: Christian Lindig 


Strangely this doesn't apply to staging. And after examining the
downloaded patch I'm not sure if my mail client is acting up. Do you
have a git branch that I can pull from?


The patch needed to be reduced as one of the sections being patched was 
removed by a recent patch. I am attaching the revised patch as a file 
in case there was also an email formatting issue.


Michael YoungFrom 247cea9b587baafaf80bcc5b44bc68defb4efa26 Mon Sep 17 00:00:00 2001
From: Michael Young 
Date: Tue, 6 Feb 2018 21:27:23 +
Subject: [PATCH 1/2 v2] make xen ocaml safe-strings compliant

Xen built with ocaml 4.06 gives errors such as
Error: This expression has type bytes but an expression was
expected of type string
as Byte and safe-strings which were introduced in 4.02 are the
default in 4.06.
This patch which is mostly by Richard W.M. Jones of Red Hat
from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
fixes these issues.

v2: drop tools/ocaml/libs/xc/xenctrl.ml from the patch as the
affected code was removed by commit d933f1a53c06002351c1e36d40615e40bd4bf6af
tools/ocaml: Drop coredump infrastructure

Signed-off-by: Michael Young 
Reviewed-by: Christian Lindig 
---
 tools/ocaml/libs/xb/xb.ml|  6 +++---
 tools/ocaml/xenstored/logging.ml | 22 +++---
 tools/ocaml/xenstored/stdext.ml  |  2 +-
 tools/ocaml/xenstored/utils.ml   | 18 +-
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/tools/ocaml/libs/xb/xb.ml b/tools/ocaml/libs/xb/xb.ml
index 50944b5fd6..aa2cf98223 100644
--- a/tools/ocaml/libs/xb/xb.ml
+++ b/tools/ocaml/libs/xb/xb.ml
@@ -84,7 +84,7 @@ let read_mmap back con s len =
 
 let read con s len =
match con.backend with
-   | Fd backfd -> read_fd backfd con s len
+   | Fd backfd -> read_fd backfd con (Bytes.of_string s) len
| Xenmmap backmmap -> read_mmap backmmap con s len
 
 let write_fd back con s len =
@@ -98,7 +98,7 @@ let write_mmap back con s len =
 
 let write con s len =
match con.backend with
-   | Fd backfd -> write_fd backfd con s len
+   | Fd backfd -> write_fd backfd con (Bytes.of_string s) len
| Xenmmap backmmap -> write_mmap backmmap con s len
 
 (* NB: can throw Reconnect *)
@@ -147,7 +147,7 @@ let input con =
| NoHdr (i, buf)  ->
(* we complete the partial header *)
if sz > 0 then
-   String.blit s 0 buf (Partial.header_size () - i) sz;
+   String.blit s 0 (Bytes.of_string buf) 
(Partial.header_size () - i) sz;
con.partial_in <- if sz = i then
HaveHdr (Partial.of_string buf) else NoHdr (i - sz, buf)
);
diff --git a/tools/ocaml/xenstored/logging.ml b/tools/ocaml/xenstored/logging.ml
index 0c0d03d0c4..d24abf8a3a 100644
--- a/tools/ocaml/xenstored/logging.ml
+++ b/tools/ocaml/xenstored/logging.ml
@@ -60,11 +60,11 @@ type logger =
 let truncate_line nb_chars line = 
if String.length line > nb_chars - 1 then
let len = max (nb_chars - 1) 2 in
-   let dst_line = String.create len in
-   String.blit line 0 dst_line 0 (len - 2);
-   dst_line.[len-2] <- '.'; 
-   dst_line.[len-1] <- '.';
-   dst_line
+   let dst_line = Bytes.create len in
+   Bytes.blit_string line 0 dst_line 0 (len - 2);
+   Bytes.set dst_line (len-2) '.'; 
+   Bytes.set dst_line (len-1) '.';
+   Bytes.to_string dst_line
else line
 
 let log_rotate ref_ch log_file log_nb_files =
@@ -252,13 +252,13 @@ let string_of_access_type = function
*)
 
 let sanitize_data data =
-   let data = String.copy data in
-   for i = 0 to String.length data - 1
+   let data = Bytes.copy data in
+   for i = 0 to Bytes.length data - 1
do
-   if data.[i] = '\000' then
-   data.[i] <- ' '
+   if Bytes.get data i = '\000' then
+   Bytes.set data i ' '
done;
-   String.escaped data
+   String.escaped (Bytes.to_string data)
 
 let activate_access_log = ref true
 let access_log_destination = ref (File (Paths.xen_log_dir ^ 
"/xenstored-access.log"))
@@ -291,7 +291,7 @@ let access_logging ~con ~tid 

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 06/02/18 16:23, Jan Beulich wrote:
 On 06.02.18 at 17:14,  wrote:
>> On 06/02/18 16:07, Jan Beulich wrote:
>> On 05.02.18 at 22:18,  wrote:
 --- a/xen/arch/x86/nmi.c
 +++ b/xen/arch/x86/nmi.c
 @@ -34,7 +34,8 @@
  #include 
  
  unsigned int nmi_watchdog = NMI_NONE;
 -static unsigned int nmi_hz = HZ;
 +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs 
>> */
 +static unsigned int nmi_hz = HZ / 10;
>>>
>>> For one - the comment should explain what "too high" means.
>>> Further - what if on another system 10Hz is still too high? I also hope
>>> you realize that you slow down boot a little for everyone just
>>> because of this one machine model. Can the lower frequency perhaps
>>> be set via DMI quirk, or otherwise obtain a command line override
>>> (perhaps something like "watchdog=probe:10Hz")?
>>>
>>
>> I can improve the comment message.
>> Why does this change slow down anything while I'm lowering the frequency
>> - not making it higher?
> 
> We wait for two occurrences of the NMI in wait_for_nmis().
> 
>> The alternative approach would be to reshuffle
>> the code and take the reason before programming the next interrupt as
>> suggested before. In that case the actual frequency would be adjusted
>> naturally I think.
> 
> Thinking about this, reading the reason early seems like a good idea
> to me irrespective of the issue here.
>

I ran a couple of experiments with different layouts in NMI handler:
it looks like it doesn't really help as merely having this instruction
inside the handler and running it at 100Hz breaks a number of timeouts
in SMP bootstrap code and makes it unstable. So we are back to lowering
the frequency as I'm now out of ideas.

The problem with a quirk/commandline parameter is that the issue is
reported for a wide variety of systems and, as it looks like, depends on
the default BIOS setup - means it's hard to identify particular
machines. We should obviously sort this out with Intel but until then
lowering the initial frequency is our only option.

Igor

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

[Xen-devel] [linux-linus bisection] complete build-armhf-pvops

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-armhf-pvops
testid kernel-build

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  23c35f48f5fbe33f68904138b23fee64df7d2f0f
  Bug not present: d3581c8ef718ae1b03e9106446ddf76b77026895
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118625/


  commit 23c35f48f5fbe33f68904138b23fee64df7d2f0f
  Author: Linus Torvalds 
  Date:   Fri Feb 2 16:44:14 2018 -0800
  
  pinctrl: remove include file from 
  
  When pulling the recent pinctrl merge, I was surprised by how a
  pinctrl-only pull request ended up rebuilding basically the whole
  kernel.
  
  The reason for that ended up being that  included
  , so any change to that file ended up causing
  pretty much every driver out there to be rebuilt.
  
  The reason for that was because 'struct device' has this in it:
  
  #ifdef CONFIG_PINCTRL
  struct dev_pin_info *pins;
  #endif
  
  but we already avoid header includes for these kinds of things in that
  header file, preferring to just use a forward-declaration of the
  structure instead.  Exactly to avoid this kind of header dependency.
  
  Since some drivers seem to expect that  header
  to come in automatically, move the include to 
  instead.  It might be better to just make the includes more targeted,
  but I'm not going to review every driver.
  
  It would definitely be good to have a tool for finding and minimizing
  header dependencies automatically - or at least help with them.  Right
  now we almost certainly end up having way too many of these things, and
  it's hard to test every single configuration.
  
  FWIW, you can get a sense of the "hotness" of a header file with something
  like this after doing a full build:
  
  find . -name '.*.o.cmd' -print0 |
  xargs -0 tail --lines=+2 |
  grep -v 'wildcard ' |
  tr ' \\' '\n' |
  sort | uniq -c | sort -n | less -S
  
  which isn't exact (there are other things in those '*.o.cmd' than just
  the dependencies, and the "--lines=+2" only removes the header), but
  might a useful approximation.
  
  With this patch,  drops to "only" having 833
  users in the current x86-64 allmodconfig.  In contrast, 
  has 14857 build files including it directly or indirectly.
  
  Of course, the headers that absolutely _everybody_ includes (things like
   etc) get a score of 23000+.
  
  Cc: Linus Walleij 
  Cc: Greg Kroah-Hartman 
  Signed-off-by: Linus Torvalds 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/build-armhf-pvops.kernel-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/build-armhf-pvops.kernel-build
 --summary-out=tmp/118625.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus build-armhf-pvops kernel-build
Searching for failure / basis pass:
 118598 fail [host=arndale-bluewater] / 118538 ok.
Failure / basis pass flights: 118598 / 118538
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Latest 35277995e17919ab838beae765f440674e8576eb 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Basis pass 4bf772b14675411a69b3c807f73006de0fe4b649 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#4bf772b14675411a69b3c807f73006de0fe4b649-35277995e17919ab838beae765f440674e8576eb
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
Loaded 1215 nodes in revision graph
Searching for test results:
 118583 [host=arndale-westfield]
 118538 pass 4bf772b14675411a69b3c807f73006de0fe4b649 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118556 fail 23c35f48f5fbe33f68904138b23fee64df7d2f0f 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118566 [host=arndale-westfield]
 118581 [host=arndale-westfield]
 118576 fail 35277995e17919ab838beae765f440674e8576eb 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118584 [host=arndale-westfield]
 118610 pass d3581c8ef718ae1b03e9106446ddf76b77026895 
c530a75c1e6a472b0eb9558310b518f0dfcd8860
 118585 [host=arndale-westfield]
 

[Xen-devel] [PATCH 1/2] xen/arm: Extend the number of memory banks supported

[Julien Grall]

When booting using Grub on Thunder-X, the number of memory available is
greater than 64. Bump the number to 128, so we can take advantage of all
the memory.

Signed-off-by: Julien Grall 

---

Note that I wasn't able to boot without this patch, because EFI stub
is printing an error when the number of region exceed 64. This will
result to fragment in bit more the memory (sounds like print
allocate memory) and will fail to get the memory on retry.
---
 xen/include/asm-arm/setup.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
index 7ff2c34dab..0cc3330807 100644
--- a/xen/include/asm-arm/setup.h
+++ b/xen/include/asm-arm/setup.h
@@ -6,7 +6,7 @@
 #define MIN_FDT_ALIGN 8
 #define MAX_FDT_SIZE SZ_2M
 
-#define NR_MEM_BANKS 64
+#define NR_MEM_BANKS 128
 
 #define MAX_MODULES 5 /* Current maximum useful modules */
 
-- 
2.11.0


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

[Xen-devel] [PATCH 0/2] Fixup for booting Xen on Thunder-X using Grub

[Julien Grall]

Hi all,

This small series will help to boot Xen on Thunder-X using Grub. This part
of my work to use Thunder-X in Osstest

Cheers,

Julien Grall (2):
  xen/arm: Extend the number of memory banks supported
  xen/arm: Blacklist SMMU on Thunder-X

 xen/arch/arm/platforms/Makefile   |  1 +
 xen/arch/arm/platforms/thunderx.c | 39 +++
 xen/include/asm-arm/setup.h   |  2 +-
 3 files changed, 41 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/platforms/thunderx.c

-- 
2.11.0


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  d87cfb59b42832920f4cf3392dccfa5b8736b699
baseline version:
 xen  1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0

Last test of basis   118597  2018-02-05 19:02:29 Z0 days
Testing same since   118620  2018-02-06 17:02:07 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   1c3545eeaf..d87cfb59b4  d87cfb59b42832920f4cf3392dccfa5b8736b699 -> smoke

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

Re: [Xen-devel] [PATCH v5 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Julien Grall]

Hi Andre,

On 02/06/2018 05:09 PM, Andre Przywara wrote:

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves abstraction.

One thing to note is that this changes the locking scheme slightly:
we hold the rank lock for a shorter period of time, not covering some
of the later lines, which deal with the "irq_desc" structure only. This
should not have any adverse effect, but is a change in locking anyway.

Signed-off-by: Andre Przywara 


Thank you for the quick respin!

Reviewed-by: Julien Grall 

Cheers,


---
  xen/arch/arm/gic-vgic.c| 41 +
  xen/arch/arm/gic.c | 44 ++--
  xen/include/asm-arm/vgic.h |  2 ++
  3 files changed, 53 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 8221ae557c..820e464fc0 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -397,6 +397,47 @@ void gic_dump_vgic_info(struct vcpu *v)
  printk("Pending irq=%d\n", p->irq);
  }
  
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,

+struct irq_desc *desc, bool connect)
+{
+unsigned long flags;
+/*
+ * Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference.
+ */
+struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
+struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
+struct pending_irq *p = irq_to_pending(v_target, virq);
+int ret = 0;
+
+/* "desc" is optional when we disconnect an IRQ. */
+ASSERT(connect && desc);
+
+/* We are taking to rank lock to prevent parallel connections. */
+vgic_lock_rank(v_target, rank, flags);
+
+if ( connect )
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !p->desc &&
+ !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+p->desc = desc;
+else
+ret = -EBUSY;
+}
+else
+{
+if ( desc && p->desc != desc )
+ret = -EINVAL;
+else
+p->desc = NULL;
+}
+
+vgic_unlock_rank(v_target, rank, flags);
+
+return ret;
+}
+
  /*
   * Local variables:
   * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4cb74d449e..968e46fabb 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -128,13 +128,7 @@ void gic_route_irq_to_xen(struct irq_desc *desc, unsigned 
int priority)
  int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
 struct irq_desc *desc, unsigned int priority)
  {
-unsigned long flags;
-/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
- * route SPIs to guests, it doesn't make any difference. */
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-struct pending_irq *p = irq_to_pending(v_target, virq);
-int res = -EBUSY;
+int ret;
  
  ASSERT(spin_is_locked(>lock));

  /* Caller has already checked that the IRQ is an SPI */
@@ -142,12 +136,9 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
  ASSERT(virq < vgic_num_irqs(d));
  ASSERT(!is_lpi(virq));
  
-vgic_lock_rank(v_target, rank, flags);

-
-if ( p->desc ||
- /* The VIRQ should not be already enabled by the guest */
- test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
-goto out;
+ret = vgic_connect_hw_irq(d, NULL, virq, desc, true);
+if ( ret )
+return ret;
  
  desc->handler = gic_hw_ops->gic_guest_irq_type;

  set_bit(_IRQ_GUEST, >status);
@@ -156,31 +147,19 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
  gic_set_irq_type(desc, desc->arch.type);
  gic_set_irq_priority(desc, priority);
  
-p->desc = desc;

-res = 0;
-
-out:
-vgic_unlock_rank(v_target, rank, flags);
-
-return res;
+return 0;
  }
  
  /* This function only works with SPIs for now */

  int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc)
  {
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-struct pending_irq *p = irq_to_pending(v_target, virq);
-unsigned long flags;
+int ret;
  
  ASSERT(spin_is_locked(>lock));

  ASSERT(test_bit(_IRQ_GUEST, >status));
-ASSERT(p->desc == desc);
  ASSERT(!is_lpi(virq));
  
-vgic_lock_rank(v_target, rank, flags);

-
  if ( 

Re: [Xen-devel] [PATCH 7/7] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

[Julien Grall]

Hi,

On 02/06/2018 04:36 PM, Volodymyr Babchuk wrote:

On 5 February 2018 at 15:20, Julien Grall  wrote:

The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
hardening the branch predictor. So we want the handling to be as fast as
possible.

As the mitigation is applied on every guest exit, we can check for the
call before saving all the context and return very early.

Have you tried any benchmarks? How big is the benefit?


I have benchmarked but I can't share the result. I can give you an idea 
on how this could benefits Xen.


Linux will call the workaround on every context switch between process. 
So imagine for each context switch, you have will enter in Xen and in 
the following order:

1) enter Xen
2) apply the workaround which means calling EL3.
3) save part of the guest context
4) call enter_hypervisor_head that will sync the vGIC state
5) detect you actually call SMCCC_ARCH_WORKAROUND_1 that will do nothing
	6) call leave_hypervisor_tail that will sync back the vGIC state and 
execute softirq (that could reschedule the vCPU)

7) restore the guest context
8) return to the guest

So effectively, instead of executing hundreds (if not thousands) 
instructions each time, you will end up only executing less than 50 
instructions.




For now, only provide a fast path for HVC64 call. Because the code rely
on 2 registers, x0 and x1 are saved in advanced.

Is there a typo? Should it be "advance"?



Signed-off-by: Julien Grall 

---
 guest_sync only handle 64-bit guest, so I have only implemented the
 64-bit side for now. We can discuss whether it is useful to
 implement it for 32-bit guests.

 We could also consider to implement the fast path for SMC64,
 althought a guest should always use HVC.

I can imagine a guest that know nothing about virtualization and use
SMC as a conduit. But I can't provide real world example, thou.


Someone can easily send a follow-up patch for that if it is deemed 
necessary.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Alexey G]

On Tue, 6 Feb 2018 17:21:19 +
Igor Druzhinin  wrote:
>On 06/02/18 17:08, Alexey G wrote:
>> The major concern here is the possiblity of SMI being triggered _not_
>> by some specific I/O port access. Primarily, if it actually was a
>> periodic SMI.
>> 
>> If the actual SMI source is not related to some place in the NMI
>> handler code but was eg. due to some SMI timer, lowering NMI watchdog
>> frequency might not fix the issue completely, but lower its
>> reproducibility (perhaps to some very rare occurrences). So it's
>> better be sure what was the real source of SMI.
>>   
>
>This *is* related to this instruction - it was confirmed empirically.
>Removing this instruction stops SMIs from occurring and effectively
>removes the issue leaving the frequency unchanged.

Hmm, it would be interesting to know for what evil purpose does it need
to trap I/O port 61h.
BTW, on which motherboard model the issue was reproduced?

>> 2. According to the code, it looks like NMI status reading happens
>> while NMIs are still blocked -- this means that SMI handler must
>> exec IRET by itself to reset NMI blocking state -- again, this is
>> possible (eg. in unreal->protmode switching code), but not likely.
>>   
>
>According to SDM one NMI might be pending while taken in SMI mode (see
>ch. 34.8). This is actually even true if NMI comes while servicing
>another NMI. So when we return to the NMI handler from SMI and finish
>it properly the next one appears immediately.

If the SMI handler doesn't mess up with NMI blocking state, it
means that SMI handler processes every reading of port 61h longer than a
watchdog NMI period duration... which is quite long. Motherboard vendor
did something very wrong with I/O trap handling in the SMI handler code
if it takes so much.

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

Re: [Xen-devel] [PATCH 5/7] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

On 02/06/2018 04:23 PM, Volodymyr Babchuk wrote:

Hi,


Hi,


On 5 February 2018 at 15:20, Julien Grall  wrote:

SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
(CVE-2017-5715).

If the hypervisor has some mitigation for this issue, report that we
deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
workaround on every guest exit.

Just to be sure: is there some way to disable this workaround?


In which context? If the platform does not have any processor affected 
by variant 2, then the workaround will not be enabled.


In case of Linux, this workaround will only be called on affected 
processors.







Signed-off-by: Julien Grall 
---
  xen/arch/arm/vsmc.c | 22 --
  xen/include/asm-arm/smccc.h |  6 ++
  2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index a708aa5e81..144a1cd761 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -18,6 +18,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
  return true;

  case ARM_SMCCC_ARCH_FEATURES_FID:
-/* Nothing supported yet */
-set_user_reg(regs, 0, -1);
+{
+uint32_t arch_func_id = get_user_reg(regs, 1);
+int ret = -1;

I think that register_t will suit better in this case.


Well no. The return in the spec is int32 and will fit in w0. register_t 
is either 32-bit or 64-bit. So int is the right type here.





+
+switch ( arch_func_id )
+{
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
+ret = 0;
+break;
+}
+
+set_user_reg(regs, 0, ret);
+
+return true;
+}
+
+case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
+/* No return value */
  return true;
  }

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
index 431389c118..b790fac17c 100644
--- a/xen/include/asm-arm/smccc.h
+++ b/xen/include/asm-arm/smccc.h
@@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t funcid)
 ARM_SMCCC_OWNER_ARCH,\
 0x1)

+#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
+ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
+  ARM_SMCCC_CONV_32,\
+  ARM_SMCCC_OWNER_ARCH, \
+  0x8000)
+
  /* Only one error code defined in SMCCC */
  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)

--
2.11.0


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


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Wei Liu]

On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
> >   if (libxl__device_pci_destroy_all(gc, domid) < 0)
> >   LOGD(ERROR, domid, "Pci shutdown failed");
> >   rc = xc_domain_pause(ctx->xch, domid);
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 2cfe4c08a7..c398b6a6b8 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -4424,6 +4424,8 @@ static inline bool libxl__string_is_default(char **s)
> >   _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
> >   libxl_static_shm *sshm, int len);
> > +_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
> > +
> >   _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
> > libxl_static_shm *sshms, int len);
> >   _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
> > diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
> > index 562f46f299..1bf4d4c2dc 100644
> > --- a/tools/libxl/libxl_sshm.c
> > +++ b/tools/libxl/libxl_sshm.c
> > @@ -86,6 +86,112 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t 
> > domid,
> >   return 0;
> >   }
> > +/* Decrease the refcount of an sshm. When refcount reaches 0,
> 
> NIT: Libxl coding style regarding the comment seems to be uncleared (Ian,
> Wei?). But I feel keep /* and */ in separate line is nicer.

I don't have an opinion here.

> 
> > + * clean up the whole sshm path.
> > + */
> > +static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
> > +   const char *sshm_path)
> > +static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
> > +  uint32_t domid, const char *id, bool 
> > isretry)
> > +{
> > +const char *slave_path, *begin_str, *end_str;
> > +uint64_t begin, end;
> > +
> > +slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
> > +
> > +begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
> > +end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
> > +begin = strtoull(begin_str, NULL, 16);
> > +end = strtoull(end_str, NULL, 16);
> > +
> > +/* Avoid calling do_unmap many times in case of xs transaction retry */
> > +if (!isretry)
> > +libxl__sshm_do_unmap(gc, domid, id, begin, end);
> 
> IHMO, by unmapping the regions in middle of the transaction, you increase
> the potential failure of it. I would move that out of the transaction path.
> 
> I would be interested to hear the opinion of the tools maintainers here.
> 

If you move the unmap after the loop you create a window in which
the pages are still mapped but the toolstack thinks they are unmapped.

While the code as-is now makes sure (assuming no error in unmap) the
pages are unmapped no later than the transaction is committed. I think
this can be done by moving unmap before the transaction.

Zhongze, do you think the unmap must be done inside the loop? What kind
of invariants do you have in mind?

Then there is the question of "what do we do if unmap fails". Honestly I
don't have an answer. It seems rather screwed up in that case and I
doubt there is much libxl can do to rectify things.

Wei.

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

Re: [Xen-devel] [PATCH 4/7] xen/arm: vsmc: Implement SMCCC 1.1

[Julien Grall]

Hi,

On 02/06/2018 04:18 PM, Volodymyr Babchuk wrote:

On 5 February 2018 at 15:20, Julien Grall  wrote:

The new SMC Calling Convention (v1.1) allows for a reduced overhead when
calling into the firmware, and provides a new feature discovery
mechanism. See ARM DEN 00070A.

Сould you please use also a human-readable document name? I remember
that I read "Firmware interfaces for mitigating CVE-2017-5715", but I
can't remember what is ARM DEN 00070A about.


The reason I am using ARM DEN 0070A is because the name does not give 
you revision of the specification. So you can't know whether you use rev 
A or B. As new revision may introduce/change behavior, this is very 
helpful to know which specific revision that was used to write the code.


It is also much easier to find on the web the identifier than the title 
as you directly reach to a given version


Anyway, I can mention the full name of the specification in the commit.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

[Wei Liu]

On Tue, Feb 06, 2018 at 05:30:50PM +, Julien Grall wrote:
> 
> 
> On 02/06/2018 03:59 PM, Zhongze Liu wrote:
> > Hi Julien,
> 
> Hi,
> 
> 
> > 2018-02-06 21:07 GMT+08:00 Julien Grall :
> > > Hi,
> > > 
> > > On 01/30/2018 05:50 PM, Zhongze Liu wrote:
> > > > 
> > > > Add libxl__sshm_add to map shared pages from one DomU to another, The
> > > > mapping
> > > > process involves the follwing steps:
> > 
> > [...]
> > 
> > > > +
> > > > +/* Set default values for libxl_static_shm */
> > > > +int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
> > > > +   libxl_static_shm *sshm)
> > > > +{
> > > > +int rc;
> > > > +
> > > > +if (sshm->role == LIBXL_SSHM_ROLE_UNKNOWN)
> > > > +sshm->role = LIBXL_SSHM_ROLE_SLAVE;
> > > > +if (sshm->prot == LIBXL_SSHM_PROT_UNKNOWN)
> > > > +sshm->prot = LIBXL_SSHM_PROT_RW;
> > > 
> > > 
> > > What is the purpose of {ROLE,PROT}_UNKNOWN if you default it resp. to
> > > ROLE_SLAVE and PROT_RW.  Would not it be easier to just drop them?
> > 
> > The *_UNKNOWN values are used by the libxlu code to check whether a specific
> > option was set more than once.
> 
> AFAIK, a toolstack is free to not use libxlu. Someone may implement their
> own toolstack on top of libxl and may use ROLE_UNKNOWN by mistake.

Yes.

> 
> > Without the default *_UNKNOWN value, I will not
> > be able to judge if, say, role is set to 'slave' by the user or not,
> > and therefore, if I
> > see the user setting role to 'master', I won't be able to tell if role
> > is specified twice
> > or not.
> > 
> > I think treating re-specification of options as errors will be good
> > for the users.
> 
> In that case, you should treat that as an error for everyone and not only
> xl. This would avoid confusion on other toolstack.
> 
> > 
> > [...]
> > 
> > > > +
> > > > +/*   libxl__sshm_do_map -- map pages into slave's physmap
> > > > + *
> > > > + *   This functions maps
> > > > + * master gfn: [@msshm->begin + @sshm->offset, @msshm->end +
> > > > @sshm->offset)
> > > > + *   into
> > > > + * slave gfn: [@sshm->begin, @sshm->end)
> > > > + *
> > > > + *   The gfns of the pages that are successfully mapped will be stored
> > > > + *   in @mapped, and the number of the gfns will be stored in @nmapped.
> > > > + *
> > > > + *   The caller have to guarentee that sshm->begin < sshm->end and all
> > > > the
> > > 
> > > 
> > > s/have to/has to/ I think.
> > > s/guarentee/guarantee/
> > > 
> > > > + *   values are page-aligned.
> > > 
> > > 
> > > Hmmm, I don't see the alignement check in libxl. So do you rely on the
> > > toolstack to do it?
> > 
> > Yes, This was done in libxlu_sshm.c.
> 
> Same remark as above regarding libxlu. Note that I am maintaining the tools.
> Ian and Wei may have a different opinion here.
> 

Please move the check to libxl.

Wei.

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

Re: [Xen-devel] [PATCH 3/7] xen/arm: vpsci: Add support for PSCI 1.1

[Julien Grall]

On 02/06/2018 04:07 PM, Volodymyr Babchuk wrote:

Hi,


Hi Volodymyr,

Thank you for the review.


On 5 February 2018 at 15:20, Julien Grall  wrote:

At the moment, Xen provides virtual PSCI interface compliant with 0.1
and 0.2. Since them, the specification has been updated and the latest
version is 1.1 (see ARM DEN 0022D).

 From an implementation point of view, only PSCI_FEATURES is mandatory.
The rest is optional and can be left unimplemented for now.

At the same time, the compatible for PSCI node have been updated to
expose "arm,psci-1.0".

Signed-off-by: Julien Grall 
Cc: Wei Liu 
Cc: Ian Jackson 
Cc: mirela.simono...@aggios.com

---
 We may want to provide a way for the toolstack to specify a PSCI
 version. This could be useful if a guest is expecting a given
 version.
---
  tools/libxl/libxl_arm.c  |  3 ++-
  xen/arch/arm/domain_build.c  |  1 +
  xen/arch/arm/vpsci.c | 34 +-
  xen/include/asm-arm/perfc_defn.h |  1 +
  xen/include/asm-arm/psci.h   |  1 +
  xen/include/asm-arm/vpsci.h  |  2 +-
  6 files changed, 39 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index 3e46554301..86f59c0d80 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -410,7 +410,8 @@ static int make_psci_node(libxl__gc *gc, void *fdt)
  res = fdt_begin_node(fdt, "psci");
  if (res) return res;

-res = fdt_property_compat(gc, fdt, 2, "arm,psci-0.2","arm,psci");
+res = fdt_property_compat(gc, fdt, 3, "arm,psci-1.0",
+  "arm,psci-0.2", "arm,psci");
  if (res) return res;

  res = fdt_property_string(fdt, "method", "hvc");
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 155c952349..941688a2ce 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -637,6 +637,7 @@ static int make_psci_node(void *fdt, const struct 
dt_device_node *parent)
  {
  int res;
  const char compat[] =
+"arm,psci-1.0""\0"
  "arm,psci-0.2""\0"
  "arm,psci";

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 17dab42cf4..025250a119 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -115,7 +115,7 @@ static int32_t do_psci_cpu_off(uint32_t power_state)

  static uint32_t do_psci_0_2_version(void)
  {
-return PSCI_VERSION(0, 2);
+return PSCI_VERSION(1, 0);
  }

I'm confused a bit with the versions. In the commit message you
mentioned version 1.1. But there you return version 1,0 from a
function named do_psci_0_2_version().


So the function names are implemented based on when they were added in 
the specification. This makes slightly easier if we ever decide to 
expose 0.2 (or 1.0/1.1) only PSCI in the guest.


Also, good catch for the returned version. I first implemented the patch 
for 1.0 and forgot to update it.






  static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
@@ -199,6 +199,28 @@ static void do_psci_0_2_system_reset(void)
  domain_shutdown(d,SHUTDOWN_reboot);
  }

+static int32_t do_psci_1_0_features(uint32_t psci_func_id)
+{
+switch ( psci_func_id )
+{
+case PSCI_0_2_FN32_PSCI_VERSION:
+case PSCI_0_2_FN32_CPU_OFF:
+case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
+case PSCI_0_2_FN32_SYSTEM_OFF:
+case PSCI_0_2_FN32_SYSTEM_RESET:
+case PSCI_0_2_FN32_CPU_ON:
+case PSCI_0_2_FN64_CPU_ON:
+case PSCI_0_2_FN32_CPU_SUSPEND:
+case PSCI_0_2_FN64_CPU_SUSPEND:
+case PSCI_0_2_FN32_AFFINITY_INFO:
+case PSCI_0_2_FN64_AFFINITY_INFO:
+case PSCI_1_0_FN32_PSCI_FEATURES:

Are those functions sorted in a some order?


They were meant to be sorted by the function ID. Thought it looks like 
it is not the case, I will fix that in the next version.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86: reduce Meltdown band-aid IPI overhead

[George Dunlap]

On 01/26/2018 12:07 PM, Jan Beulich wrote:
> In case we can detect single-threaded guest processes (by checking
> whether we can account for all root page table uses locally on the vCPU
> that's running), there's no point in issuing a sync IPI upon an L4 entry
> update, as no other vCPU of the guest will have that page table loaded.
> 
> Signed-off-by: Jan Beulich 

Looks good to me, and I think the summation is pretty clear:

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

[Julien Grall]

On 02/06/2018 03:59 PM, Zhongze Liu wrote:

Hi Julien,


Hi,



2018-02-06 21:07 GMT+08:00 Julien Grall :

Hi,

On 01/30/2018 05:50 PM, Zhongze Liu wrote:


Add libxl__sshm_add to map shared pages from one DomU to another, The
mapping
process involves the follwing steps:


[...]


+
+/* Set default values for libxl_static_shm */
+int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
+   libxl_static_shm *sshm)
+{
+int rc;
+
+if (sshm->role == LIBXL_SSHM_ROLE_UNKNOWN)
+sshm->role = LIBXL_SSHM_ROLE_SLAVE;
+if (sshm->prot == LIBXL_SSHM_PROT_UNKNOWN)
+sshm->prot = LIBXL_SSHM_PROT_RW;



What is the purpose of {ROLE,PROT}_UNKNOWN if you default it resp. to
ROLE_SLAVE and PROT_RW.  Would not it be easier to just drop them?


The *_UNKNOWN values are used by the libxlu code to check whether a specific
option was set more than once.


AFAIK, a toolstack is free to not use libxlu. Someone may implement 
their own toolstack on top of libxl and may use ROLE_UNKNOWN by mistake.



Without the default *_UNKNOWN value, I will not
be able to judge if, say, role is set to 'slave' by the user or not,
and therefore, if I
see the user setting role to 'master', I won't be able to tell if role
is specified twice
or not.

I think treating re-specification of options as errors will be good
for the users.


In that case, you should treat that as an error for everyone and not 
only xl. This would avoid confusion on other toolstack.




[...]


+
+/*   libxl__sshm_do_map -- map pages into slave's physmap
+ *
+ *   This functions maps
+ * master gfn: [@msshm->begin + @sshm->offset, @msshm->end +
@sshm->offset)
+ *   into
+ * slave gfn: [@sshm->begin, @sshm->end)
+ *
+ *   The gfns of the pages that are successfully mapped will be stored
+ *   in @mapped, and the number of the gfns will be stored in @nmapped.
+ *
+ *   The caller have to guarentee that sshm->begin < sshm->end and all
the



s/have to/has to/ I think.
s/guarentee/guarantee/


+ *   values are page-aligned.



Hmmm, I don't see the alignement check in libxl. So do you rely on the
toolstack to do it?


Yes, This was done in libxlu_sshm.c.


Same remark as above regarding libxlu. Note that I am maintaining the 
tools. Ian and Wei may have a different opinion here.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/7] libxl: introduce a new structure to represent static shared memory regions

[Julien Grall]

On 02/06/2018 04:06 PM, Zhongze Liu wrote:

Hi,


Hi,



2018-02-06 23:46 GMT+08:00 Julien Grall :

Hi,

On 02/06/2018 03:41 PM, Zhongze Liu wrote:


Thanks for reviewing.

2018-02-06 19:27 GMT+08:00 Julien Grall :


Hi,

On 01/30/2018 05:50 PM, Zhongze Liu wrote:



Add a new structure to the IDL familiy to represent static shared memory
regions



[...]


+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),




We might want to store the size rather than the end. This would allow us
to
cover region up to the address 2^64-1.

Also, this would make clearer whether end is included in the region or
not.



I think making the range inclusive and documenting it would have the
same effect.
But I'm not sure which syntax is more friendly to the users. What do you
think?



You would still run into some problem. Indeed LIBX_SSHM_RANGE_UNKNOWN is
defined as UINT64_MAX. So how would you differentiate them?


But saying inclusive, I was actually trying to say "including the page
that begins at @end", so


Which is quite confusing. Usually when I see a range, I assume that the 
end will be the actual end. Not PAGE_ALIGN(end).



the only possibility when  LIBXL_SSHM_RANGE_UNKNOWN would be a valid value for
@end is when the page granularity is 1byte, which, I think, is not
very likely to happen.

But soon I find this might lead to more confusion. Now I agree with
you that we should use
the begin/size syntax instead of the current one.
Yes, begin/size is straightforward. There are no way to lead to map one 
less (or extra) page by confusion.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 06/02/18 17:08, Alexey G wrote:
> On Tue, 6 Feb 2018 14:21:12 +
> Andrew Cooper  wrote:
> 
>> On 06/02/18 03:10, Alexey G wrote:
>>> I/O port 61h normally is not emulated by SMI legacy kbd handling code
>>> in BIOS, only ports like 60h, 64h, etc.
>>> Contrary to USB legacy emulation, it has to intercept port 61h via a
>>> different approach -- generic SMI I/O trap, which is not common (at
>>> least it was) to use by BIOSes... although it is possible as EFI
>>> interface and code for this is available. The assumption about port
>>> 61h being trapped by the SMI handler must be explicitly confirmed by
>>> checking I/O Trap control regs in the RCBA region.
>>>
>>> If I/O trap regs won't show an active I/O trap on I/O port 61h -- the
>>> root cause might be different (might even be related to stuff like
>>> NMI2SMI logic).
>>>
>>> If the problem is actually due to NMI handler being preempted by
>>> another NMI which occurred after (a long) execution of triggered SMI
>>> handler, it might be better to do all sensitive stuff before
>>> re-enabling NMIs by IRET in the NMI handler.  
>>
>> The problem is that the SMI handler executes enough instructions to
>> trigger another NMI (which is based on the retired instruction count),
>> which gets delivered once the SMI handler returns, and servicing the
>> NMI triggers a new SMI, which triggers a new NMI.  This is why the
>> system stalls.
>>
>> I'll leave the how/why port 0x61 is trapping to SMI to Igor, but it is
>> only a secondary concern here.  We cannot reasonably have the watchdog
>> able to trip because of exclusively SMI activity, or we'll potentially
>> livelock anywhere.
> 
> The major concern here is the possiblity of SMI being triggered _not_
> by some specific I/O port access. Primarily, if it actually was a
> periodic SMI.
> 
> If the actual SMI source is not related to some place in the NMI
> handler code but was eg. due to some SMI timer, lowering NMI watchdog
> frequency might not fix the issue completely, but lower its
> reproducibility (perhaps to some very rare occurrences). So it's better
> be sure what was the real source of SMI.
> 

This *is* related to this instruction - it was confirmed empirically.
Removing this instruction stops SMIs from occurring and effectively
removes the issue leaving the frequency unchanged.

> There are 2 weak spots in the analysis:
> 
> 1. Triggering SMI by reading I/O port 61h -- intercepting the port 61h
> is non-typical behavior for BIOS (unlike 60h/64h)
> 

Apparently, it is now.

> 2. According to the code, it looks like NMI status reading happens while
> NMIs are still blocked -- this means that SMI handler must exec IRET
> by itself to reset NMI blocking state -- again, this is possible (eg.
> in unreal->protmode switching code), but not likely.
> 

According to SDM one NMI might be pending while taken in SMI mode (see
ch. 34.8). This is actually even true if NMI comes while servicing
another NMI. So when we return to the NMI handler from SMI and finish it
properly the next one appears immediately.

Igor

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

Re: [Xen-devel] [PATCH RFC 2/8] public/io/netif: add directory for backend parameters

[Wei Liu]

(Three months after you sent this, sorry...)

On Mon, Nov 06, 2017 at 12:33:06PM +, Joao Martins wrote:
> On Mon, Nov 06, 2017 at 10:33:59AM +, Paul Durrant wrote:
> > > -Original Message-
> > > From: Joao Martins [mailto:joao.m.mart...@oracle.com]
> > > Sent: 02 November 2017 18:06
> > > To: Xen Development List 
> > > Cc: Joao Martins ; Konrad Rzeszutek Wilk
> > > ; Paul Durrant ; Wei Liu
> > > 
> > > Subject: [PATCH RFC 2/8] public/io/netif: add directory for backend
> > > parameters
> > > 
> > > The proposed directory provides a mechanism for tools to control the
> > > maximum feature set of the device being provisioned by backend.
> > > The parameters/features include offloading features, number of
> > > queues etc.
> > > 
> > > Signed-off-by: Joao Martins 
> > > ---
> > >  xen/include/public/io/netif.h | 16 
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/xen/include/public/io/netif.h b/xen/include/public/io/netif.h
> > > index 2454448baa..a412e4771d 100644
> > > --- a/xen/include/public/io/netif.h
> > > +++ b/xen/include/public/io/netif.h
> > > @@ -161,6 +161,22 @@
> > >   */
> > > 
> > >  /*
> > > + * The directory "require" maybe be created in backend path by tools
> > > + * domain to override the maximum feature set that backend provides to
> > > the
> > > + * frontend. The children entries within this directory are features 
> > > names
> > > + * and the correspondent values that should be used backend as defaults
> > > e.g.:
> > > + *
> > > + * /local/domain/X/backend///require
> > > + * /local/domain/X/backend///require/multi-queue-
> > > max-queues = "2"
> > > + * /local/domain/X/backend///require/feature-no-csum-
> > > offload = "1"
> > > + *
> > > + * In the example above, network backend will negotiate up to a maximum
> > > of
> > > + * two queues with frontend plus disabling IPv4 checksum offloading.
> > > + *
> > > + * This directory and its children entries shall only be visible to the 
> > > backend.
> > > + */
> > > +
> > 
> > What should happen if the toolstack sets something in 'require' that
> > the backend cannot provide? I don't see anything in your RFC patches
> > to check that the backend has responded appropriately to the keys.
> 
> Hmm, you're right that this RFC doesn't handle that properly - but for the
> ones the backend provide I had suggested (albeit not implemented here)
> back in the other thread that we could compare the values of feature in
> "require" with the one announced to the frontend. But well this wouldn't
> cover the non-provided ones, and possibly would fall a bit as a hack.
> 
> I could change the format of the entries within "require"
> directory to be e.g. "- = " and the
> acknowledgement entry would come in the form "-status
> = ". Consequently the lack of a "-status" entry would
> have a stronger semantic i.e. unsupported and ignored. The toolstack then 
> would have
> means to check whether the feature was really succesfull set as desired
> or not. But then one question comes to mind: should the backend be
> prevented to init in the event that the features requested fail to be
> set? In which case uevent (on Linux) isn't triggered and xenbus state doesn't
> get changed and toolstack would fail with timeout later on.
> 

I think the backend should not proceed if it can't meet the
requirements. But to be clear I also don't think the timeout behaviour
should be used to determine if the setting is successful because it is
asking other part of the system to pick up the slack and system
administrators would be left in the dark (unless there is easily
accessible message that can be obtained by libxl to return to system
administrators).

> Also, a nice thing of this stuff is that we could also use this to set
> set backend implementation specific parameters that are not
> described or relevant in I/O specs. But then I start to wonder where would
> be the correct place for backends to specify its maximum feature set of
> changeable entries? Maybe:
> 
> /local/domain/X/backend/vif/features/
> /local/domain/X/backend/vif/features/-desc = "Description
> of "

No idea. I'm very bad at naming things.

Wei.

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

[Xen-devel] [PATCH v5 7/8] ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq

[Andre Przywara]

The functions to actually populate a list register were accessing
the VGIC internal pending_irq struct, although they should be abstracting
from that.
Break the needed information down to remove the reference to pending_irq
from gic-v[23].c.

Signed-off-by: Andre Przywara 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/gic-v2.c | 14 +++---
 xen/arch/arm/gic-v3.c | 12 ++--
 xen/arch/arm/gic-vgic.c   |  3 ++-
 xen/include/asm-arm/gic.h |  4 ++--
 xen/include/asm-arm/irq.h |  3 +++
 5 files changed, 20 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 511c8d7294..2b271ba322 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -428,8 +428,8 @@ static void gicv2_disable_interface(void)
 spin_unlock();
 }
 
-static void gicv2_update_lr(int lr, const struct pending_irq *p,
-unsigned int state)
+static void gicv2_update_lr(int lr, unsigned int virq, uint8_t priority,
+unsigned int hw_irq, unsigned int state)
 {
 uint32_t lr_reg;
 
@@ -437,12 +437,12 @@ static void gicv2_update_lr(int lr, const struct 
pending_irq *p,
 BUG_ON(lr < 0);
 
 lr_reg = (((state & GICH_V2_LR_STATE_MASK) << GICH_V2_LR_STATE_SHIFT)  |
-  ((GIC_PRI_TO_GUEST(p->priority) & GICH_V2_LR_PRIORITY_MASK)
- << GICH_V2_LR_PRIORITY_SHIFT) |
-  ((p->irq & GICH_V2_LR_VIRTUAL_MASK) << 
GICH_V2_LR_VIRTUAL_SHIFT));
+  ((GIC_PRI_TO_GUEST(priority) & GICH_V2_LR_PRIORITY_MASK)
+  << GICH_V2_LR_PRIORITY_SHIFT) |
+  ((virq & GICH_V2_LR_VIRTUAL_MASK) << GICH_V2_LR_VIRTUAL_SHIFT));
 
-if ( p->desc != NULL )
-lr_reg |= GICH_V2_LR_HW | ((p->desc->irq & GICH_V2_LR_PHYSICAL_MASK )
+if ( hw_irq != INVALID_IRQ )
+lr_reg |= GICH_V2_LR_HW | ((hw_irq & GICH_V2_LR_PHYSICAL_MASK )
<< GICH_V2_LR_PHYSICAL_SHIFT);
 
 writel_gich(lr_reg, GICH_LR + lr * 4);
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 072345c6f9..25c30bb9ea 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -966,8 +966,8 @@ static void gicv3_disable_interface(void)
 spin_unlock();
 }
 
-static void gicv3_update_lr(int lr, const struct pending_irq *p,
-unsigned int state)
+static void gicv3_update_lr(int lr, unsigned int virq, uint8_t priority,
+unsigned int hw_irq, unsigned int state)
 {
 uint64_t val = 0;
 
@@ -983,11 +983,11 @@ static void gicv3_update_lr(int lr, const struct 
pending_irq *p,
 if ( current->domain->arch.vgic.version == GIC_V3 )
 val |= GICH_LR_GRP1;
 
-val |= ((uint64_t)p->priority & 0xff) << GICH_LR_PRIORITY_SHIFT;
-val |= ((uint64_t)p->irq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT;
+val |= (uint64_t)priority << GICH_LR_PRIORITY_SHIFT;
+val |= ((uint64_t)virq & GICH_LR_VIRTUAL_MASK) << GICH_LR_VIRTUAL_SHIFT;
 
-   if ( p->desc != NULL )
-   val |= GICH_LR_HW | (((uint64_t)p->desc->irq & GICH_LR_PHYSICAL_MASK)
+   if ( hw_irq != INVALID_IRQ )
+   val |= GICH_LR_HW | (((uint64_t)hw_irq & GICH_LR_PHYSICAL_MASK)
<< GICH_LR_PHYSICAL_SHIFT);
 
 gicv3_ich_write_lr(lr, val);
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 72a904bbeb..d273863556 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -38,7 +38,8 @@ static inline void gic_set_lr(int lr, struct pending_irq *p,
 
 clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status);
 
-gic_hw_ops->update_lr(lr, p, state);
+gic_hw_ops->update_lr(lr, p->irq, p->priority,
+  p->desc ? p->desc->irq : INVALID_IRQ, state);
 
 set_bit(GIC_IRQ_GUEST_VISIBLE, >status);
 clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 1a142d6e9f..497f195bc1 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -344,8 +344,8 @@ struct gic_hw_operations {
 /* Disable CPU physical and virtual interfaces */
 void (*disable_interface)(void);
 /* Update LR register with state and priority */
-void (*update_lr)(int lr, const struct pending_irq *pending_irq,
-  unsigned int state);
+void (*update_lr)(int lr, unsigned int virq, uint8_t priority,
+  unsigned int hw_irq, unsigned int state);
 /* Update HCR status register */
 void (*update_hcr_status)(uint32_t flag, bool set);
 /* Clear LR register */
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index abc8f06a13..0d110ecb08 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -31,6 +31,9 @@ struct arch_irq_desc {
 /* LPIs are always numbered starting at 8192, so 0 is a good invalid case. */
 #define 

[Xen-devel] [PATCH v5 8/8] ARM: make nr_irqs a constant

[Andre Przywara]

On ARM the maximum number of IRQs is a constant, but we share it being
a variable to match x86. Since we are not supposed to alter it, let's
mark it as "const" to avoid accidental change.

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

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 62103a20e3..29af10e82c 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 
-unsigned int __read_mostly nr_irqs = NR_IRQS;
+const unsigned int nr_irqs = NR_IRQS;
 
 static unsigned int local_irqs_type[NR_LOCAL_IRQS];
 static DEFINE_SPINLOCK(local_irqs_type_lock);
diff --git a/xen/include/asm-arm/irq.h b/xen/include/asm-arm/irq.h
index 0d110ecb08..9d55e9b122 100644
--- a/xen/include/asm-arm/irq.h
+++ b/xen/include/asm-arm/irq.h
@@ -34,7 +34,7 @@ struct arch_irq_desc {
 /* This is a spurious interrupt ID which never makes it into the GIC code. */
 #define INVALID_IRQ 1023
 
-extern unsigned int nr_irqs;
+extern const unsigned int nr_irqs;
 #define nr_static_irqs NR_IRQS
 #define arch_hwdom_irqs(domid) NR_IRQS
 
-- 
2.14.1


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

[Xen-devel] [PATCH v5 2/8] ARM: VGIC: split gic.c to observe hardware/virtual GIC separation

[Andre Przywara]

Currently gic.c holds code to handle hardware IRQs as well as code to
bridge VGIC requests to the GIC virtualization hardware.
Despite being named gic.c, this file reaches into the VGIC and uses data
structures describing virtual IRQs.
To improve abstraction, move the VGIC functions into a separate file,
so that gic.c does what it says on the tin.

Signed-off-by: Andre Przywara 
Acked-by: Julien Grall 
---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/gic-vgic.c   | 396 ++
 xen/arch/arm/gic.c| 363 +-
 xen/include/asm-arm/gic.h |   3 +
 4 files changed, 402 insertions(+), 361 deletions(-)
 create mode 100644 xen/arch/arm/gic-vgic.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 30a2a6500a..41d7366527 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -16,6 +16,7 @@ obj-y += domain_build.o
 obj-y += domctl.o
 obj-$(EARLY_PRINTK) += early_printk.o
 obj-y += gic.o
+obj-y += gic-vgic.o
 obj-y += gic-v2.o
 obj-$(CONFIG_HAS_GICV3) += gic-v3.o
 obj-$(CONFIG_HAS_ITS) += gic-v3-its.o
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
new file mode 100644
index 00..74d8ea7c96
--- /dev/null
+++ b/xen/arch/arm/gic-vgic.c
@@ -0,0 +1,396 @@
+/*
+ * xen/arch/arm/gic-vgic.c
+ *
+ * ARM Generic Interrupt Controller virtualization support
+ *
+ * Tim Deegan 
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) - 
1))
+
+#undef GIC_DEBUG
+
+static void gic_update_one_lr(struct vcpu *v, int i);
+
+static inline void gic_set_lr(int lr, struct pending_irq *p,
+  unsigned int state)
+{
+ASSERT(!local_irq_is_enabled());
+
+clear_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status);
+
+gic_hw_ops->update_lr(lr, p, state);
+
+set_bit(GIC_IRQ_GUEST_VISIBLE, >status);
+clear_bit(GIC_IRQ_GUEST_QUEUED, >status);
+p->lr = lr;
+}
+
+static inline void gic_add_to_lr_pending(struct vcpu *v, struct pending_irq *n)
+{
+struct pending_irq *iter;
+
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+if ( !list_empty(>lr_queue) )
+return;
+
+list_for_each_entry ( iter, >arch.vgic.lr_pending, lr_queue )
+{
+if ( iter->priority > n->priority )
+{
+list_add_tail(>lr_queue, >lr_queue);
+return;
+}
+}
+list_add_tail(>lr_queue, >arch.vgic.lr_pending);
+}
+
+void gic_remove_from_lr_pending(struct vcpu *v, struct pending_irq *p)
+{
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+list_del_init(>lr_queue);
+}
+
+void gic_raise_inflight_irq(struct vcpu *v, unsigned int virtual_irq)
+{
+struct pending_irq *n = irq_to_pending(v, virtual_irq);
+
+/* If an LPI has been removed meanwhile, there is nothing left to raise. */
+if ( unlikely(!n) )
+return;
+
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+/* Don't try to update the LR if the interrupt is disabled */
+if ( !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+return;
+
+if ( list_empty(>lr_queue) )
+{
+if ( v == current )
+gic_update_one_lr(v, n->lr);
+}
+#ifdef GIC_DEBUG
+else
+gdprintk(XENLOG_DEBUG, "trying to inject irq=%u into d%dv%d, when it 
is still lr_pending\n",
+ virtual_irq, v->domain->domain_id, v->vcpu_id);
+#endif
+}
+
+/*
+ * Find an unused LR to insert an IRQ into, starting with the LR given
+ * by @lr. If this new interrupt is a PRISTINE LPI, scan the other LRs to
+ * avoid inserting the same IRQ twice. This situation can occur when an
+ * event gets discarded while the LPI is in an LR, and a new LPI with the
+ * same number gets mapped quickly afterwards.
+ */
+static unsigned int gic_find_unused_lr(struct vcpu *v,
+   struct pending_irq *p,
+   unsigned int lr)
+{
+unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned long *lr_mask = (unsigned long *) _cpu(lr_mask);
+struct gic_lr lr_val;
+
+ASSERT(spin_is_locked(>arch.vgic.lock));
+
+if ( unlikely(test_bit(GIC_IRQ_GUEST_PRISTINE_LPI, >status)) )
+{
+unsigned int used_lr;
+
+for_each_set_bit(used_lr, lr_mask, nr_lrs)
+{
+

[Xen-devel] [PATCH v5 0/8] ARM: VGIC/GIC separation cleanups

[Andre Przywara]

Hi,

a minor update over the last post. Added tags, extended one commit
message and added an error return in patch 5/8.

Please test and apply.

Cheers,
Andre

Changelog v4->v5
01: unchanged
02: reordered headers, added tag
03, 04: unchanged
05: return an error if irq_desc does not match, extended commit message
06: added tag
07, 08: unchanged

Changelog v3->v4
01: added tags
02: remove extra header files, move per-CPU variable into gic.h
03, 04: unchanged
05: rework locking, rework dropping hardware IRQ connection
06: add ASSERT
07: unchanged
08: removed read_mostly attribute

Changelog v2->v3:
01: reworked
02: rebased to match staging, added tag
03, 07: added tag
08: new, as suggested by Julien


By the original VGIC design, Xen differentiates between the actual VGIC
emulation on one hand and the GIC hardware accesses on the other.
It seems there were some deviations from that scheme (over time?), so at
the moment we end up happily accessing VGIC specific data structures
like struct pending_irq and struct vgic_irq_rank from pure GIC files
like gic.c or even irq.c (try: git grep -l struct\ pending_irq xen/arch/arm).
But any future VGIC rework will depend on a clean separation, so this
series tries to clean this up.
After this series there are no more references to VGIC structures from
GIC files, at least for non-ITS code. The ITS is a beast own its own
(blame the author) and will be addressed later.

*** BLURB HERE ***

Andre Przywara (8):
  ARM: VGIC: drop unneeded gic_restore_pending_irqs()
  ARM: VGIC: split gic.c to observe hardware/virtual GIC separation
  ARM: VGIC: split up gic_dump_info() to cover virtual part separately
  ARM: VGIC: rework events_need_delivery()
  ARM: VGIC: factor out vgic_connect_hw_irq()
  ARM: VGIC: factor out vgic_get_hw_irq_desc()
  ARM: VGIC: rework gicv[23]_update_lr to not use pending_irq
  ARM: make nr_irqs a constant

 xen/arch/arm/Makefile   |   1 +
 xen/arch/arm/domain.c   |   1 +
 xen/arch/arm/gic-v2.c   |  14 +-
 xen/arch/arm/gic-v3.c   |  12 +-
 xen/arch/arm/gic-vgic.c | 466 
 xen/arch/arm/gic.c  | 423 ++--
 xen/arch/arm/irq.c  |   9 +-
 xen/arch/arm/vgic.c |  11 ++
 xen/include/asm-arm/event.h |  13 +-
 xen/include/asm-arm/gic.h   |   8 +-
 xen/include/asm-arm/irq.h   |   5 +-
 xen/include/asm-arm/vgic.h  |   6 +
 12 files changed, 526 insertions(+), 443 deletions(-)
 create mode 100644 xen/arch/arm/gic-vgic.c

-- 
2.14.1


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

[Xen-devel] [PATCH v5 1/8] ARM: VGIC: drop unneeded gic_restore_pending_irqs()

[Andre Przywara]

In gic_restore_pending_irqs() we push our pending virtual IRQs into the
list registers. This function is called once from gic_inject(), just
before we return to the guest, but also in gic_restore_state(), when
we context-switch a VCPU. Having a closer look it turns out that the
later call is not needed, since we will always call gic_inject() anyway.
So remove that call (and the forward declaration) to streamline this
interface and make separating the GIC from the VGIC world later.

Signed-off-by: Andre Przywara 
Reviewed-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/gic.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index bac8ada2bb..721a17a9d7 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -36,8 +36,6 @@
 #include 
 #include 
 
-static void gic_restore_pending_irqs(struct vcpu *v);
-
 static DEFINE_PER_CPU(uint64_t, lr_mask);
 
 #define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) - 
1))
@@ -91,8 +89,6 @@ void gic_restore_state(struct vcpu *v)
 gic_hw_ops->restore_state(v);
 
 isb();
-
-gic_restore_pending_irqs(v);
 }
 
 /* desc->irq needs to be disabled before calling this function */
-- 
2.14.1


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

[Xen-devel] [PATCH v5 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Andre Przywara]

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves abstraction.

One thing to note is that this changes the locking scheme slightly:
we hold the rank lock for a shorter period of time, not covering some
of the later lines, which deal with the "irq_desc" structure only. This
should not have any adverse effect, but is a change in locking anyway.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-vgic.c| 41 +
 xen/arch/arm/gic.c | 44 ++--
 xen/include/asm-arm/vgic.h |  2 ++
 3 files changed, 53 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 8221ae557c..820e464fc0 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -397,6 +397,47 @@ void gic_dump_vgic_info(struct vcpu *v)
 printk("Pending irq=%d\n", p->irq);
 }
 
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
+struct irq_desc *desc, bool connect)
+{
+unsigned long flags;
+/*
+ * Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference.
+ */
+struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
+struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
+struct pending_irq *p = irq_to_pending(v_target, virq);
+int ret = 0;
+
+/* "desc" is optional when we disconnect an IRQ. */
+ASSERT(connect && desc);
+
+/* We are taking to rank lock to prevent parallel connections. */
+vgic_lock_rank(v_target, rank, flags);
+
+if ( connect )
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !p->desc &&
+ !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+p->desc = desc;
+else
+ret = -EBUSY;
+}
+else
+{
+if ( desc && p->desc != desc )
+ret = -EINVAL;
+else
+p->desc = NULL;
+}
+
+vgic_unlock_rank(v_target, rank, flags);
+
+return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 4cb74d449e..968e46fabb 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -128,13 +128,7 @@ void gic_route_irq_to_xen(struct irq_desc *desc, unsigned 
int priority)
 int gic_route_irq_to_guest(struct domain *d, unsigned int virq,
struct irq_desc *desc, unsigned int priority)
 {
-unsigned long flags;
-/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
- * route SPIs to guests, it doesn't make any difference. */
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-struct pending_irq *p = irq_to_pending(v_target, virq);
-int res = -EBUSY;
+int ret;
 
 ASSERT(spin_is_locked(>lock));
 /* Caller has already checked that the IRQ is an SPI */
@@ -142,12 +136,9 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 ASSERT(virq < vgic_num_irqs(d));
 ASSERT(!is_lpi(virq));
 
-vgic_lock_rank(v_target, rank, flags);
-
-if ( p->desc ||
- /* The VIRQ should not be already enabled by the guest */
- test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
-goto out;
+ret = vgic_connect_hw_irq(d, NULL, virq, desc, true);
+if ( ret )
+return ret;
 
 desc->handler = gic_hw_ops->gic_guest_irq_type;
 set_bit(_IRQ_GUEST, >status);
@@ -156,31 +147,19 @@ int gic_route_irq_to_guest(struct domain *d, unsigned int 
virq,
 gic_set_irq_type(desc, desc->arch.type);
 gic_set_irq_priority(desc, priority);
 
-p->desc = desc;
-res = 0;
-
-out:
-vgic_unlock_rank(v_target, rank, flags);
-
-return res;
+return 0;
 }
 
 /* This function only works with SPIs for now */
 int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
   struct irq_desc *desc)
 {
-struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
-struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
-struct pending_irq *p = irq_to_pending(v_target, virq);
-unsigned long flags;
+int ret;
 
 ASSERT(spin_is_locked(>lock));
 ASSERT(test_bit(_IRQ_GUEST, >status));
-ASSERT(p->desc == desc);
 ASSERT(!is_lpi(virq));
 
-vgic_lock_rank(v_target, rank, flags);
-
 if ( d->is_dying )
 {
 desc->handler->shutdown(desc);
@@ -198,19 +177,16 @@ int gic_remove_irq_from_guest(struct domain *d, unsigned 
int virq,
  */
 if ( test_bit(_IRQ_INPROGRESS, 

[Xen-devel] [PATCH v5 4/8] ARM: VGIC: rework events_need_delivery()

[Andre Przywara]

In event.h we very deeply dive into the VGIC to learn if an event for
a guest is pending.
Rework that function to abstract the VGIC specific part out. Also
reorder the queries there, as we only actually need to check for the
event channel if there are no other pending IRQs.

Signed-off-by: Andre Przywara 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/vgic.c | 11 +++
 xen/include/asm-arm/event.h | 13 +++--
 xen/include/asm-arm/vgic.h  |  2 ++
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 6e933a86d3..9921769b15 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -593,6 +593,17 @@ void arch_evtchn_inject(struct vcpu *v)
 vgic_vcpu_inject_irq(v, v->domain->arch.evtchn_irq);
 }
 
+bool vgic_evtchn_irq_pending(struct vcpu *v)
+{
+struct pending_irq *p;
+
+p = irq_to_pending(v, v->domain->arch.evtchn_irq);
+/* Does not work for LPIs. */
+ASSERT(!is_lpi(v->domain->arch.evtchn_irq));
+
+return list_empty(>inflight);
+}
+
 bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
 {
 struct vcpu *v = current;
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index 2b20d1aa15..e8c2a6cb44 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -16,12 +16,6 @@ static inline int vcpu_event_delivery_is_enabled(struct vcpu 
*v)
 
 static inline int local_events_need_delivery_nomask(void)
 {
-struct pending_irq *p = irq_to_pending(current,
-   current->domain->arch.evtchn_irq);
-
-/* Does not work for LPIs. */
-ASSERT(!is_lpi(current->domain->arch.evtchn_irq));
-
 /* XXX: if the first interrupt has already been delivered, we should
  * check whether any other interrupts with priority higher than the
  * one in GICV_IAR are in the lr_pending queue or in the LR
@@ -33,11 +27,10 @@ static inline int local_events_need_delivery_nomask(void)
 if ( gic_events_need_delivery() )
 return 1;
 
-if ( vcpu_info(current, evtchn_upcall_pending) &&
-list_empty(>inflight) )
-return 1;
+if ( !vcpu_info(current, evtchn_upcall_pending) )
+return 0;
 
-return 0;
+return vgic_evtchn_irq_pending(current);
 }
 
 static inline int local_events_need_delivery(void)
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index 2a93a7bef9..22c8502c95 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -218,6 +218,8 @@ extern void register_vgic_ops(struct domain *d, const 
struct vgic_ops *ops);
 int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
 
+bool vgic_evtchn_irq_pending(struct vcpu *v);
+
 extern int domain_vgic_register(struct domain *d, int *mmio_count);
 extern int vcpu_vgic_free(struct vcpu *v);
 extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
-- 
2.14.1


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

[Xen-devel] [PATCH v5 3/8] ARM: VGIC: split up gic_dump_info() to cover virtual part separately

[Andre Przywara]

Currently gic_dump_info() not only dumps the hardware state of the GIC,
but also the VGIC internal virtual IRQ lists.
Split the latter off and move it into gic-vgic.c to observe the abstraction.

Signed-off-by: Andre Przywara 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/domain.c |  1 +
 xen/arch/arm/gic-vgic.c   | 11 +++
 xen/arch/arm/gic.c| 12 
 xen/include/asm-arm/gic.h |  1 +
 4 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index eb8c8f6176..a010443bfd 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -941,6 +941,7 @@ long arch_do_vcpu_op(int cmd, struct vcpu *v, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 void arch_dump_vcpu_info(struct vcpu *v)
 {
 gic_dump_info(v);
+gic_dump_vgic_info(v);
 }
 
 void vcpu_mark_events_pending(struct vcpu *v)
diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 74d8ea7c96..8221ae557c 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -386,6 +386,17 @@ void gic_inject(void)
 gic_hw_ops->update_hcr_status(GICH_HCR_UIE, true);
 }
 
+void gic_dump_vgic_info(struct vcpu *v)
+{
+struct pending_irq *p;
+
+list_for_each_entry ( p, >arch.vgic.inflight_irqs, inflight )
+printk("Inflight irq=%u lr=%u\n", p->irq, p->lr);
+
+list_for_each_entry( p, >arch.vgic.lr_pending, lr_queue )
+printk("Pending irq=%d\n", p->irq);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 04e6d66b69..4cb74d449e 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -443,20 +443,8 @@ static void maintenance_interrupt(int irq, void *dev_id, 
struct cpu_user_regs *r
 
 void gic_dump_info(struct vcpu *v)
 {
-struct pending_irq *p;
-
 printk("GICH_LRs (vcpu %d) mask=%"PRIx64"\n", v->vcpu_id, v->arch.lr_mask);
 gic_hw_ops->dump_state(v);
-
-list_for_each_entry ( p, >arch.vgic.inflight_irqs, inflight )
-{
-printk("Inflight irq=%u lr=%u\n", p->irq, p->lr);
-}
-
-list_for_each_entry( p, >arch.vgic.lr_pending, lr_queue )
-{
-printk("Pending irq=%d\n", p->irq);
-}
 }
 
 void init_maintenance_interrupt(void)
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 71e5354427..1a142d6e9f 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -287,6 +287,7 @@ extern void send_SGI_allbutself(enum gic_sgi sgi);
 
 /* print useful debug info */
 extern void gic_dump_info(struct vcpu *v);
+extern void gic_dump_vgic_info(struct vcpu *v);
 
 /* Number of interrupt lines */
 extern unsigned int gic_number_lines(void);
-- 
2.14.1


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

[Xen-devel] [PATCH v5 6/8] ARM: VGIC: factor out vgic_get_hw_irq_desc()

[Andre Przywara]

At the moment we happily access the VGIC internal struct pending_irq
(which describes a virtual IRQ) in irq.c.
Factor out the actually needed functionality to learn the associated
hardware IRQ and move that into gic-vgic.c to improve abstraction.

Signed-off-by: Andre Przywara 
Acked-by: Stefano Stabellini 
Reviewed-by: Julien Grall 
---
 xen/arch/arm/gic-vgic.c| 17 +
 xen/arch/arm/irq.c |  7 ++-
 xen/include/asm-arm/vgic.h |  2 ++
 3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 820e464fc0..72a904bbeb 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -397,6 +397,23 @@ void gic_dump_vgic_info(struct vcpu *v)
 printk("Pending irq=%d\n", p->irq);
 }
 
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq)
+{
+struct pending_irq *p;
+
+ASSERT(!v && virq >= 32);
+
+if ( !v )
+v = d->vcpu[0];
+
+p = irq_to_pending(v, virq);
+if ( !p )
+return NULL;
+
+return p->desc;
+}
+
 int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
 struct irq_desc *desc, bool connect)
 {
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 7f133de549..62103a20e3 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -534,19 +534,16 @@ int release_guest_irq(struct domain *d, unsigned int virq)
 struct irq_desc *desc;
 struct irq_guest *info;
 unsigned long flags;
-struct pending_irq *p;
 int ret;
 
 /* Only SPIs are supported */
 if ( virq < NR_LOCAL_IRQS || virq >= vgic_num_irqs(d) )
 return -EINVAL;
 
-p = spi_to_pending(d, virq);
-if ( !p->desc )
+desc = vgic_get_hw_irq_desc(d, NULL, virq);
+if ( !desc )
 return -EINVAL;
 
-desc = p->desc;
-
 spin_lock_irqsave(>lock, flags);
 
 ret = -EINVAL;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index fda082395b..6ea9f140a7 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -219,6 +219,8 @@ int vgic_v2_init(struct domain *d, int *mmio_count);
 int vgic_v3_init(struct domain *d, int *mmio_count);
 
 bool vgic_evtchn_irq_pending(struct vcpu *v);
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq);
 int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
 struct irq_desc *desc, bool connect);
 
-- 
2.14.1


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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Alexey G]

On Tue, 6 Feb 2018 14:21:12 +
Andrew Cooper  wrote:

>On 06/02/18 03:10, Alexey G wrote:
>> I/O port 61h normally is not emulated by SMI legacy kbd handling code
>> in BIOS, only ports like 60h, 64h, etc.
>> Contrary to USB legacy emulation, it has to intercept port 61h via a
>> different approach -- generic SMI I/O trap, which is not common (at
>> least it was) to use by BIOSes... although it is possible as EFI
>> interface and code for this is available. The assumption about port
>> 61h being trapped by the SMI handler must be explicitly confirmed by
>> checking I/O Trap control regs in the RCBA region.
>>
>> If I/O trap regs won't show an active I/O trap on I/O port 61h -- the
>> root cause might be different (might even be related to stuff like
>> NMI2SMI logic).
>>
>> If the problem is actually due to NMI handler being preempted by
>> another NMI which occurred after (a long) execution of triggered SMI
>> handler, it might be better to do all sensitive stuff before
>> re-enabling NMIs by IRET in the NMI handler.  
>
>The problem is that the SMI handler executes enough instructions to
>trigger another NMI (which is based on the retired instruction count),
>which gets delivered once the SMI handler returns, and servicing the
>NMI triggers a new SMI, which triggers a new NMI.  This is why the
>system stalls.
>
>I'll leave the how/why port 0x61 is trapping to SMI to Igor, but it is
>only a secondary concern here.  We cannot reasonably have the watchdog
>able to trip because of exclusively SMI activity, or we'll potentially
>livelock anywhere.

The major concern here is the possiblity of SMI being triggered _not_
by some specific I/O port access. Primarily, if it actually was a
periodic SMI.

If the actual SMI source is not related to some place in the NMI
handler code but was eg. due to some SMI timer, lowering NMI watchdog
frequency might not fix the issue completely, but lower its
reproducibility (perhaps to some very rare occurrences). So it's better
be sure what was the real source of SMI.

There are 2 weak spots in the analysis:

1. Triggering SMI by reading I/O port 61h -- intercepting the port 61h
is non-typical behavior for BIOS (unlike 60h/64h)

2. According to the code, it looks like NMI status reading happens while
NMIs are still blocked -- this means that SMI handler must exec IRET
by itself to reset NMI blocking state -- again, this is possible (eg.
in unreal->protmode switching code), but not likely.

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

Re: [Xen-devel] [PATCH 1/3] Make credit2 the default scheduler

[George Dunlap]

On 02/06/2018 06:18 AM, Juergen Gross wrote:
> On 05/02/18 17:53, Dario Faggioli wrote:
>> On Mon, 2018-02-05 at 13:01 +, George Dunlap wrote:
>>> And in any case, making those improvements
>>> on credit2 will be easier than on credit.
>>>
>> And, if possible, I agree with George on this even more!
>>
>> One thing I think we should consider, though, is that we've often said
>> we would switch at the very beginning of a dev cycle, to get as much as
>> osstest and day-by-day testing from developer as possible.
>>
>> Considering we're releasing in June, but freezing in March, do we think
>>  it is still early enough?
> 
> The 4.11 release is completely dominated by Meltdown/Spectre mitigation
> work. So either 4.11 will be a security focused version or we need to
> extend the development phase.

Personally I could go either way on this.  So unless someone wants to
argue for switching now (or we significantly extend the development
window), let's plan on leaving this for post-4.11.

> I think we should _really_ discuss release schedules rather sooner than
> later.

Sorry I wasn't much involved in the earlier discussion -- I was rather
heads-down trying to figure out what to do about speculative execution.
:-)  Let me see if I can go find that thread.

 -George

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

Re: [Xen-devel] [PATCH v1 3/6] libxl: add backend type and id to vkb

[Wei Liu]

On Tue, Feb 06, 2018 at 06:45:15PM +0200, Oleksandr Grytsov wrote:
> > > +static int libxl__set_xenstore_vkb(libxl__gc *gc, uint32_t domid,
> > > +   libxl_device_vkb *vkb,
> > > +   flexarray_t *back, flexarray_t
> > *front,
> > > +   flexarray_t *ro_front)
> > > +{
> > > +if (vkb->id) {
> > > +flexarray_append_pair(front, "id", vkb->id);
> > > +}
> > > +
> >
> > Ditto.
> >
> > And, isn't 0 a valid device id?
> >
> >
> id here is char *. I put it to xenstore only if it is defined. It shall be
> defined for linux backend
> in case of multiple instances of kbd device are defined. The backend
> distinguishes them
> by id.

Oh I was a fool -- I misread that as dev_id which had numeric value.

Wei.

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

Re: [Xen-devel] [PATCH 1/2] make xen ocaml safe-strings compliant

[Wei Liu]

On Tue, Jan 30, 2018 at 10:55:47PM +, Michael Young wrote:
> Xen built with ocaml 4.06 gives errors such as
> Error: This expression has type bytes but an expression was
>   expected of type string
> as Byte and safe-strings which were introduced in 4.02 are the
> default in 4.06.
> This patch which is partly by Richard W.M. Jones of Red Hat
> from https://bugzilla.redhat.com/show_bug.cgi?id=1526703
> fixes these issues.
> 
> Signed-off-by: Michael Young 
> Reviewed-by: Christian Lindig 

Strangely this doesn't apply to staging. And after examining the
downloaded patch I'm not sure if my mail client is acting up. Do you
have a git branch that I can pull from?

Wei.

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

Re: [Xen-devel] [PATCH v1 3/6] libxl: add backend type and id to vkb

[Oleksandr Grytsov]

On Tue, Feb 6, 2018 at 4:25 PM, Wei Liu  wrote:

> On Wed, Nov 01, 2017 at 05:05:04PM +0200, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov 
> >
> > New field backend_type is added to vkb device
> > in order to have QEMU and user space backend
> > simultaneously. Each vkb backend shall read
> > appropriate XS entry and service only own
> > frontends.
> > Id is a string field which used by the backend
> > to indentify the frontend.
> >
> > Signed-off-by: Oleksandr Grytsov 
> > ---
> >  tools/libxl/libxl_create.c  |  3 +++
> >  tools/libxl/libxl_dm.c  |  1 +
> >  tools/libxl/libxl_types.idl |  8 
> >  tools/libxl/libxl_vkb.c | 33 -
> >  4 files changed, 44 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index f813114..60d8686 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1376,6 +1376,9 @@ static void domcreate_launch_dm(libxl__egc *egc,
> libxl__multidev *multidev,
> >  for (i = 0; i < d_config->num_vfbs; i++) {
> >  libxl__device_add(gc, domid, __vfb_devtype,
> >_config->vfbs[i]);
> > +}
> > +
> > +for (i = 0; i < d_config->num_vkbs; i++) {
> >  libxl__device_add(gc, domid, __vkb_devtype,
> >_config->vkbs[i]);
> >  }
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 98f89a9..f07de35 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -1728,6 +1728,7 @@ static int 
> > libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc
> *gc,
> >
> >  vkb->backend_domid = 0;
> >  vkb->devid = 0;
> > +
>
> Stray change. I don't have objection though.
>
> >  return 0;
> >  }
> >
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index cd0c06f..c3876a2 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -240,6 +240,12 @@ libxl_checkpointed_stream =
> Enumeration("checkpointed_stream", [
> >  (2, "COLO"),
> >  ])
> >
> > +libxl_vkb_backend = Enumeration("vkb_backend", [
> > +(0, "UNKNOWN"),
> > +(1, "QEMU"),
> > +(2, "LINUX")
> > +])
> > +
> >  #
> >  # Complex libxl types
> >  #
> > @@ -603,6 +609,8 @@ libxl_device_vkb = Struct("device_vkb", [
> >  ("backend_domid", libxl_domid),
> >  ("backend_domname", string),
> >  ("devid", libxl_devid),
> > +("backend_type", libxl_vkb_backend),
> > +("id", string)
> >  ])
> >
> >  libxl_device_disk = Struct("device_disk", [
> > diff --git a/tools/libxl/libxl_vkb.c b/tools/libxl/libxl_vkb.c
> > index ea6fca8..88ab186 100644
> > --- a/tools/libxl/libxl_vkb.c
> > +++ b/tools/libxl/libxl_vkb.c
> > @@ -17,6 +17,10 @@
> >  static int libxl__device_vkb_setdefault(libxl__gc *gc, uint32_t domid,
> >  libxl_device_vkb *vkb, bool
> hotplug)
> >  {
> > +if (vkb->backend_type == LIBXL_VKB_BACKEND_UNKNOWN) {
> > +vkb->backend_type = LIBXL_VKB_BACKEND_QEMU;
> > +}
> > +
> >  return libxl__resolve_domid(gc, vkb->backend_domname,
> >backend_domid);
> >  }
> >
> > @@ -34,6 +38,30 @@ static int libxl__device_from_vkb(libxl__gc *gc,
> uint32_t domid,
> >  return 0;
> >  }
> >
> > +static int libxl__device_vkb_dm_needed(libxl_device_vkb *vkb, uint32_t
> domid)
> > +{
> > +   if (vkb->backend_type == LIBXL_VKB_BACKEND_QEMU) {
> > +return 1;
> > +   }
>
> No need to have {} for a single statement here.
>
> > +
> > +return 0;
> > +}
> > +
> > +static int libxl__set_xenstore_vkb(libxl__gc *gc, uint32_t domid,
> > +   libxl_device_vkb *vkb,
> > +   flexarray_t *back, flexarray_t
> *front,
> > +   flexarray_t *ro_front)
> > +{
> > +if (vkb->id) {
> > +flexarray_append_pair(front, "id", vkb->id);
> > +}
> > +
>
> Ditto.
>
> And, isn't 0 a valid device id?
>
>
id here is char *. I put it to xenstore only if it is defined. It shall be
defined for linux backend
in case of multiple instances of kbd device are defined. The backend
distinguishes them
by id.

Wei.
>



-- 
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Xen ARM community call Tuesday 13th February 5PM UTC

[Lars Kurth]

> As we do not have Jira access, it would be better to do it on Wiki or 
>  "something else".
The project has Jira access and can give selected community members write access
Read access is not an issue
Lars

On 06/02/2018, 11:22, "Artem Mygaiev"  wrote:

Hi Lars

As we do not have Jira access, it would be better to do it on Wiki or 
"something else".

  -- Artem

On 06.02.18 12:53, Lars Kurth wrote:
> Adding Rich
> 
>> I think it would be hugely beneficial if there could be an open
>> repository of information that describes in clear terms what the
>> specific engineering items are which are needed to make Xen viable for
>> assessment towards safety certification.
> Very good idea
> 
> If there is agreement, I can volunteer to set up such a repository: 
options for tracking are
> *Our Atlassian Jira instance (maybe a new area specifically for this 
purpose)
> * Wiki page
> * Something else
> 
> Lars
> 
> On 06/02/2018, 10:26, "Robin Randhawa"  wrote:
> 
>  Hi Julien.
>  
>  Thanks for looping me in.
>  
>  On Tue, 2018-02-06 at 10:11 +, Julien Grall wrote:
>  > Hi all,
>  >
>  > I would suggest to have the next community call on Tuesday 13th
>  > February
>  > 5pm GMT. Does it sound good?
>  
>  I'm out of office from the 8th to the 16th unfortunately.
>  
>  > Do you have any specific topic you would like to discuss?
>  
>  From my side:
>  
>  I've spoken to a fair number of folks on the To list here in 1-1
>  discussions about this.
>  
>  I think it would be hugely beneficial if there could be an open
>  repository of information that describes in clear terms what the
>  specific engineering items are which are needed to make Xen viable 
for
>  assessment towards safety certification.
>  
>  I'm not a Xen expert by any measure but off the top I recall that one
>  item was the task of removing the reliance on the Linux kernel for
>  Dom0.
>  
>  I am certain there are more.
>  
>  The motivation behind this is to spur folks into acknowledging the
>  technical work that remains to be done. Whether that work then 
happens
>  behind closed proprietary doors to generate value or in the open is 
an
>  implementation detail.
>  
>  If nothing else - it would definitely act as an accelerator.
>  
>  Personally, I would be thrilled if there was enough momentum to 
openly
>  massage Xen into the shape that I allude to. If that takes things 70%
>  ahead with the remaining 30% done by misc Xen commercial entities as
>  their differentiation value add - that's a huge bonus for the 
ecosystem
>  and for the future of Xen.
>  
>  Thanks!
>  Robin
>  
>  
>  IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
>  
> 


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

Re: [Xen-devel] [PATCH v3 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

Hi,

On 06.02.18 17:53, Julien Grall wrote:

At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).

This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.

Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the latter
0.2 or later call.

At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.

Signed-off-by: Julien Grall 

Reviewed-by: Volodymyr Babchuk 


---
 Changes in v3:
 - Add copyright and emacs magic in vpsci.h
 - Add a comment to update SCCC_SMCCC_*_REVISION once per
 release

 Changes in v2:
 - Add a 'v' in the function names to help distinguish virtual vs
 physical PSCI
 - Introduce vpsci.h and VSCPI_NR_FUNCS
---
  xen/arch/arm/vpsci.c| 148 +++-
  xen/arch/arm/vsmc.c |  99 ++---
  xen/include/asm-arm/psci.h  |  19 --
  xen/include/asm-arm/vpsci.h |  42 +
  4 files changed, 182 insertions(+), 126 deletions(-)
  create mode 100644 xen/include/asm-arm/vpsci.h

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 979d32ed6d..03fd4eb5b5 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -16,7 +16,7 @@
  
  #include 

  #include 
-#include 
+#include 
  #include 
  
  #include 

@@ -91,12 +91,12 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
  return PSCI_SUCCESS;
  }
  
-int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)

+static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
  {
  return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
  }
  
-int32_t do_psci_cpu_off(uint32_t power_state)

+static int32_t do_psci_cpu_off(uint32_t power_state)
  {
  struct vcpu *v = current;
  if ( !test_and_set_bit(_VPF_down, >pause_flags) )
@@ -104,13 +104,14 @@ int32_t do_psci_cpu_off(uint32_t power_state)
  return PSCI_SUCCESS;
  }
  
-uint32_t do_psci_0_2_version(void)

+static uint32_t do_psci_0_2_version(void)
  {
  return PSCI_VERSION(0, 2);
  }
  
-register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t entry_point,

-register_t context_id)
+static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
+  register_t entry_point,
+  register_t context_id)
  {
  struct vcpu *v = current;
  
@@ -123,13 +124,14 @@ register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t entry_point,

  return PSCI_SUCCESS;
  }
  
-int32_t do_psci_0_2_cpu_off(void)

+static int32_t do_psci_0_2_cpu_off(void)
  {
  return do_psci_cpu_off(0);
  }
  
-int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t entry_point,

-   register_t context_id)
+static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
+  register_t entry_point,
+  register_t context_id)
  {
  return do_common_cpu_on(target_cpu, entry_point, context_id,
  PSCI_VERSION(0, 2));
@@ -144,8 +146,8 @@ static const unsigned long target_affinity_mask[] = {
  #endif
  };
  
-int32_t do_psci_0_2_affinity_info(register_t target_affinity,

-  uint32_t lowest_affinity_level)
+static int32_t do_psci_0_2_affinity_info(register_t target_affinity,
+ uint32_t lowest_affinity_level)
  {
  struct domain *d = current->domain;
  struct vcpu *v;
@@ -172,23 +174,141 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
  return PSCI_0_2_AFFINITY_LEVEL_OFF;
  }
  
-uint32_t do_psci_0_2_migrate_info_type(void)

+static uint32_t do_psci_0_2_migrate_info_type(void)
  {
  return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
  }
  
-void do_psci_0_2_system_off( void )

+static void do_psci_0_2_system_off( void )
  {
  struct domain *d = current->domain;
  domain_shutdown(d,SHUTDOWN_poweroff);
  }
  
-void do_psci_0_2_system_reset(void)

+static void do_psci_0_2_system_reset(void)
  {
  struct domain *d = current->domain;
  domain_shutdown(d,SHUTDOWN_reboot);
  }
  
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)

+#define PSCI_ARG(reg, n) get_user_reg(reg, n)
+
+#ifdef CONFIG_ARM_64
+#define PSCI_ARG32(reg, n) (uint32_t)(get_user_reg(reg, n))
+#else
+#define PSCI_ARG32(reg, n) PSCI_ARG(reg, n)
+#endif
+
+/*
+ * PSCI 0.1 calls. It will return false if the function ID is not
+ * handled.
+ */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, 

Re: [Xen-devel] [PATCH 7/7] xen/arm64: Implement a fast path for handling SMCCC_ARCH_WORKAROUND_1

[Volodymyr Babchuk]

Hi,

On 5 February 2018 at 15:20, Julien Grall  wrote:
> The function SMCCC_ARCH_WORKAROUND_1 will be called by the guest for
> hardening the branch predictor. So we want the handling to be as fast as
> possible.
>
> As the mitigation is applied on every guest exit, we can check for the
> call before saving all the context and return very early.
Have you tried any benchmarks? How big is the benefit?

>
> For now, only provide a fast path for HVC64 call. Because the code rely
> on 2 registers, x0 and x1 are saved in advanced.
Is there a typo? Should it be "advance"?

>
> Signed-off-by: Julien Grall 
>
> ---
> guest_sync only handle 64-bit guest, so I have only implemented the
> 64-bit side for now. We can discuss whether it is useful to
> implement it for 32-bit guests.
>
> We could also consider to implement the fast path for SMC64,
> althought a guest should always use HVC.
I can imagine a guest that know nothing about virtualization and use
SMC as a conduit. But I can't provide real world example, thou.

> ---
>  xen/arch/arm/arm64/entry.S  | 56 
> +++--
>  xen/include/asm-arm/processor.h |  2 ++
>  2 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/entry.S b/xen/arch/arm/arm64/entry.S
> index 6d99e46f0f..67f96d518f 100644
> --- a/xen/arch/arm/arm64/entry.S
> +++ b/xen/arch/arm/arm64/entry.S
> @@ -1,6 +1,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  /*
> @@ -90,8 +91,12 @@ lr  .reqx30 /* link register */
>  .endm
>  /*
>   * Save state on entry to hypervisor, restore on exit
> + *
> + * save_x0_x1: Does the macro needs to save x0/x1 (default 1). If 0,
> + * we rely on the on x0/x1 to have been saved at the correct position on
> + * the stack before.
>   */
> -.macro  entry, hyp, compat
> +.macro  entry, hyp, compat, save_x0_x1=1
>  sub sp, sp, #(UREGS_SPSR_el1 - UREGS_LR) /* CPSR, PC, SP, LR */
>  pushx28, x29
>  pushx26, x27
> @@ -107,7 +112,16 @@ lr  .reqx30 /* link register */
>  pushx6, x7
>  pushx4, x5
>  pushx2, x3
> +/*
> + * The caller may already have saved x0/x1 on the stack at the
> + * correct address and corrupt them with another value. Only
> + * save them if save_x0_x1 == 1.
> + */
> +.if \save_x0_x1 == 1
>  pushx0, x1
> +.else
> +sub sp, sp, #16
> +.endif
>
>  .if \hyp == 1/* Hypervisor mode */
>
> @@ -200,7 +214,45 @@ hyp_irq:
>  exithyp=1
>
>  guest_sync:
> -entry   hyp=0, compat=0
> +/*
> + * Save x0, x1 in advance
> + */
> +stp x0, x1, [sp, #-(UREGS_kernel_sizeof - UREGS_X0)]
> +
> +/*
> + * x1 is used because x0 may contain the function identifier.
> + * This avoids to restore x0 from the stack.
> + */
> +mrs x1, esr_el2
> +lsr x1, x1, #HSR_EC_SHIFT   /* x1 = ESR_EL2.EC */
> +cmp x1, #HSR_EC_HVC64
> +b.ne1f  /* Not a HVC skip fastpath. 
> */
> +
> +mrs x1, esr_el2
> +and x1, x1, #0x /* Check the immediate 
> [0:16] */
> +cbnzx1, 1f  /* should be 0 for HVC #0 */
> +
> +/*
> + * Fastest path possible for ARM_SMCCC_ARCH_WORKAROUND_1.
> + * The workaround has already been applied on the exception
> + * entry from the guest, so let's quickly get back to the guest.
> + */
> +eor w0, w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
> +cbnzw0, 1f
> +
> +/*
> + * Clobber both x0 and x1 to prevent leakage. Note that thanks
> + * the eor, x0 = 0.
> + */
> +mov x1, x0
> +eret
> +
> +1:
> +/*
> + * x0/x1 may have been scratch by the fast path above, so avoid
> + * to save them.
> + */
> +entry   hyp=0, compat=0, save_x0_x1=0
>  /*
>   * The vSError will be checked while 
> SKIP_SYNCHRONIZE_SERROR_ENTRY_EXIT
>   * is not set. If a vSError took place, the initial exception will be
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index c0f79d0093..222a02dd99 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -306,6 +306,8 @@
>  #define HDCR_TPM(_AC(1,U)<<6)   /* Trap Performance Monitors 
> accesses */
>  #define HDCR_TPMCR  (_AC(1,U)<<5)   /* Trap PMCR accesses */
>
> +#define HSR_EC_SHIFT26
> +
>  #define HSR_EC_UNKNOWN  0x00
>  #define HSR_EC_WFI_WFE  0x01
>  #define HSR_EC_CP15_32  0x03
> --
> 2.11.0
>
>
> 

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 06/02/18 16:23, Jan Beulich wrote:
 On 06.02.18 at 17:14,  wrote:
>> On 06/02/18 16:07, Jan Beulich wrote:
>> On 05.02.18 at 22:18,  wrote:
 --- a/xen/arch/x86/nmi.c
 +++ b/xen/arch/x86/nmi.c
 @@ -34,7 +34,8 @@
  #include 
  
  unsigned int nmi_watchdog = NMI_NONE;
 -static unsigned int nmi_hz = HZ;
 +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs 
>> */
 +static unsigned int nmi_hz = HZ / 10;
>>>
>>> For one - the comment should explain what "too high" means.
>>> Further - what if on another system 10Hz is still too high? I also hope
>>> you realize that you slow down boot a little for everyone just
>>> because of this one machine model. Can the lower frequency perhaps
>>> be set via DMI quirk, or otherwise obtain a command line override
>>> (perhaps something like "watchdog=probe:10Hz")?
>>>
>>
>> I can improve the comment message.
>> Why does this change slow down anything while I'm lowering the frequency
>> - not making it higher?
> 
> We wait for two occurrences of the NMI in wait_for_nmis().

Yes, you right, ignore my previous mail. We are waiting synchronously
for them. I'll rewrite the code so I'll not change the frequency.

Igor

> 
>> The alternative approach would be to reshuffle
>> the code and take the reason before programming the next interrupt as
>> suggested before. In that case the actual frequency would be adjusted
>> naturally I think.
> 
> Thinking about this, reading the reason early seems like a good idea
> to me irrespective of the issue here.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 06/02/18 16:23, Jan Beulich wrote:
 On 06.02.18 at 17:14,  wrote:
>> On 06/02/18 16:07, Jan Beulich wrote:
>> On 05.02.18 at 22:18,  wrote:
 --- a/xen/arch/x86/nmi.c
 +++ b/xen/arch/x86/nmi.c
 @@ -34,7 +34,8 @@
  #include 
  
  unsigned int nmi_watchdog = NMI_NONE;
 -static unsigned int nmi_hz = HZ;
 +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs 
>> */
 +static unsigned int nmi_hz = HZ / 10;
>>>
>>> For one - the comment should explain what "too high" means.
>>> Further - what if on another system 10Hz is still too high? I also hope
>>> you realize that you slow down boot a little for everyone just
>>> because of this one machine model. Can the lower frequency perhaps
>>> be set via DMI quirk, or otherwise obtain a command line override
>>> (perhaps something like "watchdog=probe:10Hz")?
>>>
>>
>> I can improve the comment message.
>> Why does this change slow down anything while I'm lowering the frequency
>> - not making it higher?
> 
> We wait for two occurrences of the NMI in wait_for_nmis().
> 

This happens *much* later in the boot sequence after we actually enable
the watchdog on CPU0. Till that time we already get hundreds of them
regardless of the frequency.

>> The alternative approach would be to reshuffle
>> the code and take the reason before programming the next interrupt as
>> suggested before. In that case the actual frequency would be adjusted
>> naturally I think.
> 
> Thinking about this, reading the reason early seems like a good idea
> to me irrespective of the issue here.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH 6/7] xen/arm: Adapt smccc.h to be able to use it in assembly code

[Volodymyr Babchuk]

Hi,

On 5 February 2018 at 15:20, Julien Grall  wrote:
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

> ---
>  xen/include/asm-arm/smccc.h | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index b790fac17c..d24ccb51d8 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -25,18 +25,20 @@
>   * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
>   */
>
> -#define ARM_SMCCC_STD_CALL  0U
> -#define ARM_SMCCC_FAST_CALL 1U
> +#define ARM_SMCCC_STD_CALL  _AC(0,U)
> +#define ARM_SMCCC_FAST_CALL _AC(1,U)
>  #define ARM_SMCCC_TYPE_SHIFT31
>
> -#define ARM_SMCCC_CONV_32   0U
> -#define ARM_SMCCC_CONV_64   1U
> +#define ARM_SMCCC_CONV_32   _AC(0,U)
> +#define ARM_SMCCC_CONV_64   _AC(1,U)
>  #define ARM_SMCCC_CONV_SHIFT30
>
> -#define ARM_SMCCC_OWNER_MASK0x3FU
> +#define ARM_SMCCC_OWNER_MASK_AC(0x3F,U)
>  #define ARM_SMCCC_OWNER_SHIFT   24
>
> -#define ARM_SMCCC_FUNC_MASK 0xU
> +#define ARM_SMCCC_FUNC_MASK _AC(0x,U)
> +
> +#ifndef __ASSEMBLY__
>
>  /* Check if this is fast call. */
>  static inline bool smccc_is_fast_call(register_t funcid)
> @@ -62,6 +64,8 @@ static inline uint32_t smccc_get_owner(register_t funcid)
>  return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
>  }
>
> +#endif
> +
>  /*
>   * Construct function identifier from call type (fast or standard),
>   * calling convention (32 or 64 bit), service owner and function number.
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH 5/7] xen/arm: vsmc: Implement SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Volodymyr Babchuk]

Hi,

On 5 February 2018 at 15:20, Julien Grall  wrote:
> SMCCC 1.1 offers firmware-based CPU workarounds. In particular,
> SMCCC_ARCH_WORKAROUND_1 provides BP hardening for variant 2 of XSA-254
> (CVE-2017-5715).
>
> If the hypervisor has some mitigation for this issue, report that we
> deal with it using SMCCC_ARCH_WORKAROUND_1, as we apply the hypervisor
> workaround on every guest exit.
Just to be sure: is there some way to disable this workaround?


>
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/vsmc.c | 22 --
>  xen/include/asm-arm/smccc.h |  6 ++
>  2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index a708aa5e81..144a1cd761 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -93,8 +94,25 @@ static bool handle_arch(struct cpu_user_regs *regs)
>  return true;
>
>  case ARM_SMCCC_ARCH_FEATURES_FID:
> -/* Nothing supported yet */
> -set_user_reg(regs, 0, -1);
> +{
> +uint32_t arch_func_id = get_user_reg(regs, 1);
> +int ret = -1;
I think that register_t will suit better in this case.

> +
> +switch ( arch_func_id )
> +{
> +case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
> +if ( cpus_have_cap(ARM_HARDEN_BRANCH_PREDICTOR) )
> +ret = 0;
> +break;
> +}
> +
> +set_user_reg(regs, 0, ret);
> +
> +return true;
> +}
> +
> +case ARM_SMCCC_ARCH_WORKAROUND_1_FID:
> +/* No return value */
>  return true;
>  }
>
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index 431389c118..b790fac17c 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -115,6 +115,12 @@ static inline uint32_t smccc_get_owner(register_t funcid)
> ARM_SMCCC_OWNER_ARCH,\
> 0x1)
>
> +#define ARM_SMCCC_ARCH_WORKAROUND_1_FID \
> +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +  ARM_SMCCC_CONV_32,\
> +  ARM_SMCCC_OWNER_ARCH, \
> +  0x8000)
> +
>  /* Only one error code defined in SMCCC */
>  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
>
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Jan Beulich]

>>> On 06.02.18 at 17:14,  wrote:
> On 06/02/18 16:07, Jan Beulich wrote:
> On 05.02.18 at 22:18,  wrote:
>>> --- a/xen/arch/x86/nmi.c
>>> +++ b/xen/arch/x86/nmi.c
>>> @@ -34,7 +34,8 @@
>>>  #include 
>>>  
>>>  unsigned int nmi_watchdog = NMI_NONE;
>>> -static unsigned int nmi_hz = HZ;
>>> +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs 
> */
>>> +static unsigned int nmi_hz = HZ / 10;
>> 
>> For one - the comment should explain what "too high" means.
>> Further - what if on another system 10Hz is still too high? I also hope
>> you realize that you slow down boot a little for everyone just
>> because of this one machine model. Can the lower frequency perhaps
>> be set via DMI quirk, or otherwise obtain a command line override
>> (perhaps something like "watchdog=probe:10Hz")?
>>
> 
> I can improve the comment message.
> Why does this change slow down anything while I'm lowering the frequency
> - not making it higher?

We wait for two occurrences of the NMI in wait_for_nmis().

> The alternative approach would be to reshuffle
> the code and take the reason before programming the next interrupt as
> suggested before. In that case the actual frequency would be adjusted
> naturally I think.

Thinking about this, reading the reason early seems like a good idea
to me irrespective of the issue here.

Jan


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

Re: [Xen-devel] [PATCH 4/7] xen/arm: vsmc: Implement SMCCC 1.1

[Volodymyr Babchuk]

On 5 February 2018 at 15:20, Julien Grall  wrote:
> The new SMC Calling Convention (v1.1) allows for a reduced overhead when
> calling into the firmware, and provides a new feature discovery
> mechanism. See ARM DEN 00070A.
Сould you please use also a human-readable document name? I remember
that I read "Firmware interfaces for mitigating CVE-2017-5715", but I
can't remember what is ARM DEN 00070A about.

> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/vpsci.c|  1 +
>  xen/arch/arm/vsmc.c | 23 +++
>  xen/include/asm-arm/smccc.h | 15 +++
>  3 files changed, 39 insertions(+)
>
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 025250a119..e40ba5c5ad 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -215,6 +215,7 @@ static int32_t do_psci_1_0_features(uint32_t psci_func_id)
>  case PSCI_0_2_FN32_AFFINITY_INFO:
>  case PSCI_0_2_FN64_AFFINITY_INFO:
>  case PSCI_1_0_FN32_PSCI_FEATURES:
> +case ARM_SMCCC_VERSION_FID:
>  return 0;
>  default:
>  return PSCI_NOT_SUPPORTED;
> diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
> index 3d3bd95fee..a708aa5e81 100644
> --- a/xen/arch/arm/vsmc.c
> +++ b/xen/arch/arm/vsmc.c
> @@ -81,6 +81,26 @@ static bool fill_function_call_count(struct cpu_user_regs 
> *regs, uint32_t cnt)
>  return true;
>  }
>
> +/* SMCCC interface for ARM Architecture */
> +static bool handle_arch(struct cpu_user_regs *regs)
> +{
> +uint32_t fid = (uint32_t)get_user_reg(regs, 0);
> +
> +switch ( fid )
> +{
> +case ARM_SMCCC_VERSION_FID:
> +set_user_reg(regs, 0, ARM_SMCCC_VERSION_1_1);
> +return true;
> +
> +case ARM_SMCCC_ARCH_FEATURES_FID:
> +/* Nothing supported yet */
> +set_user_reg(regs, 0, -1);
> +return true;
> +}
> +
> +return false;
> +}
> +
>  /* SMCCC interface for hypervisor. Tell about itself. */
>  static bool handle_hypervisor(struct cpu_user_regs *regs)
>  {
> @@ -188,6 +208,9 @@ static bool vsmccc_handle_call(struct cpu_user_regs *regs)
>  {
>  switch ( smccc_get_owner(funcid) )
>  {
> +case ARM_SMCCC_OWNER_ARCH:
> +handled = handle_arch(regs);
> +break;
>  case ARM_SMCCC_OWNER_HYPERVISOR:
>  handled = handle_hypervisor(regs);
>  break;
> diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
> index 62b3a8cdf5..431389c118 100644
> --- a/xen/include/asm-arm/smccc.h
> +++ b/xen/include/asm-arm/smccc.h
> @@ -16,6 +16,9 @@
>  #ifndef __ASM_ARM_SMCCC_H__
>  #define __ASM_ARM_SMCCC_H__
>
> +#define ARM_SMCCC_VERSION_1_0   0x1
> +#define ARM_SMCCC_VERSION_1_1   0x10001
> +
>  /*
>   * This file provides common defines for ARM SMC Calling Convention as
>   * specified in
> @@ -100,6 +103,18 @@ static inline uint32_t smccc_get_owner(register_t funcid)
> ARM_SMCCC_OWNER_##owner, \
> 0xFF03)
>
> +#define ARM_SMCCC_VERSION_FID   \
> +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +   ARM_SMCCC_CONV_32,   \
> +   ARM_SMCCC_OWNER_ARCH,\
> +   0x0) \
> +
> +#define ARM_SMCCC_ARCH_FEATURES_FID \
> +ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, \
> +   ARM_SMCCC_CONV_32,   \
> +   ARM_SMCCC_OWNER_ARCH,\
> +   0x1)
> +
>  /* Only one error code defined in SMCCC */
>  #define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
>
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Igor Druzhinin]

On 06/02/18 16:07, Jan Beulich wrote:
 On 05.02.18 at 22:18,  wrote:
>> --- a/xen/arch/x86/nmi.c
>> +++ b/xen/arch/x86/nmi.c
>> @@ -34,7 +34,8 @@
>>  #include 
>>  
>>  unsigned int nmi_watchdog = NMI_NONE;
>> -static unsigned int nmi_hz = HZ;
>> +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs */
>> +static unsigned int nmi_hz = HZ / 10;
> 
> For one - the comment should explain what "too high" means.
> Further - what if on another system 10Hz is still too high? I also hope
> you realize that you slow down boot a little for everyone just
> because of this one machine model. Can the lower frequency perhaps
> be set via DMI quirk, or otherwise obtain a command line override
> (perhaps something like "watchdog=probe:10Hz")?
>

I can improve the comment message.
Why does this change slow down anything while I'm lowering the frequency
- not making it higher? The alternative approach would be to reshuffle
the code and take the reason before programming the next interrupt as
suggested before. In that case the actual frequency would be adjusted
naturally I think.

Igor

> Jan
> 

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

[Xen-devel] [xen-unstable test] 118607: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
REGR. vs. 118582

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

version targeted for testing:
 xen  1c3545eeaf4ac6f8d5db5a52c29c112694bcd4f0
baseline version:
 xen  99d9d7a33b781bc9a91416f1e04c8e50e40fa4ef

Last test of basis   118582  2018-02-05 01:57:22 Z1 days
Failing since118594  2018-02-05 14:46:10 Z1 days2 attempts
Testing same since   118607  2018-02-06 05:47:11 Z0 days1 attempts


People who touched 

Re: [Xen-devel] [PATCH] x86/spec_ctrl: Fix determination of when to use IBRS

[Jan Beulich]

>>> On 06.02.18 at 14:48,  wrote:
> The original version of this logic was:
> 
> /*
>  * On Intel hardware, we'd like to use retpoline in preference to
>  * IBRS, but only if it is safe on this hardware.
>  */
> else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
> {
> if ( retpoline_safe() )
> thunk = THUNK_RETPOLINE;
> else
> ibrs = true;
> }
> 
> but it was changed by a request during review.  Sadly, the result is buggy as
> it breaks the later fallback logic by allowing IBRS to appear as available
> when in fact it isn't.
> 
> This in practice means that on repoline-unsafe hardware without IBRS, we
> select THUNK_JUMP despite intending to select THUNK_RETPOLINE.
> 
> Reported-by: Zhenzhong Duan 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

[Xen-devel] CfP 13th Virtualization in High­-Performance Cloud Computing Workshop (VHPC '18)

[VHPC 18]

*CALL
FOR PAPERS 13th Workshop on Virtualization in High­-Performance Cloud
Computing  (VHPC '18)held in conjunction with the International
Supercomputing Conference - High Performance,June 24-28, 2018, Frankfurt,
Germany.(Springer LNCS Proceedings)
Date:
June 28, 2018Workshop URL: http://vhpc.org Paper
Submission Deadline: April 23, 2018, Springer LNCS, rolling abstract
submissionAbstract/Paper Submission Link:
https://edas.info/newPaper.php?c=24355
Special Track: GPU - Accelerator
Virtualization Call for PapersVirtualization technologies constitute a key
enabling factor for flexible resource managementin modern data centers, and
particularly in cloud environments. Cloud providers need tomanage complex
infrastructures in a seamless fashion to support the highly dynamic
andheterogeneous workloads and hosted applications customers deploy.
Similarly, HPCenvironments have been increasingly adopting techniques that
enable flexible managementof vast computing and networking resources, close
to marginal provisioning cost, which isunprecedented in the history of
scientific and commercial computing.Various virtualization technologies
contribute to the overall picture in different ways: machinevirtualization,
with its capability to enable consolidation of multiple under­utilized
servers withheterogeneous software and operating systems (OSes), and its
capability to live­-migrate afully operating virtual machine (VM) with a
very short downtime, enables novel and dynamicways to manage physical
servers; OS-­level virtualization (i.e., containerization), with
itscapability to isolate multiple user­-space environments and to allow for
their co­existencewithin the same OS kernel, promises to provide many of
the advantages of machine virtualization with high levels of responsiveness
and performance; I/O Virtualization allows physical network interfaces to
take traffic from multiple VMs or containers; network virtualization, with
its capability to create logical network overlays that are independent of
theunderlying physical topology is furthermore enabling virtualization of
HPC infrastructures. PublicationAccepted papers will be published in a
Springer LNCS proceedings volume.Topics of InterestThe VHPC program
committee solicits original, high-quality submissions related
tovirtualization across the entire software stack with a special focus on
the intersection of HPCand the cloud.Major Topics- Virtualization in
supercomputing environments, HPC clusters, HPC in the cloud and grids-
OS-level virtualization and containers (LXC, Docker, rkt, Singularity,
Shifter, i.a.)- Lightweight/specialized operating systems in conjunction
with virtual machines- Novel unikernels and use cases for virtualized HPC
environments- Performance improvements for or driven by unikernels- Tool
support for unikernels: configuration/build environments, debuggers,
profilers- Hypervisor extensions to mitigate side-channel attacks
 ([micro-]architectural timing attacks, privilege escalation)- VM &
Container trust and security- Containers inside VMs with hypervisor
isolation- GPU virtualization operationalization- Approaches to GPGPU
virtualization including API remoting and hypervisor abstraction-
Optimizations of virtual machine monitor platforms and hypervisors-
Hypervisor support for heterogeneous resources (GPUs, co-processors, FPGAs,
etc.)- Virtualization support for emerging memory technologies-
Virtualization in enterprise HPC and microvisors- Software defined networks
and network virtualization- Management, deployment of virtualized
environments and orchestration (Kubernetes i.a.)- Workflow-pipeline
container-based composability - Checkpointing facilitation utilizing
containers and VMs - Emerging topics including multi-kernel approaches and
NUMA in hypervisors- Operating MPI in containers/VMs and Unikernels  -
Virtualization in data intensive computing (big data) - HPC convergence-
Adaptation of HPC technologies in the cloud (high performance networks,
RDMA, etc.)- Performance measurement, modelling and monitoring of
virtualized/cloud workloads- Latency-and jitter sensitive workloads in
virtualized/containerized environments- I/O virtualization (including
applications, SR-IOV, i.a.) - Hybrid local facility + cloud compute and
based storage systems, cloudbursting- FPGA and many-core accelerator
virtualization- Job scheduling/control/policy and container placement in
virtualized environments- Cloud reliability, fault-tolerance and
high-availability- QoS and SLA in virtualized environments- IaaS platforms,
cloud frameworks and APIs- Energy-efficient and power-aware virtualization-
Configuration management tools for containers (including in OpenStack,
Ansible, i.a.)- ARM-based hypervisors, ARM virtualization extensionsSpecial
Track: GPU - Accelerator 

Re: [Xen-devel] [PATCH 3/7] xen/arm: vpsci: Add support for PSCI 1.1

[Volodymyr Babchuk]

Hi,

On 5 February 2018 at 15:20, Julien Grall  wrote:
> At the moment, Xen provides virtual PSCI interface compliant with 0.1
> and 0.2. Since them, the specification has been updated and the latest
> version is 1.1 (see ARM DEN 0022D).
>
> From an implementation point of view, only PSCI_FEATURES is mandatory.
> The rest is optional and can be left unimplemented for now.
>
> At the same time, the compatible for PSCI node have been updated to
> expose "arm,psci-1.0".
>
> Signed-off-by: Julien Grall 
> Cc: Wei Liu 
> Cc: Ian Jackson 
> Cc: mirela.simono...@aggios.com
>
> ---
> We may want to provide a way for the toolstack to specify a PSCI
> version. This could be useful if a guest is expecting a given
> version.
> ---
>  tools/libxl/libxl_arm.c  |  3 ++-
>  xen/arch/arm/domain_build.c  |  1 +
>  xen/arch/arm/vpsci.c | 34 +-
>  xen/include/asm-arm/perfc_defn.h |  1 +
>  xen/include/asm-arm/psci.h   |  1 +
>  xen/include/asm-arm/vpsci.h  |  2 +-
>  6 files changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index 3e46554301..86f59c0d80 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -410,7 +410,8 @@ static int make_psci_node(libxl__gc *gc, void *fdt)
>  res = fdt_begin_node(fdt, "psci");
>  if (res) return res;
>
> -res = fdt_property_compat(gc, fdt, 2, "arm,psci-0.2","arm,psci");
> +res = fdt_property_compat(gc, fdt, 3, "arm,psci-1.0",
> +  "arm,psci-0.2", "arm,psci");
>  if (res) return res;
>
>  res = fdt_property_string(fdt, "method", "hvc");
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 155c952349..941688a2ce 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -637,6 +637,7 @@ static int make_psci_node(void *fdt, const struct 
> dt_device_node *parent)
>  {
>  int res;
>  const char compat[] =
> +"arm,psci-1.0""\0"
>  "arm,psci-0.2""\0"
>  "arm,psci";
>
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 17dab42cf4..025250a119 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -115,7 +115,7 @@ static int32_t do_psci_cpu_off(uint32_t power_state)
>
>  static uint32_t do_psci_0_2_version(void)
>  {
> -return PSCI_VERSION(0, 2);
> +return PSCI_VERSION(1, 0);
>  }
I'm confused a bit with the versions. In the commit message you
mentioned version 1.1. But there you return version 1,0 from a
function named do_psci_0_2_version().

>
>  static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
> @@ -199,6 +199,28 @@ static void do_psci_0_2_system_reset(void)
>  domain_shutdown(d,SHUTDOWN_reboot);
>  }
>
> +static int32_t do_psci_1_0_features(uint32_t psci_func_id)
> +{
> +switch ( psci_func_id )
> +{
> +case PSCI_0_2_FN32_PSCI_VERSION:
> +case PSCI_0_2_FN32_CPU_OFF:
> +case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
> +case PSCI_0_2_FN32_SYSTEM_OFF:
> +case PSCI_0_2_FN32_SYSTEM_RESET:
> +case PSCI_0_2_FN32_CPU_ON:
> +case PSCI_0_2_FN64_CPU_ON:
> +case PSCI_0_2_FN32_CPU_SUSPEND:
> +case PSCI_0_2_FN64_CPU_SUSPEND:
> +case PSCI_0_2_FN32_AFFINITY_INFO:
> +case PSCI_0_2_FN64_AFFINITY_INFO:
> +case PSCI_1_0_FN32_PSCI_FEATURES:
Are those functions sorted in a some order?

> +return 0;
> +default:
> +return PSCI_NOT_SUPPORTED;
> +}
> +}
> +
>  #define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
>  #define PSCI_ARG(reg, n) get_user_reg(reg, n)
>
> @@ -311,6 +333,16 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
> uint32_t fid)
>  PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
>  return true;
>  }
> +
> +case PSCI_1_0_FN32_PSCI_FEATURES:
> +{
> +uint32_t psci_func_id = PSCI_ARG32(regs, 1);
> +
> +perfc_incr(vpsci_features);
> +PSCI_SET_RESULT(regs, do_psci_1_0_features(psci_func_id));
> +return true;
> +}
> +
>  default:
>  return false;
>  }
> diff --git a/xen/include/asm-arm/perfc_defn.h 
> b/xen/include/asm-arm/perfc_defn.h
> index a7acb7d21c..87866264ca 100644
> --- a/xen/include/asm-arm/perfc_defn.h
> +++ b/xen/include/asm-arm/perfc_defn.h
> @@ -31,6 +31,7 @@ PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
>  PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
>  PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
>  PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
> +PERFCOUNTER(vpsci_features,"vpsci: features")
>
>  PERFCOUNTER(vgicd_reads,"vgicd: read")
>  PERFCOUNTER(vgicd_writes,   "vgicd: write")
> diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
> index 

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Jan Beulich]

>>> On 05.02.18 at 22:18,  wrote:
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -34,7 +34,8 @@
>  #include 
>  
>  unsigned int nmi_watchdog = NMI_NONE;
> -static unsigned int nmi_hz = HZ;
> +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs */
> +static unsigned int nmi_hz = HZ / 10;

For one - the comment should explain what "too high" means.
Further - what if on another system 10Hz is still too high? I also hope
you realize that you slow down boot a little for everyone just
because of this one machine model. Can the lower frequency perhaps
be set via DMI quirk, or otherwise obtain a command line override
(perhaps something like "watchdog=probe:10Hz")?

Jan


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

Re: [Xen-devel] [PATCH v4 3/7] libxl: introduce a new structure to represent static shared memory regions

[Zhongze Liu]

Hi,

2018-02-06 23:46 GMT+08:00 Julien Grall :
> Hi,
>
> On 02/06/2018 03:41 PM, Zhongze Liu wrote:
>>
>> Thanks for reviewing.
>>
>> 2018-02-06 19:27 GMT+08:00 Julien Grall :
>>>
>>> Hi,
>>>
>>> On 01/30/2018 05:50 PM, Zhongze Liu wrote:


 Add a new structure to the IDL familiy to represent static shared memory
 regions
>>
>>
>> [...]
>>
 +libxl_static_shm = Struct("static_shm", [
 +("id", string),
 +("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
 +("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
 +("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
>>>
>>>
>>>
>>> We might want to store the size rather than the end. This would allow us
>>> to
>>> cover region up to the address 2^64-1.
>>>
>>> Also, this would make clearer whether end is included in the region or
>>> not.
>>>
>>
>> I think making the range inclusive and documenting it would have the
>> same effect.
>> But I'm not sure which syntax is more friendly to the users. What do you
>> think?
>
>
> You would still run into some problem. Indeed LIBX_SSHM_RANGE_UNKNOWN is
> defined as UINT64_MAX. So how would you differentiate them?

But saying inclusive, I was actually trying to say "including the page
that begins at @end", so
the only possibility when  LIBXL_SSHM_RANGE_UNKNOWN would be a valid value for
@end is when the page granularity is 1byte, which, I think, is not
very likely to happen.

But soon I find this might lead to more confusion. Now I agree with
you that we should use
the begin/size syntax instead of the current one.

Cheers,

Zhongze Liu

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

Re: [Xen-devel] [PATCH v4 4/7] libxl: support mapping static shared memory areas during domain creation

[Zhongze Liu]

Hi Julien,

2018-02-06 21:07 GMT+08:00 Julien Grall :
> Hi,
>
> On 01/30/2018 05:50 PM, Zhongze Liu wrote:
>>
>> Add libxl__sshm_add to map shared pages from one DomU to another, The
>> mapping
>> process involves the follwing steps:

[...]

>> +
>> +/* Set default values for libxl_static_shm */
>> +int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
>> +   libxl_static_shm *sshm)
>> +{
>> +int rc;
>> +
>> +if (sshm->role == LIBXL_SSHM_ROLE_UNKNOWN)
>> +sshm->role = LIBXL_SSHM_ROLE_SLAVE;
>> +if (sshm->prot == LIBXL_SSHM_PROT_UNKNOWN)
>> +sshm->prot = LIBXL_SSHM_PROT_RW;
>
>
> What is the purpose of {ROLE,PROT}_UNKNOWN if you default it resp. to
> ROLE_SLAVE and PROT_RW.  Would not it be easier to just drop them?

The *_UNKNOWN values are used by the libxlu code to check whether a specific
option was set more than once. Without the default *_UNKNOWN value, I will not
be able to judge if, say, role is set to 'slave' by the user or not,
and therefore, if I
see the user setting role to 'master', I won't be able to tell if role
is specified twice
or not.

I think treating re-specification of options as errors will be good
for the users.

[...]

>> +
>> +/*   libxl__sshm_do_map -- map pages into slave's physmap
>> + *
>> + *   This functions maps
>> + * master gfn: [@msshm->begin + @sshm->offset, @msshm->end +
>> @sshm->offset)
>> + *   into
>> + * slave gfn: [@sshm->begin, @sshm->end)
>> + *
>> + *   The gfns of the pages that are successfully mapped will be stored
>> + *   in @mapped, and the number of the gfns will be stored in @nmapped.
>> + *
>> + *   The caller have to guarentee that sshm->begin < sshm->end and all
>> the
>
>
> s/have to/has to/ I think.
> s/guarentee/guarantee/
>
>> + *   values are page-aligned.
>
>
> Hmmm, I don't see the alignement check in libxl. So do you rely on the
> toolstack to do it?

Yes, This was done in libxlu_sshm.c.

Cheers,

Zhongze Liu

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

Re: [Xen-devel] [PATCH 2/7] xen/arm: psci: Rework the PSCI definitions

[Volodymyr Babchuk]

Hi,

On 5 February 2018 at 15:20, Julien Grall  wrote:
> Some PSCI functions are only available in the 32-bit version. After
> recent changes, Xen always needs to know whether the call was made using
> 32-bit id or 64-bit id. So we don't emulate reserved one.
>
> With the current naming scheme, it is not easy to know which call
> supports 32-bit and 64-bit id. So rework the definitions to encode the
> version in the name. From now the functions will be named PSCI_0_2_FNxx
> where xx is 32 or 64.
>
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

> ---
>  xen/arch/arm/platforms/seattle.c |  4 ++--
>  xen/arch/arm/psci.c  | 10 +-
>  xen/arch/arm/vpsci.c | 22 +++---
>  xen/include/asm-arm/psci.h   | 37 +
>  4 files changed, 39 insertions(+), 34 deletions(-)
>
> diff --git a/xen/arch/arm/platforms/seattle.c 
> b/xen/arch/arm/platforms/seattle.c
> index 22c062293f..893cc17972 100644
> --- a/xen/arch/arm/platforms/seattle.c
> +++ b/xen/arch/arm/platforms/seattle.c
> @@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst 
> =
>   */
>  static void seattle_system_reset(void)
>  {
> -call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
>  }
>
>  static void seattle_system_off(void)
>  {
> -call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
>  }
>
>  PLATFORM_START(seattle, "SEATTLE")
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index 1508a3be3a..5dda35cd7c 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -31,9 +31,9 @@
>   * (native-width) function ID.
>   */
>  #ifdef CONFIG_ARM_64
> -#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64(name)
> +#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64_##name
>  #else
> -#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32(name)
> +#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32_##name
>  #endif
>
>  uint32_t psci_ver;
> @@ -48,13 +48,13 @@ int call_psci_cpu_on(int cpu)
>  void call_psci_system_off(void)
>  {
>  if ( psci_ver > PSCI_VERSION(0, 1) )
> -call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_OFF, 0, 0, 0);
>  }
>
>  void call_psci_system_reset(void)
>  {
>  if ( psci_ver > PSCI_VERSION(0, 1) )
> -call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
> +call_smc(PSCI_0_2_FN32_SYSTEM_RESET, 0, 0, 0);
>  }
>
>  int __init psci_is_smc_method(const struct dt_device_node *psci)
> @@ -144,7 +144,7 @@ int __init psci_init_0_2(void)
>  }
>  }
>
> -psci_ver = call_smc(PSCI_0_2_FN32(PSCI_VERSION), 0, 0, 0);
> +psci_ver = call_smc(PSCI_0_2_FN32_PSCI_VERSION, 0, 0, 0);
>
>  /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
>  if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 
> )
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 359db884f9..17dab42cf4 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -250,35 +250,35 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
> uint32_t fid)
>   */
>  switch ( fid )
>  {
> -case PSCI_0_2_FN32(PSCI_VERSION):
> +case PSCI_0_2_FN32_PSCI_VERSION:
>  perfc_incr(vpsci_version);
>  PSCI_SET_RESULT(regs, do_psci_0_2_version());
>  return true;
>
> -case PSCI_0_2_FN32(CPU_OFF):
> +case PSCI_0_2_FN32_CPU_OFF:
>  perfc_incr(vpsci_cpu_off);
>  PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
>  return true;
>
> -case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
> +case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
>  perfc_incr(vpsci_migrate_info_type);
>  PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
>  return true;
>
> -case PSCI_0_2_FN32(SYSTEM_OFF):
> +case PSCI_0_2_FN32_SYSTEM_OFF:
>  perfc_incr(vpsci_system_off);
>  do_psci_0_2_system_off();
>  PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
>  return true;
>
> -case PSCI_0_2_FN32(SYSTEM_RESET):
> +case PSCI_0_2_FN32_SYSTEM_RESET:
>  perfc_incr(vpsci_system_reset);
>  do_psci_0_2_system_reset();
>  PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
>  return true;
>
> -case PSCI_0_2_FN32(CPU_ON):
> -case PSCI_0_2_FN64(CPU_ON):
> +case PSCI_0_2_FN32_CPU_ON:
> +case PSCI_0_2_FN64_CPU_ON:
>  {
>  register_t vcpuid = PSCI_ARG(regs, 1);
>  register_t epoint = PSCI_ARG(regs, 2);
> @@ -289,8 +289,8 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, 
> uint32_t fid)
>  return true;
>  }
>
> -case PSCI_0_2_FN32(CPU_SUSPEND):
> -case PSCI_0_2_FN64(CPU_SUSPEND):
> +case PSCI_0_2_FN32_CPU_SUSPEND:
> +case PSCI_0_2_FN64_CPU_SUSPEND:
>  {
>  uint32_t pstate = PSCI_ARG32(regs, 1);

[Xen-devel] [PATCH v3 0/3] xen/arm: SMCCC fixes and PSCI clean-up

[Julien Grall]

Hi all,

This small patch series contains SMCCC fixes (see #2) and PSCI clean-up.

Cheers,

Julien Grall (3):
  xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU
  xen/arm: vsmc: Don't implement function ID that doesn't exist
  xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

 xen/arch/arm/vpsci.c | 156 +--
 xen/arch/arm/vsmc.c  | 126 ---
 xen/include/asm-arm/perfc_defn.h |   2 -
 xen/include/asm-arm/psci.h   |  23 --
 xen/include/asm-arm/smccc.h  |  20 -
 xen/include/asm-arm/vpsci.h  |  42 +++
 6 files changed, 207 insertions(+), 162 deletions(-)
 create mode 100644 xen/include/asm-arm/vpsci.h

-- 
2.11.0


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

[Xen-devel] [PATCH v3 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

At the moment PSCI function dispatching is done in vsmc.c and the
function implementation in vpsci.c. Some bits of the implementation is
even done in vsmc.c (see PSCI_SYSTEM_RESET).

This means that it is difficult to follow the implementation and also
requires to export functions for each PSCI functions.

Therefore move PSCI dispatching in two new functions do_vpsci_0_1_call
and do_vpsci_0_2_call. The former will handle PSCI 0.1 call while the latter
0.2 or later call.

At the same time, a new header vpsci.h was created to contain all
definitions for virtual PSCI and avoid confusion with the host PSCI.

Signed-off-by: Julien Grall 

---
Changes in v3:
- Add copyright and emacs magic in vpsci.h
- Add a comment to update SCCC_SMCCC_*_REVISION once per
release

Changes in v2:
- Add a 'v' in the function names to help distinguish virtual vs
physical PSCI
- Introduce vpsci.h and VSCPI_NR_FUNCS
---
 xen/arch/arm/vpsci.c| 148 +++-
 xen/arch/arm/vsmc.c |  99 ++---
 xen/include/asm-arm/psci.h  |  19 --
 xen/include/asm-arm/vpsci.h |  42 +
 4 files changed, 182 insertions(+), 126 deletions(-)
 create mode 100644 xen/include/asm-arm/vpsci.h

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index 979d32ed6d..03fd4eb5b5 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -16,7 +16,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 #include 
@@ -91,12 +91,12 @@ static int do_common_cpu_on(register_t target_cpu, 
register_t entry_point,
 return PSCI_SUCCESS;
 }
 
-int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
+static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
 {
 return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
 }
 
-int32_t do_psci_cpu_off(uint32_t power_state)
+static int32_t do_psci_cpu_off(uint32_t power_state)
 {
 struct vcpu *v = current;
 if ( !test_and_set_bit(_VPF_down, >pause_flags) )
@@ -104,13 +104,14 @@ int32_t do_psci_cpu_off(uint32_t power_state)
 return PSCI_SUCCESS;
 }
 
-uint32_t do_psci_0_2_version(void)
+static uint32_t do_psci_0_2_version(void)
 {
 return PSCI_VERSION(0, 2);
 }
 
-register_t do_psci_0_2_cpu_suspend(uint32_t power_state, register_t 
entry_point,
-register_t context_id)
+static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,
+  register_t entry_point,
+  register_t context_id)
 {
 struct vcpu *v = current;
 
@@ -123,13 +124,14 @@ register_t do_psci_0_2_cpu_suspend(uint32_t power_state, 
register_t entry_point,
 return PSCI_SUCCESS;
 }
 
-int32_t do_psci_0_2_cpu_off(void)
+static int32_t do_psci_0_2_cpu_off(void)
 {
 return do_psci_cpu_off(0);
 }
 
-int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t entry_point,
-   register_t context_id)
+static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
+  register_t entry_point,
+  register_t context_id)
 {
 return do_common_cpu_on(target_cpu, entry_point, context_id,
 PSCI_VERSION(0, 2));
@@ -144,8 +146,8 @@ static const unsigned long target_affinity_mask[] = {
 #endif
 };
 
-int32_t do_psci_0_2_affinity_info(register_t target_affinity,
-  uint32_t lowest_affinity_level)
+static int32_t do_psci_0_2_affinity_info(register_t target_affinity,
+ uint32_t lowest_affinity_level)
 {
 struct domain *d = current->domain;
 struct vcpu *v;
@@ -172,23 +174,141 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-uint32_t do_psci_0_2_migrate_info_type(void)
+static uint32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
 
-void do_psci_0_2_system_off( void )
+static void do_psci_0_2_system_off( void )
 {
 struct domain *d = current->domain;
 domain_shutdown(d,SHUTDOWN_poweroff);
 }
 
-void do_psci_0_2_system_reset(void)
+static void do_psci_0_2_system_reset(void)
 {
 struct domain *d = current->domain;
 domain_shutdown(d,SHUTDOWN_reboot);
 }
 
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
+#define PSCI_ARG(reg, n) get_user_reg(reg, n)
+
+#ifdef CONFIG_ARM_64
+#define PSCI_ARG32(reg, n) (uint32_t)(get_user_reg(reg, n))
+#else
+#define PSCI_ARG32(reg, n) PSCI_ARG(reg, n)
+#endif
+
+/*
+ * PSCI 0.1 calls. It will return false if the function ID is not
+ * handled.
+ */
+bool do_vpsci_0_1_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+switch ( (uint32_t)get_user_reg(regs, 0) )
+{
+case PSCI_cpu_off:
+{
+uint32_t pstate = PSCI_ARG32(regs, 1);
+
+perfc_incr(vpsci_cpu_off);
+

[Xen-devel] [PATCH v3 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

[Julien Grall]

The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.

However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64. This is the case of:
* PSCI_VERSION
* CPU_OFF
* MIGRATE_INFO_TYPE
* SYSTEM_OFF
* SYSTEM_RESET

Similarly call count, call uid, revision can only be query using smc32/hvc32
fast calls (See 6.2 in ARM DEN 0028B).

Xen should only implement identifier existing in the specification in
order to avoid potential clash with later revision. Therefore rework the
vsmc code to use the whole function identifier rather than only the
function number.

At the same time, the new macros for call count, call uid, revision are
renamed to better suit the spec.

Lastly, update SSSC_SMCCC_FUNCTION_COUNT to match the correct number of
funtions. Note that version is not updated because the number has always
been wrong, and nobody could properly use it.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
This should be backported to Xen 4.10 as we should not implement
functions identifier that does not exist toprevent clash with a
later revision.

Changes in v3:
- Add Volodymyr's reviewed-by

Changes in v2:
- Rename the call count, call uid, revision macros
- Update SSSC_SMCCC_FUNCTION_COUNT
---
 xen/arch/arm/vsmc.c | 39 ++-
 xen/include/asm-arm/smccc.h | 20 +---
 2 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 997f2e0ebc..3d8cbcc808 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -28,7 +28,7 @@
 #define XEN_SMCCC_FUNCTION_COUNT 3
 
 /* Number of functions currently supported by Standard Service Service Calls. 
*/
-#define SSSC_SMCCC_FUNCTION_COUNT 11
+#define SSSC_SMCCC_FUNCTION_COUNT 14
 
 static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)
 {
@@ -84,13 +84,15 @@ static bool fill_function_call_count(struct cpu_user_regs 
*regs, uint32_t cnt)
 /* SMCCC interface for hypervisor. Tell about itself. */
 static bool handle_hypervisor(struct cpu_user_regs *regs)
 {
-switch ( smccc_get_fn(get_user_reg(regs, 0)) )
+uint32_t fid = (uint32_t)get_user_reg(regs, 0);
+
+switch ( fid )
 {
-case ARM_SMCCC_FUNC_CALL_COUNT:
+case ARM_SMCCC_CALL_COUNT_FID(HYPERVISOR):
 return fill_function_call_count(regs, XEN_SMCCC_FUNCTION_COUNT);
-case ARM_SMCCC_FUNC_CALL_UID:
+case ARM_SMCCC_CALL_UID_FID(HYPERVISOR):
 return fill_uid(regs, XEN_SMCCC_UID);
-case ARM_SMCCC_FUNC_CALL_REVISION:
+case ARM_SMCCC_REVISION_FID(HYPERVISOR):
 return fill_revision(regs, XEN_SMCCC_MAJOR_REVISION,
  XEN_SMCCC_MINOR_REVISION);
 default:
@@ -140,36 +142,37 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 {
 uint32_t fid = (uint32_t)get_user_reg(regs, 0);
 
-switch ( smccc_get_fn(fid) )
+switch ( fid )
 {
-case PSCI_0_2_FN_PSCI_VERSION:
+case PSCI_0_2_FN32(PSCI_VERSION):
 perfc_incr(vpsci_version);
 PSCI_SET_RESULT(regs, do_psci_0_2_version());
 return true;
 
-case PSCI_0_2_FN_CPU_OFF:
+case PSCI_0_2_FN32(CPU_OFF):
 perfc_incr(vpsci_cpu_off);
 PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 return true;
 
-case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+case PSCI_0_2_FN32(MIGRATE_INFO_TYPE):
 perfc_incr(vpsci_migrate_info_type);
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case PSCI_0_2_FN_SYSTEM_OFF:
+case PSCI_0_2_FN32(SYSTEM_OFF):
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN_SYSTEM_RESET:
+case PSCI_0_2_FN32(SYSTEM_RESET):
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case PSCI_0_2_FN_CPU_ON:
+case PSCI_0_2_FN32(CPU_ON):
+case PSCI_0_2_FN64(CPU_ON):
 {
 register_t vcpuid = PSCI_ARG(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -180,7 +183,8 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 }
 
-case PSCI_0_2_FN_CPU_SUSPEND:
+case PSCI_0_2_FN32(CPU_SUSPEND):
+case PSCI_0_2_FN64(CPU_SUSPEND):
 {
 uint32_t pstate = PSCI_ARG32(regs, 1);
 register_t epoint = PSCI_ARG(regs, 2);
@@ -191,7 +195,8 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 }
 
-case PSCI_0_2_FN_AFFINITY_INFO:
+case PSCI_0_2_FN32(AFFINITY_INFO):
+case PSCI_0_2_FN64(AFFINITY_INFO):
 {
 register_t taff = 

[Xen-devel] [PATCH v3 1/3] xen/arm: vpsci: Removing dummy MIGRATE and MIGRATE_INFO_UP_CPU

[Julien Grall]

The PSCI call MIGRATE and MIGRATE_INFO_UP_CPU are optional and
implemented as just returning PSCI_NOT_SUPPORTED (aka UNKNOWN_FUNCTION
for SMCCC).

The new SMCCC framework is able to deal with unimplemented function and
return the proper error code. So remove the implementations for both
function.

Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

---
Changes in v3:
- Add Volodymyr reviewed-by

Changes in v2:
- Remove define in psci.h
- Update SSSC_SMCCC_FUNCTION_COUNT
---
 xen/arch/arm/vpsci.c | 10 --
 xen/arch/arm/vsmc.c  | 16 +---
 xen/include/asm-arm/perfc_defn.h |  2 --
 xen/include/asm-arm/psci.h   |  4 
 4 files changed, 1 insertion(+), 31 deletions(-)

diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
index cd724904ef..979d32ed6d 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -172,21 +172,11 @@ int32_t do_psci_0_2_affinity_info(register_t 
target_affinity,
 return PSCI_0_2_AFFINITY_LEVEL_OFF;
 }
 
-int32_t do_psci_0_2_migrate(uint32_t target_cpu)
-{
-return PSCI_NOT_SUPPORTED;
-}
-
 uint32_t do_psci_0_2_migrate_info_type(void)
 {
 return PSCI_0_2_TOS_MP_OR_NOT_PRESENT;
 }
 
-register_t do_psci_0_2_migrate_info_up_cpu(void)
-{
-return PSCI_NOT_SUPPORTED;
-}
-
 void do_psci_0_2_system_off( void )
 {
 struct domain *d = current->domain;
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index c9064de37a..997f2e0ebc 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -28,7 +28,7 @@
 #define XEN_SMCCC_FUNCTION_COUNT 3
 
 /* Number of functions currently supported by Standard Service Service Calls. 
*/
-#define SSSC_SMCCC_FUNCTION_COUNT 13
+#define SSSC_SMCCC_FUNCTION_COUNT 11
 
 static bool fill_uid(struct cpu_user_regs *regs, xen_uuid_t uuid)
 {
@@ -157,11 +157,6 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
-perfc_incr(vpsci_migrate_info_up_cpu);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
-return true;
-
 case PSCI_0_2_FN_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
@@ -206,15 +201,6 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 }
 
-case PSCI_0_2_FN_MIGRATE:
-{
-uint32_t tcpu = PSCI_ARG32(regs, 1);
-
-perfc_incr(vpsci_cpu_migrate);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate(tcpu));
-return true;
-}
-
 case ARM_SMCCC_FUNC_CALL_COUNT:
 return fill_function_call_count(regs, SSSC_SMCCC_FUNCTION_COUNT);
 
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index 5f957ee6ec..a7acb7d21c 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -27,12 +27,10 @@ PERFCOUNTER(vpsci_cpu_on,  "vpsci: cpu_on")
 PERFCOUNTER(vpsci_cpu_off, "vpsci: cpu_off")
 PERFCOUNTER(vpsci_version, "vpsci: version")
 PERFCOUNTER(vpsci_migrate_info_type,   "vpsci: migrate_info_type")
-PERFCOUNTER(vpsci_migrate_info_up_cpu, "vpsci: migrate_info_up_cpu")
 PERFCOUNTER(vpsci_system_off,  "vpsci: system_off")
 PERFCOUNTER(vpsci_system_reset,"vpsci: system_reset")
 PERFCOUNTER(vpsci_cpu_suspend, "vpsci: cpu_suspend")
 PERFCOUNTER(vpsci_cpu_affinity_info,   "vpsci: cpu_affinity_info")
-PERFCOUNTER(vpsci_cpu_migrate, "vpsci: cpu_migrate")
 
 PERFCOUNTER(vgicd_reads,"vgicd: read")
 PERFCOUNTER(vgicd_writes,   "vgicd: write")
diff --git a/xen/include/asm-arm/psci.h b/xen/include/asm-arm/psci.h
index 635ea5dae4..32c1f81f21 100644
--- a/xen/include/asm-arm/psci.h
+++ b/xen/include/asm-arm/psci.h
@@ -37,9 +37,7 @@ int32_t do_psci_0_2_cpu_on(register_t target_cpu, register_t 
entry_point,
register_t context_id);
 int32_t do_psci_0_2_affinity_info(register_t target_affinity,
   uint32_t lowest_affinity_level);
-int32_t do_psci_0_2_migrate(uint32_t target_cpu);
 uint32_t do_psci_0_2_migrate_info_type(void);
-register_t do_psci_0_2_migrate_info_up_cpu(void);
 void do_psci_0_2_system_off(void);
 void do_psci_0_2_system_reset(void);
 
@@ -57,9 +55,7 @@ void do_psci_0_2_system_reset(void);
 #define PSCI_0_2_FN_CPU_OFF 2
 #define PSCI_0_2_FN_CPU_ON  3
 #define PSCI_0_2_FN_AFFINITY_INFO   4
-#define PSCI_0_2_FN_MIGRATE 5
 #define PSCI_0_2_FN_MIGRATE_INFO_TYPE   6
-#define PSCI_0_2_FN_MIGRATE_INFO_UP_CPU 7
 #define PSCI_0_2_FN_SYSTEM_OFF  8
 #define PSCI_0_2_FN_SYSTEM_RESET9
 
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

On 06.02.18 17:39, Julien Grall wrote:



On 02/06/2018 03:28 PM, Volodymyr Babchuk wrote:

Hi Julien,

On 06.02.18 16:45, Julien Grall wrote:

[...]

+/*
+ * PSCI 0.2 or later calls. It will return false if the function 
ID is

+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+    /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated 
when

+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC 
requires this.


Meh, you can't rely on the SSSC revision most of the time as the 
version for PSCI is done through PSCI_get_version. I can add a 
comment if you want.


Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC 
as well. So you can write something like "ARM SMCCC requires that 
SSSC revision and function call count should be updated every time 
you add or remove a function"


Usually we update versioning number only once per release. I would 
follow the same approach for this one. So I would suggest




It is not stated clearly in SMCCC, but I've got a felling that 
revision belongs not to product version, but to SMC interface version. 
So I see no reason to change revision, if there was no changes to 
interface itself.

I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch 
series) which alters the interface.
At the end of the day this is closely tie to product revision. A new 
revision may produce change in the implementation and therefore the 
version will be bumped. But there are always exception when you do a 
release just for bug fix.


This is the same for Xen, we only change interface version if something 
major as changed. If nothing, then the version stays the same.




Then I'm okay with this. I just wanted to sure that we are on the same page.



"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding 
removing a function. SSCCC_SMCCC_*_REVISION should be updated once 
per Xen release".


And who will be responsible for this?


The first patch modifying the SMCCC implementation after the tree is 
re-opened. This is how we deal the rest of the versions in Xen, and it 
works.


I'm good with this then.


--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v4 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Julien Grall]

On 02/06/2018 03:44 PM, Andre Przywara wrote:

Hi,

On 06/02/18 14:21, Julien Grall wrote:

Hi Andre,

On 02/05/2018 04:19 PM, Andre Przywara wrote:

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves
abstraction.


I was expecting some explanation regarding the new locking order in the
commit message.


Well, there is no real change in the new locking order. We enter both
gic_route_irq_to_guest() and gic_remove_irq_from_guest() with the desc
lock held, then take the rank lock at some point in time and drop it
again. The only change is how long we hold the rank lock, but this
should have no effect, since we don't manipulate any virtual IRQ
properties (rank or not) in the code lines that are now no longer under
the lock.
I can try to summarise this in the commit message.


Sorry, somehow I wrote locking order when I was meant to say about how 
long you take the lock.


Something along what you say above looks good to me. What I want to 
avoid is running into a problem and wondering why the locking was modified.


Cheers,




Signed-off-by: Andre Przywara 
---
   xen/arch/arm/gic-vgic.c    | 36 
   xen/arch/arm/gic.c | 44
++--
   xen/include/asm-arm/vgic.h |  2 ++
   3 files changed, 48 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 1d5744ecc8..fff7c01ee8 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -397,6 +397,42 @@ void gic_dump_vgic_info(struct vcpu *v)
   printk("Pending irq=%d\n", p->irq);
   }
   +int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned
int virq,
+    struct irq_desc *desc, bool connect)
+{
+    unsigned long flags;
+    /* Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference. */


Please fix the coding style as requested in v3.


Ah, sorry, I forgot that over the rewrite.


+    struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
+    struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
+    struct pending_irq *p = irq_to_pending(v_target, virq);
+    int ret = 0;
+
+    ASSERT(connect && desc);


I am not sure why you allow desc to be non-NULL when disconnecting it
(see more below).


I consider passing the desc pointer in addition to the vIRQ number
redundant in case we want to drop the association. The only reason we do
this is to work around the somewhat opposite locking order. So this is a
property of the existing code, which I consider at least somewhat dodgy.

In order to allow changing this in the future (for instance with the new
VGIC), I introduced the "connect" parameter and decided to make "desc"
optional in case "connect" is false.
If we give it anyway, we check for a match, which is what we do with the
current code. So we keep this molly guard.


+
+    /* We are taking to rank lock to prevent parallel connections. */
+    vgic_lock_rank(v_target, rank, flags);
+
+    if ( connect )
+    {
+    /* The VIRQ should not be already enabled by the guest */
+    if ( !p->desc &&
+ !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+    p->desc = desc;
+    else
+    ret = -EBUSY;
+    }
+    else
+    {
+    if ( !desc || p->desc == desc )


 From a quick glance, no caller will have desc is NULL.


Yes, for now.


Even if it was,
it will not harm because p->desc will be set to NULL.


+    p->desc = NULL;
+    }

But likely you want to return an error if p->desc != desc as this is a
user input error. Ignoring it is a pretty bad.


Right, good point. Actually this is what I had in mind, but somehow
managed to derail it. Will fix it.

Thanks for the review!
Andre.


+
+    vgic_unlock_rank(v_target, rank, flags);
+
+    return ret;
+}
+
   /*
    * Local variables:
    * mode: C


Cheers,



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/7] libxl: introduce a new structure to represent static shared memory regions

[Julien Grall]

Hi,

On 02/06/2018 03:41 PM, Zhongze Liu wrote:

Thanks for reviewing.

2018-02-06 19:27 GMT+08:00 Julien Grall :

Hi,

On 01/30/2018 05:50 PM, Zhongze Liu wrote:


Add a new structure to the IDL familiy to represent static shared memory
regions


[...]


+libxl_static_shm = Struct("static_shm", [
+("id", string),
+("offset", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("begin", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),
+("end", uint64, {'init_val': 'LIBXL_SSHM_RANGE_UNKNOWN'}),



We might want to store the size rather than the end. This would allow us to
cover region up to the address 2^64-1.

Also, this would make clearer whether end is included in the region or not.



I think making the range inclusive and documenting it would have the
same effect.
But I'm not sure which syntax is more friendly to the users. What do you think?


You would still run into some problem. Indeed LIBX_SSHM_RANGE_UNKNOWN is 
defined as UINT64_MAX. So how would you differentiate them?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Andre Przywara]

Hi,

On 06/02/18 14:21, Julien Grall wrote:
> Hi Andre,
> 
> On 02/05/2018 04:19 PM, Andre Przywara wrote:
>> At the moment we happily access VGIC internal data structures like
>> the rank and struct pending_irq in gic.c, which should be VGIC agnostic.
>>
>> Factor out a new function vgic_connect_hw_irq(), which allows a virtual
>> IRQ to be connected to a hardware IRQ (using the hw bit in the LR).
>>
>> This removes said accesses to VGIC data structures and improves
>> abstraction.
> 
> I was expecting some explanation regarding the new locking order in the
> commit message.

Well, there is no real change in the new locking order. We enter both
gic_route_irq_to_guest() and gic_remove_irq_from_guest() with the desc
lock held, then take the rank lock at some point in time and drop it
again. The only change is how long we hold the rank lock, but this
should have no effect, since we don't manipulate any virtual IRQ
properties (rank or not) in the code lines that are now no longer under
the lock.
I can try to summarise this in the commit message.

>> Signed-off-by: Andre Przywara 
>> ---
>>   xen/arch/arm/gic-vgic.c    | 36 
>>   xen/arch/arm/gic.c | 44
>> ++--
>>   xen/include/asm-arm/vgic.h |  2 ++
>>   3 files changed, 48 insertions(+), 34 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
>> index 1d5744ecc8..fff7c01ee8 100644
>> --- a/xen/arch/arm/gic-vgic.c
>> +++ b/xen/arch/arm/gic-vgic.c
>> @@ -397,6 +397,42 @@ void gic_dump_vgic_info(struct vcpu *v)
>>   printk("Pending irq=%d\n", p->irq);
>>   }
>>   +int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned
>> int virq,
>> +    struct irq_desc *desc, bool connect)
>> +{
>> +    unsigned long flags;
>> +    /* Use vcpu0 to retrieve the pending_irq struct. Given that we only
>> + * route SPIs to guests, it doesn't make any difference. */
> 
> Please fix the coding style as requested in v3.

Ah, sorry, I forgot that over the rewrite.

>> +    struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
>> +    struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
>> +    struct pending_irq *p = irq_to_pending(v_target, virq);
>> +    int ret = 0;
>> +
>> +    ASSERT(connect && desc);
> 
> I am not sure why you allow desc to be non-NULL when disconnecting it
> (see more below).

I consider passing the desc pointer in addition to the vIRQ number
redundant in case we want to drop the association. The only reason we do
this is to work around the somewhat opposite locking order. So this is a
property of the existing code, which I consider at least somewhat dodgy.

In order to allow changing this in the future (for instance with the new
VGIC), I introduced the "connect" parameter and decided to make "desc"
optional in case "connect" is false.
If we give it anyway, we check for a match, which is what we do with the
current code. So we keep this molly guard.

>> +
>> +    /* We are taking to rank lock to prevent parallel connections. */
>> +    vgic_lock_rank(v_target, rank, flags);
>> +
>> +    if ( connect )
>> +    {
>> +    /* The VIRQ should not be already enabled by the guest */
>> +    if ( !p->desc &&
>> + !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
>> +    p->desc = desc;
>> +    else
>> +    ret = -EBUSY;
>> +    }
>> +    else
>> +    {
>> +    if ( !desc || p->desc == desc )
> 
> From a quick glance, no caller will have desc is NULL.

Yes, for now.

> Even if it was,
> it will not harm because p->desc will be set to NULL.
> 
>> +    p->desc = NULL;
>> +    }
> But likely you want to return an error if p->desc != desc as this is a
> user input error. Ignoring it is a pretty bad.

Right, good point. Actually this is what I had in mind, but somehow
managed to derail it. Will fix it.

Thanks for the review!
Andre.

>> +
>> +    vgic_unlock_rank(v_target, rank, flags);
>> +
>> +    return ret;
>> +}
>> +
>>   /*
>>    * Local variables:
>>    * mode: C
> 
> Cheers,
> 

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

Re: [Xen-devel] [PATCH 1/7] xen/arm: vpsci: Remove parameter 'ver' from do_common_cpu

[Volodymyr Babchuk]

Hi Julien,

On 5 February 2018 at 15:20, Julien Grall  wrote:
> Currently, the behavior of do_common_cpu will slightly change depending
> on the PSCI version passed in parameter. Looking at the code, more the
> specific 0.2 behavior could move out of the function or adapted for 0.1:
>
> - x0/r0 can be updated on PSCI 0.1 because general purpose registers
> are undefined upon CPU on.
> - PSCI 0.1 does not defined PSCI_ALREADY_ON. However, it would be
> safer to bail out if the CPU is already on.
>
> Based on this, the parameter 'ver' is removed and do_psci_cpu_on
> (implementation for PSCI 0.1) is adapted to avoid returning
> PSCI_ALREADY_ON.
>
> Signed-off-by: Julien Grall 
Reviewed-by: Volodymyr Babchuk 

> ---
>  xen/arch/arm/vpsci.c | 28 ++--
>  1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/arm/vpsci.c b/xen/arch/arm/vpsci.c
> index 884f0fa710..359db884f9 100644
> --- a/xen/arch/arm/vpsci.c
> +++ b/xen/arch/arm/vpsci.c
> @@ -22,7 +22,7 @@
>  #include 
>
>  static int do_common_cpu_on(register_t target_cpu, register_t entry_point,
> -   register_t context_id,int ver)
> +register_t context_id)
>  {
>  struct vcpu *v;
>  struct domain *d = current->domain;
> @@ -40,8 +40,7 @@ static int do_common_cpu_on(register_t target_cpu, 
> register_t entry_point,
>  if ( is_64bit_domain(d) && is_thumb )
>  return PSCI_INVALID_PARAMETERS;
>
> -if ( (ver == PSCI_VERSION(0, 2)) &&
> -!test_bit(_VPF_down, >pause_flags) )
> +if ( !test_bit(_VPF_down, >pause_flags) )
>  return PSCI_ALREADY_ON;
>
>  if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
> @@ -55,18 +54,21 @@ static int do_common_cpu_on(register_t target_cpu, 
> register_t entry_point,
>  ctxt->ttbr0 = 0;
>  ctxt->ttbr1 = 0;
>  ctxt->ttbcr = 0; /* Defined Reset Value */
> +
> +/*
> + * x0/r0_usr are always updated because for PSCI 0.1 the general
> + * purpose registers are undefined upon CPU_on.
> + */
>  if ( is_32bit_domain(d) )
>  {
>  ctxt->user_regs.cpsr = PSR_GUEST32_INIT;
> -if ( ver == PSCI_VERSION(0, 2) )
> -ctxt->user_regs.r0_usr = context_id;
> +ctxt->user_regs.r0_usr = context_id;
>  }
>  #ifdef CONFIG_ARM_64
>  else
>  {
>  ctxt->user_regs.cpsr = PSR_GUEST64_INIT;
> -if ( ver == PSCI_VERSION(0, 2) )
> -ctxt->user_regs.x0 = context_id;
> +ctxt->user_regs.x0 = context_id;
>  }
>  #endif
>
> @@ -93,7 +95,14 @@ static int do_common_cpu_on(register_t target_cpu, 
> register_t entry_point,
>
>  static int32_t do_psci_cpu_on(uint32_t vcpuid, register_t entry_point)
>  {
> -return do_common_cpu_on(vcpuid, entry_point, 0 , PSCI_VERSION(0, 1));
> +int32_t ret;
> +
> +ret = do_common_cpu_on(vcpuid, entry_point, 0);
> +/*
> + * PSCI 0.1 does not define the return code PSCI_ALREADY_ON.
> + * Instead, return PSCI_INVALID_PARAMETERS.
> + */
> +return (ret == PSCI_ALREADY_ON) ? PSCI_INVALID_PARAMETERS : ret;
>  }
>
>  static int32_t do_psci_cpu_off(uint32_t power_state)
> @@ -133,8 +142,7 @@ static int32_t do_psci_0_2_cpu_on(register_t target_cpu,
>register_t entry_point,
>register_t context_id)
>  {
> -return do_common_cpu_on(target_cpu, entry_point, context_id,
> -PSCI_VERSION(0, 2));
> +return do_common_cpu_on(target_cpu, entry_point, context_id);
>  }
>
>  static const unsigned long target_affinity_mask[] = {
> --
> 2.11.0
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel



-- 
WBR Volodymyr Babchuk aka lorc [+380976646013]
mailto: vlad.babc...@gmail.com

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

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Julien Grall]

On 02/06/2018 03:28 PM, Volodymyr Babchuk wrote:

Hi Julien,

On 06.02.18 16:45, Julien Grall wrote:

[...]

+/*
+ * PSCI 0.2 or later calls. It will return false if the function 
ID is

+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+    /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated 
when

+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC 
requires this.


Meh, you can't rely on the SSSC revision most of the time as the 
version for PSCI is done through PSCI_get_version. I can add a 
comment if you want.


Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC 
as well. So you can write something like "ARM SMCCC requires that 
SSSC revision and function call count should be updated every time 
you add or remove a function"


Usually we update versioning number only once per release. I would 
follow the same approach for this one. So I would suggest




It is not stated clearly in SMCCC, but I've got a felling that revision 
belongs not to product version, but to SMC interface version. So I see 
no reason to change revision, if there was no changes to interface itself.

I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch 
series) which alters the interface.
At the end of the day this is closely tie to product revision. A new 
revision may produce change in the implementation and therefore the 
version will be bumped. But there are always exception when you do a 
release just for bug fix.


This is the same for Xen, we only change interface version if something 
major as changed. If nothing, then the version stays the same.




"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding 
removing a function. SSCCC_SMCCC_*_REVISION should be updated once per 
Xen release".


And who will be responsible for this?


The first patch modifying the SMCCC implementation after the tree is 
re-opened. This is how we deal the rest of the versions in Xen, and it 
works.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

[Julien Grall]

On 02/06/2018 03:15 PM, Volodymyr Babchuk wrote:

Hi Julien,


Hi,


On 06.02.18 16:53, Julien Grall wrote:

On 02/02/2018 01:46 PM, Volodymyr Babchuk wrote:



On 02.02.18 13:41, Julien Grall wrote:

The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.

However, PSCI call are only available in the range 
0x8400-0x841F

and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64. This is the case of:
 * PSCI_VERSION
 * CPU_OFF
 * MIGRATE_INFO_TYPE
 * SYSTEM_OFF
 * SYSTEM_RESET

Similarly call count, call uid, revision can only be query using 
smc32/hvc32

fast calls (See 6.2 in ARM DEN 0028B).

Xen should only implement identifier existing in the specification in
order to avoid potential clash with later revision. Therefore rework 
the

vsmc code to use the whole function identifier rather than only the
function number.

At the same time, the new macros for call count, call uid, revision are
renamed to better suit the spec.

Lastly, update SSSC_SMCCC_FUNCTION_COUNT to match the correct number of
funtions. Note that version is not updated because the number has 
always

been wrong, and nobody could properly use it.

Signed-off-by: Julien Grall 


`Reviewed-by: Volodymyr Babchuk `


Thank you for the reviewed-by. I noticed that you put ` at the 
beginning and end of the line in your reviewed-by tag so far. Is there 
any reason for that?


It is out of habit. You see, this is preferred way to add R-b tag at 
GitHub (or at least in OP-TEE repos). Github uses Markdown, and text in 
` becomes formatted as a code. I do code review mostly at github,
so it become a habit to add ` around R-b tags. You can ignore this, of 
course. I'll try to omit ` in the future.


Oh, good to know. I am usually copying the full line and my editor was 
not happy at all with the `. For Xen, we tend to only have the 
Reviewed-by tag on a line.


Anyway, thank you for reviewing the series :). I will resend a version soon.

If you have time, you might want to have a look at "xen/arm: PSCI 1.1 
and SMCCC-1.1 support and XSA-254 variant 2 update" [1].


Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2018-02/msg00285.html

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 3/3] xen/arm: vpsci: Move PSCI function dispatching from vsmc.c to vpsci.c

[Volodymyr Babchuk]

Hi Julien,

On 06.02.18 16:45, Julien Grall wrote:

[...]

+/*
+ * PSCI 0.2 or later calls. It will return false if the function 
ID is

+ * not handled.
+ */
+bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)
+{
+    /*
+ * /!\ VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when
+ * adding/removing a function
+ */
Should we also update revision of SSSC interface as well? SMCCC 
requires this.


Meh, you can't rely on the SSSC revision most of the time as the 
version for PSCI is done through PSCI_get_version. I can add a 
comment if you want.


Yes, I agree with you. But section 5.4 of SMCCC 1.0 applies to SSSC as 
well. So you can write something like "ARM SMCCC requires that SSSC 
revision and function call count should be updated every time you add 
or remove a function"


Usually we update versioning number only once per release. I would 
follow the same approach for this one. So I would suggest




It is not stated clearly in SMCCC, but I've got a felling that revision 
belongs not to product version, but to SMC interface version. So I see 
no reason to change revision, if there was no changes to interface itself.

I'm okay witch changing revision only one time per release, but only
if there was changes to PSCI interface. On other hand, person
responsible for release need to track if there was any changes in PSCI
and act accordingly. This is not very convenient.
So, I would prefer to change revision in the same patch (or patch 
series) which alters the interface.


"VPSCI_NR_FUNCS (in asm-arm/vpsci.h) should be updated when adding 
removing a function. SSCCC_SMCCC_*_REVISION should be updated once per 
Xen release".


And who will be responsible for this?

--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

[Volodymyr Babchuk]

Hi Julien,

On 06.02.18 16:53, Julien Grall wrote:

Hi Volodymyr,

On 02/02/2018 01:46 PM, Volodymyr Babchuk wrote:



On 02.02.18 13:41, Julien Grall wrote:

The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.

However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64. This is the case of:
 * PSCI_VERSION
 * CPU_OFF
 * MIGRATE_INFO_TYPE
 * SYSTEM_OFF
 * SYSTEM_RESET

Similarly call count, call uid, revision can only be query using 
smc32/hvc32

fast calls (See 6.2 in ARM DEN 0028B).

Xen should only implement identifier existing in the specification in
order to avoid potential clash with later revision. Therefore rework the
vsmc code to use the whole function identifier rather than only the
function number.

At the same time, the new macros for call count, call uid, revision are
renamed to better suit the spec.

Lastly, update SSSC_SMCCC_FUNCTION_COUNT to match the correct number of
funtions. Note that version is not updated because the number has always
been wrong, and nobody could properly use it.

Signed-off-by: Julien Grall 


`Reviewed-by: Volodymyr Babchuk `


Thank you for the reviewed-by. I noticed that you put ` at the beginning 
and end of the line in your reviewed-by tag so far. Is there any reason 
for that?


It is out of habit. You see, this is preferred way to add R-b tag at 
GitHub (or at least in OP-TEE repos). Github uses Markdown, and text in 
` becomes formatted as a code. I do code review mostly at github,
so it become a habit to add ` around R-b tags. You can ignore this, of 
course. I'll try to omit ` in the future.



--
Volodymyr Babchuk

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

Re: [Xen-devel] Xen Project Spectre / Meltdown FAQ (Jan 22 Update)

[Rich Persaud]

> On Jan 22, 2018, at 11:18, Lars Kurth  wrote:
> 
> Hi all,
> I will post the following new version of the FAQ on 
> https://blog.xenproject.org/ in a moment. As there are tables in it, I will 
> post as PDF rather than text. This thread is primarily a placeholder to post 
> further questions about these vulnerabilities.


I've added a link to the Technical FAQ, with a spreadsheet titled, "Meltdown 
and Spectre Analysis: Xen, Linux & Windows".  This was created for OpenXT, it 
may be useful to others.  It includes guest configurations, mitigations, Xen 
feature impact and x86 hardware features.  Revisions welcome.

https://wiki.xenproject.org/wiki/Xen_Project_Meltdown_and_Spectre_Technical_FAQ

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

Re: [Xen-devel] [PATCH v2 2/3] xen/arm: vsmc: Don't implement function ID that doesn't exist

[Julien Grall]

Hi Volodymyr,

On 02/02/2018 01:46 PM, Volodymyr Babchuk wrote:



On 02.02.18 13:41, Julien Grall wrote:

The current implementation of SMCCC relies on the fact only function
number (bits [15:0]) is enough to identify what to implement.

However, PSCI call are only available in the range 0x8400-0x841F
and 0xC400-0xC41F. Furthermore, not all SMC32 functions have
equivalent in the SMC64. This is the case of:
 * PSCI_VERSION
 * CPU_OFF
 * MIGRATE_INFO_TYPE
 * SYSTEM_OFF
 * SYSTEM_RESET

Similarly call count, call uid, revision can only be query using 
smc32/hvc32

fast calls (See 6.2 in ARM DEN 0028B).

Xen should only implement identifier existing in the specification in
order to avoid potential clash with later revision. Therefore rework the
vsmc code to use the whole function identifier rather than only the
function number.

At the same time, the new macros for call count, call uid, revision are
renamed to better suit the spec.

Lastly, update SSSC_SMCCC_FUNCTION_COUNT to match the correct number of
funtions. Note that version is not updated because the number has always
been wrong, and nobody could properly use it.

Signed-off-by: Julien Grall 


`Reviewed-by: Volodymyr Babchuk `


Thank you for the reviewed-by. I noticed that you put ` at the beginning 
and end of the line in your reviewed-by tag so far. Is there any reason 
for that?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 2/5] libxl: add vsnd list and info

[Wei Liu]

On Wed, Nov 01, 2017 at 05:04:44PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Add getting vsnd list amd info API
> 
> Signed-off-by: Oleksandr Grytsov 
> ---
>  tools/libxl/libxl.h |  10 ++
>  tools/libxl/libxl_types.idl |  19 +++
>  tools/libxl/libxl_utils.h   |   3 +
>  tools/libxl/libxl_vsnd.c| 375 
> +++-
>  4 files changed, 404 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 7200d49..acb73ce 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1927,6 +1927,16 @@ int libxl_device_vsnd_destroy(libxl_ctx *ctx, uint32_t 
> domid,
>const libxl_asyncop_how *ao_how)
>LIBXL_EXTERNAL_CALLERS_ONLY;
>  
> +libxl_device_vsnd *libxl_device_vsnd_list(libxl_ctx *ctx,
> +  uint32_t domid, int *num)
> +  LIBXL_EXTERNAL_CALLERS_ONLY;
> +void libxl_device_vsnd_list_free(libxl_device_vsnd* list, int num)
> + LIBXL_EXTERNAL_CALLERS_ONLY;
> +int libxl_device_vsnd_getinfo(libxl_ctx *ctx, uint32_t domid,
> +  libxl_device_vsnd *vsnd,
> +  libxl_vsndinfo *vsndlinfo)
> +  LIBXL_EXTERNAL_CALLERS_ONLY;
> +
>  /* Keyboard */
>  int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb 
> *vkb,
>   const libxl_asyncop_how *ao_how)
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index aa30196..553e724 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -988,6 +988,25 @@ libxl_vdisplinfo = Struct("vdisplinfo", [
>  ("connectors", Array(libxl_connectorinfo, "num_connectors"))
>  ], dir=DIR_OUT)
>  
> +libxl_streaminfo = Struct("streaminfo", [
> +("req_evtch", integer),
> +("req_rref", integer)
> +])
> +
> +libxl_pcminfo = Struct("pcminfo", [
> +("streams", Array(libxl_streaminfo, "num_vsnd_streams"))
> +])
> +
> +libxl_vsndinfo = Struct("vsndinfo", [
> +("backend", string),
> +("backend_id", uint32),
> +("frontend", string),
> +("frontend_id", uint32),
> +("devid", libxl_devid),
> +("state", integer),
> +("pcms", Array(libxl_pcminfo, "num_vsnd_pcms"))
> +])
> +
>  # NUMA node characteristics: size and free are how much memory it has, and 
> how
>  # much of it is free, respectively. dists is an array of distances from this
>  # node to each other node.
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 9e743dc..5455752 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -82,6 +82,9 @@ int libxl_devid_to_device_usbctrl(libxl_ctx *ctx, uint32_t 
> domid,
>  int libxl_devid_to_device_vdispl(libxl_ctx *ctx, uint32_t domid,
>   int devid, libxl_device_vdispl *vdispl);
>  
> +int libxl_devid_to_device_vsnd(libxl_ctx *ctx, uint32_t domid,
> +   int devid, libxl_device_vsnd *vsnd);
> +
>  int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, uint32_t domid,
>  int ctrl, int port,
>  libxl_device_usbdev *usbdev);
> diff --git a/tools/libxl/libxl_vsnd.c b/tools/libxl/libxl_vsnd.c
> index 99e4be3..35f1aed 100644
> --- a/tools/libxl/libxl_vsnd.c
> +++ b/tools/libxl/libxl_vsnd.c
> @@ -37,22 +37,247 @@ static int libxl__device_from_vsnd(libxl__gc *gc, 
> uint32_t domid,
> return 0;
>  }
>  
> +static int libxl__sample_rates_from_string(libxl__gc *gc, const char *str,
> +   libxl_vsnd_params *params)
> +{
> +char *tmp = libxl__strdup(gc, str);
> +
> +params->num_sample_rates = 0;
> +params->sample_rates = NULL;
> +
> +char *p = strtok(tmp, " ,");
> +
> +while (p != NULL) {
> +params->sample_rates = realloc(params->sample_rates,
> +   sizeof(*params->sample_rates) *
> +   (params->num_sample_rates + 1));

This is problematic. You need to check if realloc returns NULL before
overwriting sample_rates.

It is also a bit expensive to realloc 1 element at a time. Is is
possible to know the size before hand? If not, then fine.

Please use libxl__realloc instead. We have quite a few wrappers in
libxl. In general please use them unless you have very compelling reason
not to.

There could be other places in your two series that I missed, please fix
them.

Wei.

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

Re: [Xen-devel] [PATCH v1 1/5] libxl: add PV sound device

[Wei Liu]

On Wed, Nov 01, 2017 at 05:04:43PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Add PV sound device described in sndif.h
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

(I haven't checked if the values used in the IDL are the same in the
spec)

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

Re: [Xen-devel] [PATCH v1 3/5] xl: add PV sound condif parser

[Wei Liu]

On Wed, Nov 01, 2017 at 05:04:45PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Add config parser for virtual sound devices
> 
> Signed-off-by: Oleksandr Grytsov 
> +
> +int parse_vsnd_item(libxl_device_vsnd *vsnd, const char *spec)
> +{
> +char *buf = strdup(spec);
> +char *token = strtok(buf, ",");
> +char *key = NULL;
> +int ret;
> +
> +while(token) {

Add space please.

Otherwise:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1 5/5] docs: add PV sound device config

[Wei Liu]

On Wed, Nov 01, 2017 at 05:04:47PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Update documentation with virtual sound device
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Julien Grall]

On 02/06/2018 02:21 PM, Julien Grall wrote:

Hi Andre,

On 02/05/2018 04:19 PM, Andre Przywara wrote:

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves 
abstraction.


I was expecting some explanation regarding the new locking order in the 
commit message.


From a quick chat with Andre on IRC, it looks like figuring out the 
current locking might be tricky. So I would be happy if we only point 
out the change of locking (+ a word on the new locking) in the commit 
message.


This would help in case we find a regression later on.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] xenbus: track caller request id

[Juergen Gross]

On 02/02/18 18:42, Joao Martins wrote:
> Commit fd8aa9095a95 ("xen: optimize xenbus driver for multiple concurrent
> xenstore accesses") optimized xenbus concurrent accesses but in doing so
> broke UABI of /dev/xen/xenbus. Through /dev/xen/xenbus applications are in
> charge of xenbus message exchange with the correct header and body. Now,
> after the mentioned commit the replies received by application will no
> longer have the header req_id echoed back as it was on request (see
> specification below for reference), because that particular field is being
> overwritten by kernel.
> 
> struct xsd_sockmsg
> {
>   uint32_t type;  /* XS_??? */
>   uint32_t req_id;/* Request identifier, echoed in daemon's response.  */
>   uint32_t tx_id; /* Transaction id (0 if not related to a transaction). */
>   uint32_t len;   /* Length of data following this. */
> 
>   /* Generally followed by nul-terminated string(s). */
> };
> 
> Before there was only one request at a time so req_id could simply be
> forwarded back and forth. To allow simultaneous requests we need a
> different req_id for each message thus kernel keeps a monotonic increasing
> counter for this field and is written on every request irrespective of
> userspace value.
> 
> Forwarding again the req_id on userspace requests is not a solution because
> we would open the possibility of userspace-generated req_id colliding with
> kernel ones. So this patch instead takes another route which is to
> artificially keep user req_id while keeping the xenbus logic as is. We do
> that by saving the original req_id before xs_send(), use the private kernel
> counter as req_id and then once reply comes and was validated, we restore
> back the original req_id.
> 
> Cc:  # 4.11
> Fixes: fd8aa9095a ("xen: optimize xenbus driver for multiple concurrent 
> xenstore accesses")
> Reported-by: Bhavesh Davda 
> Signed-off-by: Joao Martins 

Reviewed-by: Juergen Gross 


Juergen

> ---
> Here's a link to a unit test (https://pastebin.com/2q51j2sR) where req_id of
> reply and response are being asserted each request. Without this patch
> the assert will fail (e.g. try it with `./xswire_reqid_test name`). But
> on <= v4.10 or >= v4.11 with the fix above, it will print domain name 10
> times.
> 
> Changes since v1:
>  * Adjust commit message
>  (Comments from Juergen on IRC)
>  * Unilateraly save/restore req_id and remove xs_request_is_user()
>  * Initialize req_id for kernel callers
> ---
>  drivers/xen/xenbus/xenbus.h   | 1 +
>  drivers/xen/xenbus/xenbus_comms.c | 1 +
>  drivers/xen/xenbus/xenbus_xs.c| 3 +++
>  3 files changed, 5 insertions(+)
> 
> diff --git a/drivers/xen/xenbus/xenbus.h b/drivers/xen/xenbus/xenbus.h
> index 149c5e7efc89..092981171df1 100644
> --- a/drivers/xen/xenbus/xenbus.h
> +++ b/drivers/xen/xenbus/xenbus.h
> @@ -76,6 +76,7 @@ struct xb_req_data {
>   struct list_head list;
>   wait_queue_head_t wq;
>   struct xsd_sockmsg msg;
> + uint32_t caller_req_id;
>   enum xsd_sockmsg_type type;
>   char *body;
>   const struct kvec *vec;
> diff --git a/drivers/xen/xenbus/xenbus_comms.c 
> b/drivers/xen/xenbus/xenbus_comms.c
> index 5b081a01779d..d239fc3c5e3d 100644
> --- a/drivers/xen/xenbus/xenbus_comms.c
> +++ b/drivers/xen/xenbus/xenbus_comms.c
> @@ -309,6 +309,7 @@ static int process_msg(void)
>   goto out;
>  
>   if (req->state == xb_req_state_wait_reply) {
> + req->msg.req_id = req->caller_req_id;
>   req->msg.type = state.msg.type;
>   req->msg.len = state.msg.len;
>   req->body = state.body;
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 3e59590c7254..3f3b29398ab8 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -227,6 +227,8 @@ static void xs_send(struct xb_req_data *req, struct 
> xsd_sockmsg *msg)
>   req->state = xb_req_state_queued;
>   init_waitqueue_head(>wq);
>  
> + /* Save the caller req_id and restore it later in the reply */
> + req->caller_req_id = req->msg.req_id;
>   req->msg.req_id = xs_request_enter(req);
>  
>   mutex_lock(_write_mutex);
> @@ -310,6 +312,7 @@ static void *xs_talkv(struct xenbus_transaction t,
>   req->num_vecs = num_vecs;
>   req->cb = xs_wake_up;
>  
> + msg.req_id = 0;
>   msg.tx_id = t.id;
>   msg.type = type;
>   msg.len = 0;
> 


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

Re: [Xen-devel] [PATCH v1 6/6] docs: add vkb device to xl.cfg and xl

[Wei Liu]

On Wed, Nov 01, 2017 at 05:05:07PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1 5/6] xl: add vkb config parser and CLI

[Wei Liu]

On Wed, Nov 01, 2017 at 05:05:06PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1 4/6] libxl: vkb add list and info functions

[Wei Liu]

On Wed, Nov 01, 2017 at 05:05:05PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1 4/6] libxl: vkb add list and info functions

[Wei Liu]

On Wed, Nov 01, 2017 at 05:05:05PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1 3/6] libxl: add backend type and id to vkb

[Wei Liu]

On Wed, Nov 01, 2017 at 05:05:04PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> New field backend_type is added to vkb device
> in order to have QEMU and user space backend
> simultaneously. Each vkb backend shall read
> appropriate XS entry and service only own
> frontends.
> Id is a string field which used by the backend
> to indentify the frontend.
> 
> Signed-off-by: Oleksandr Grytsov 
> ---
>  tools/libxl/libxl_create.c  |  3 +++
>  tools/libxl/libxl_dm.c  |  1 +
>  tools/libxl/libxl_types.idl |  8 
>  tools/libxl/libxl_vkb.c | 33 -
>  4 files changed, 44 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index f813114..60d8686 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -1376,6 +1376,9 @@ static void domcreate_launch_dm(libxl__egc *egc, 
> libxl__multidev *multidev,
>  for (i = 0; i < d_config->num_vfbs; i++) {
>  libxl__device_add(gc, domid, __vfb_devtype,
>_config->vfbs[i]);
> +}
> +
> +for (i = 0; i < d_config->num_vkbs; i++) {
>  libxl__device_add(gc, domid, __vkb_devtype,
>_config->vkbs[i]);
>  }
> diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> index 98f89a9..f07de35 100644
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -1728,6 +1728,7 @@ static int 
> libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc *gc,
>  
>  vkb->backend_domid = 0;
>  vkb->devid = 0;
> +

Stray change. I don't have objection though.

>  return 0;
>  }
>  
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index cd0c06f..c3876a2 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -240,6 +240,12 @@ libxl_checkpointed_stream = 
> Enumeration("checkpointed_stream", [
>  (2, "COLO"),
>  ])
>  
> +libxl_vkb_backend = Enumeration("vkb_backend", [
> +(0, "UNKNOWN"),
> +(1, "QEMU"),
> +(2, "LINUX")
> +])
> +
>  #
>  # Complex libxl types
>  #
> @@ -603,6 +609,8 @@ libxl_device_vkb = Struct("device_vkb", [
>  ("backend_domid", libxl_domid),
>  ("backend_domname", string),
>  ("devid", libxl_devid),
> +("backend_type", libxl_vkb_backend),
> +("id", string)
>  ])
>  
>  libxl_device_disk = Struct("device_disk", [
> diff --git a/tools/libxl/libxl_vkb.c b/tools/libxl/libxl_vkb.c
> index ea6fca8..88ab186 100644
> --- a/tools/libxl/libxl_vkb.c
> +++ b/tools/libxl/libxl_vkb.c
> @@ -17,6 +17,10 @@
>  static int libxl__device_vkb_setdefault(libxl__gc *gc, uint32_t domid,
>  libxl_device_vkb *vkb, bool hotplug)
>  {
> +if (vkb->backend_type == LIBXL_VKB_BACKEND_UNKNOWN) {
> +vkb->backend_type = LIBXL_VKB_BACKEND_QEMU;
> +}
> +
>  return libxl__resolve_domid(gc, vkb->backend_domname, 
> >backend_domid);
>  }
>  
> @@ -34,6 +38,30 @@ static int libxl__device_from_vkb(libxl__gc *gc, uint32_t 
> domid,
>  return 0;
>  }
>  
> +static int libxl__device_vkb_dm_needed(libxl_device_vkb *vkb, uint32_t domid)
> +{
> +   if (vkb->backend_type == LIBXL_VKB_BACKEND_QEMU) {
> +return 1;
> +   }

No need to have {} for a single statement here.

> +
> +return 0;
> +}
> +
> +static int libxl__set_xenstore_vkb(libxl__gc *gc, uint32_t domid,
> +   libxl_device_vkb *vkb,
> +   flexarray_t *back, flexarray_t *front,
> +   flexarray_t *ro_front)
> +{
> +if (vkb->id) {
> +flexarray_append_pair(front, "id", vkb->id);
> +}
> +

Ditto.

And, isn't 0 a valid device id?

Wei.

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Andrew Cooper]

On 06/02/18 03:10, Alexey G wrote:
> On Mon, 5 Feb 2018 21:18:42 +
> Igor Druzhinin  wrote:
>
>> We're noticing a reproducible system boot hang on certain
>> post-Skylake platforms where the BIOS is configured in
>> legacy boot mode with x2APIC disabled. The system stalls
>> immediately after writing the first SMP initialization
>> sequence into APIC ICR.
>>
>> The cause of the problem is watchdog NMI handler execution -
>> somewhere near the end of NMI handling (after it's already
>> rescheduled the next NMI) it tries to access IO port 0x61
>> to get the actual NMI reason on CPU0. Unfortunately, this
>> port is emulated by BIOS using SMIs and this emulation
>> apparently might take more than we expect under certain
>> conditions. As the result, the system is constantly moving
>> between NMI and SMI handler and not making any progress.
>>
>> Just lower the initial frequency for now as we lower it later
>> even more anyway.
> I/O port 61h normally is not emulated by SMI legacy kbd handling code
> in BIOS, only ports like 60h, 64h, etc.
> Contrary to USB legacy emulation, it has to intercept port 61h via a
> different approach -- generic SMI I/O trap, which is not common (at least
> it was) to use by BIOSes... although it is possible as EFI interface and
> code for this is available. The assumption about port 61h being trapped by
> the SMI handler must be explicitly confirmed by checking I/O Trap control
> regs in the RCBA region.
>
> If I/O trap regs won't show an active I/O trap on I/O port 61h -- the
> root cause might be different (might even be related to stuff like
> NMI2SMI logic).
>
> If the problem is actually due to NMI handler being preempted by another
> NMI which occurred after (a long) execution of triggered SMI handler, it
> might be better to do all sensitive stuff before re-enabling NMIs by IRET in
> the NMI handler.

The problem is that the SMI handler executes enough instructions to
trigger another NMI (which is based on the retired instruction count),
which gets delivered once the SMI handler returns, and servicing the NMI
triggers a new SMI, which triggers a new NMI.  This is why the system
stalls.

I'll leave the how/why port 0x61 is trapping to SMI to Igor, but it is
only a secondary concern here.  We cannot reasonably have the watchdog
able to trip because of exclusively SMI activity, or we'll potentially
livelock anywhere.

~Andrew

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

Re: [Xen-devel] [PATCH v4 6/8] ARM: VGIC: factor out vgic_get_hw_irq_desc()

[Julien Grall]

Hi Andre,

On 02/05/2018 04:19 PM, Andre Przywara wrote:

At the moment we happily access the VGIC internal struct pending_irq
(which describes a virtual IRQ) in irq.c.
Factor out the actually needed functionality to learn the associated
hardware IRQ and move that into gic-vgic.c to improve abstraction.

Signed-off-by: Andre Przywara 
Acked-by: Stefano Stabellini 


Reviewed-by: Julien Grall 

Cheers,


---
  xen/arch/arm/gic-vgic.c| 17 +
  xen/arch/arm/irq.c |  7 ++-
  xen/include/asm-arm/vgic.h |  2 ++
  3 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index fff7c01ee8..632c411565 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -397,6 +397,23 @@ void gic_dump_vgic_info(struct vcpu *v)
  printk("Pending irq=%d\n", p->irq);
  }
  
+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,

+  unsigned int virq)
+{
+struct pending_irq *p;
+
+ASSERT(!v && virq >= 32);
+
+if ( !v )
+v = d->vcpu[0];
+
+p = irq_to_pending(v, virq);
+if ( !p )
+return NULL;
+
+return p->desc;
+}
+
  int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
  struct irq_desc *desc, bool connect)
  {
diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index 7f133de549..62103a20e3 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -534,19 +534,16 @@ int release_guest_irq(struct domain *d, unsigned int virq)
  struct irq_desc *desc;
  struct irq_guest *info;
  unsigned long flags;
-struct pending_irq *p;
  int ret;
  
  /* Only SPIs are supported */

  if ( virq < NR_LOCAL_IRQS || virq >= vgic_num_irqs(d) )
  return -EINVAL;
  
-p = spi_to_pending(d, virq);

-if ( !p->desc )
+desc = vgic_get_hw_irq_desc(d, NULL, virq);
+if ( !desc )
  return -EINVAL;
  
-desc = p->desc;

-
  spin_lock_irqsave(>lock, flags);
  
  ret = -EINVAL;

diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index fda082395b..6ea9f140a7 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -219,6 +219,8 @@ int vgic_v2_init(struct domain *d, int *mmio_count);
  int vgic_v3_init(struct domain *d, int *mmio_count);
  
  bool vgic_evtchn_irq_pending(struct vcpu *v);

+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq);
  int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
  struct irq_desc *desc, bool connect);
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 5/8] ARM: VGIC: factor out vgic_connect_hw_irq()

[Julien Grall]

Hi Andre,

On 02/05/2018 04:19 PM, Andre Przywara wrote:

At the moment we happily access VGIC internal data structures like
the rank and struct pending_irq in gic.c, which should be VGIC agnostic.

Factor out a new function vgic_connect_hw_irq(), which allows a virtual
IRQ to be connected to a hardware IRQ (using the hw bit in the LR).

This removes said accesses to VGIC data structures and improves abstraction.


I was expecting some explanation regarding the new locking order in the 
commit message.




Signed-off-by: Andre Przywara 
---
  xen/arch/arm/gic-vgic.c| 36 
  xen/arch/arm/gic.c | 44 ++--
  xen/include/asm-arm/vgic.h |  2 ++
  3 files changed, 48 insertions(+), 34 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index 1d5744ecc8..fff7c01ee8 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -397,6 +397,42 @@ void gic_dump_vgic_info(struct vcpu *v)
  printk("Pending irq=%d\n", p->irq);
  }
  
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,

+struct irq_desc *desc, bool connect)
+{
+unsigned long flags;
+/* Use vcpu0 to retrieve the pending_irq struct. Given that we only
+ * route SPIs to guests, it doesn't make any difference. */


Please fix the coding style as requested in v3.


+struct vcpu *v_target = vgic_get_target_vcpu(d->vcpu[0], virq);
+struct vgic_irq_rank *rank = vgic_rank_irq(v_target, virq);
+struct pending_irq *p = irq_to_pending(v_target, virq);
+int ret = 0;
+
+ASSERT(connect && desc);


I am not sure why you allow desc to be non-NULL when disconnecting it 
(see more below).



+
+/* We are taking to rank lock to prevent parallel connections. */
+vgic_lock_rank(v_target, rank, flags);
+
+if ( connect )
+{
+/* The VIRQ should not be already enabled by the guest */
+if ( !p->desc &&
+ !test_bit(GIC_IRQ_GUEST_ENABLED, >status) )
+p->desc = desc;
+else
+ret = -EBUSY;
+}
+else
+{
+if ( !desc || p->desc == desc )


From a quick glance, no caller will have desc is NULL. Even if it was, 
it will not harm because p->desc will be set to NULL.



+p->desc = NULL;
+}
But likely you want to return an error if p->desc != desc as this is a 
user input error. Ignoring it is a pretty bad.



+
+vgic_unlock_rank(v_target, rank, flags);
+
+return ret;
+}
+
  /*
   * Local variables:
   * mode: C


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/nmi: lower initial watchdog frequency to avoid boot hangs

[Andrew Cooper]

On 05/02/18 21:18, Igor Druzhinin wrote:
> We're noticing a reproducible system boot hang on certain
> post-Skylake platforms where the BIOS is configured in

Its just a plain Skylake Server, from what I can see.

> legacy boot mode with x2APIC disabled. The system stalls
> immediately after writing the first SMP initialization
> sequence into APIC ICR.
>
> The cause of the problem is watchdog NMI handler execution -
> somewhere near the end of NMI handling (after it's already
> rescheduled the next NMI) it tries to access IO port 0x61
> to get the actual NMI reason on CPU0. Unfortunately, this
> port is emulated by BIOS using SMIs and this emulation
> apparently might take more than we expect under certain
> conditions. As the result, the system is constantly moving
> between NMI and SMI handler and not making any progress.
>
> Just lower the initial frequency for now as we lower it later
> even more anyway.
>
> Signed-off-by: Igor Druzhinin 

Acked-by: Andrew Cooper 

I can independently confirm these findings, and that the fix works.  The
NMI watchdog setup is rather crazy and complicated, but lets not get
into that rats nest here. */

> ---
>  xen/arch/x86/nmi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/nmi.c b/xen/arch/x86/nmi.c
> index d7fce28..1eb2a32 100644
> --- a/xen/arch/x86/nmi.c
> +++ b/xen/arch/x86/nmi.c
> @@ -34,7 +34,8 @@
>  #include 
>  
>  unsigned int nmi_watchdog = NMI_NONE;
> -static unsigned int nmi_hz = HZ;
> +/* initial watchdog frequency - shouldn't be too high to avoid boot hangs */
> +static unsigned int nmi_hz = HZ / 10;
>  static unsigned int nmi_perfctr_msr; /* the MSR to reset in NMI handler */
>  static unsigned int nmi_p4_cccr_val;
>  static DEFINE_PER_CPU(struct timer, nmi_timer);


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

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

[Julien Grall]

Hi,

On 02/05/2018 04:19 PM, Andre Przywara wrote:

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
new file mode 100644
index 00..263b430075
--- /dev/null
+++ b/xen/arch/arm/gic-vgic.c
@@ -0,0 +1,396 @@
+/*
+ * xen/arch/arm/gic-vgic.c
+ *
+ * ARM Generic Interrupt Controller virtualization support
+ *
+ * Tim Deegan 
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 


Please order them alphabetically. With that:

Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC] firmware/shim: fix Xen tree setup

[Wei Liu]

On Tue, Feb 06, 2018 at 05:45:18AM -0700, Jan Beulich wrote:
> >>> On 06.02.18 at 13:36,  wrote:
> > On Wed, Jan 31, 2018 at 09:55:21AM -0700, Jan Beulich wrote:
> >> - Excluding symlinks in the source tree is a problem for me: Short of
> >>   out-of-tree builds, in order to easily build test multiple
> >>   configurations, I'm setting up my build trees as trees of symlinks
> >>   into the source tree. Hence the original logic would find only the few
> >>   generated files under config/. I do realize though that find's -xtype
> >>   primary is a non-standard extension (explicitly having "! type -l"
> >>   seems pointless though, at least for standard conforming find, as
> >>   "-type f" is supposed to only find non-symlinked files).
> >> 
> > 
> > At the time I thought whatever symlinks we have in tree should be
> > created by xen's build system itself hence there was no need to copy
> > them around, and it would have to avoid latent problem like linking to
> > wrong files etc.
> > 
> > I think you have valid usecase for symlinks, so I'm fine with the change
> > you make.
> 
> The only symlinks I'm aware of are the ones putting some files from
> common/efi/ into arch/*/efi/. These are relative ones, so I was
> considering whether perhaps we should skip those but treat absolute
> ones like ordinary files. Do you have any opinion in that direction?

No opinion.

> 
> >> Irrespective of the changes I'm still observing "mkdir -p" to report a
> >> missing operand, as config/ has no subdirs. Oddly enough this doesn't
> >> cause the whole command (and hence the build to fail), despite the
> >> "set -e" now covering the entire set of commands - perhaps a quirk of
> >> the relatively old bash I've seen this with (a few simple experiments
> >> suggest that commands inside () producing a non-success status would
> >> exit the inner shell, but not the outer one).
> > 
> > I did see error when I wrote this bit hence I specifically hacked the
> > rune to preserve "." in the output. We can add that back if necessary.
> 
> Why was it dropped?

Because a few people touched this bit.

> 
> > I suppose you will send out a new version at some point?
> 
> Sure - I only need to (a) be clear about what changes to make and
> (b) find the time. Hopefully things will be easier once the Spectre v2
> backports are all done.
> 

OK. If you want me to help please let me know.

Wei.

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

[Xen-devel] [PATCH] x86/spec_ctrl: Fix determination of when to use IBRS

[Andrew Cooper]

The original version of this logic was:

/*
 * On Intel hardware, we'd like to use retpoline in preference to
 * IBRS, but only if it is safe on this hardware.
 */
else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
{
if ( retpoline_safe() )
thunk = THUNK_RETPOLINE;
else
ibrs = true;
}

but it was changed by a request during review.  Sadly, the result is buggy as
it breaks the later fallback logic by allowing IBRS to appear as available
when in fact it isn't.

This in practice means that on repoline-unsafe hardware without IBRS, we
select THUNK_JUMP despite intending to select THUNK_RETPOLINE.

Reported-by: Zhenzhong Duan 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Zhenzhong Duan 

This wants backporting to everywhere the SP2 series has gone
---
 xen/arch/x86/spec_ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
index f10ffbf..725626b 100644
--- a/xen/arch/x86/spec_ctrl.c
+++ b/xen/arch/x86/spec_ctrl.c
@@ -223,7 +223,7 @@ void __init init_speculation_mitigations(void)
  */
 else if ( retpoline_safe() )
 thunk = THUNK_RETPOLINE;
-else
+else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
 ibrs = true;
 }
 /* Without compiler thunk support, use IBRS if available. */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 7/7] docs: documentation about static shared memory regions

[Julien Grall]

Hi,

On 01/30/2018 05:50 PM, Zhongze Liu wrote:

Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.

This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:

   https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
  docs/man/xl-static-shm-configuration.pod.5 | 257 +
  docs/man/xl.cfg.pod.5.in   |   8 +
  docs/misc/xenstore-paths.markdown  |  47 ++
  3 files changed, 312 insertions(+)
  create mode 100644 docs/man/xl-static-shm-configuration.pod.5

diff --git a/docs/man/xl-static-shm-configuration.pod.5 
b/docs/man/xl-static-shm-configuration.pod.5
new file mode 100644
index 00..d68ed0ebf7
--- /dev/null
+++ b/docs/man/xl-static-shm-configuration.pod.5
@@ -0,0 +1,257 @@
+=head1 NAME
+
+xl-static-shm-configuration - XL Static Shared Memeory Configuration Syntax


s/Memeory/memory/


+
+
+(B: This is currently only available to ARM guests.)
+
+=head1 DESCRIPTION
+
+The static_shm option allows users to statically setup shared memory regions
+among a group of VMs, enabling guests without grant table support to do
+shm-based communication.
+
+Every shared region is:
+
+=over 4
+
+* Uniquely identified by a string that is no longer than 128 characters, which
+is called an B in this document.
+
+* Backed by exactely one domain, which is called a B domain, and all


s/exactely/exactly/


+the other domains who are also sharing this region are called Bs.
+
+=back
+
+=head1 SYNTAX
+
+This document specifies syntax of the static shared memory configuration in
+the xl config file. It has the following form:
+
+static_shm = [ "SSHM_SPEC", "SSHM_SPEC", ... ]
+
+where each C is in this form:
+
+[=,]*
+
+Valid examples of C are:
+
+id=ID1, begin=0x10, end=0x20, role=master, cache_policy=x86_normal
+id=ID1, offset = 0, begin=0x50, end=0x60, role=slave, prot=rw
+id=ID2, begin=0x30, end=0x40, role=master
+id=ID2, offset = 0x1, begin=0x69, end=0x80, role=slave
+id=ID2, offset = 0x1, begin=0x69, end=0x80, role=slave
+
+These might be specified in the domain config file like this:
+
+static_shm = ["id=ID2, offset = 0x1, begin=0x69, end=0x80,
+role=slave"]
+
+
+More formally, the string is a series of comma-separated keyword/value
+pairs. Each parameter may be specified at most once. Default values apply if
+the parameter is not specified.
+
+=head1 Parameters
+
+=over 4
+
+=item B
+
+=over 4
+
+=item Description
+
+The unique identifier of the shared memory region.
+
+Every identifier could appear only once in each xl config file.
+
+=item Supported values
+
+A string that contains alphanumerics and "_"s, and is no longer than 128
+characters.
+
+=item Default value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B/B
+
+=over 4
+
+=item Description
+
+The boundaries of the shared memory area.
+
+=item Supported values
+
+Same with B.
+
+=item Default Value
+
+None, this parameter is mandatory.
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+Can only appear when B = slave. If set, the address mapping will not
+start from the beginning the backing memory region, but from the middle
+(B bytes away from the beginning) of it. See the graph below:


s/offet/offset/


+
+With B = 0, the mapping will look like:
+
+  backing memory region:  #
+  |   |
+  |   |
+  |   |
+  V   V
+  slave's shared region:  #
+
+With B > 0:
+
+  backing memory region:   #
+   |<-- offset -->||   |
+   |   |
+   |   |
+   V   V
+  slave's memory region:   #
+
+=item Supported values
+
+Decimals or hexadecimals with a prefix "0x", and should be the multiple of the
+hypervisor page granularity (currently 4K on both ARM and x86).
+
+=item Default value
+
+0x0
+
+=back
+
+=item B
+
+=over 4
+
+=item Description
+
+The backing area would be taken from one domain, which we will mark
+as the "master domain", and this domain should be created prior to any
+other slave domains that depend on it.
+
+This arugment specifies the role of this domain.


s/arugment/argument/


+
+=item 

Re: [Xen-devel] [PATCH v4 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Julien Grall]

Hi,

On 01/30/2018 05:50 PM, Zhongze Liu wrote:

Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:

* For a master: decrease the refcount of the sshm region, if the refcount
   reaches 0, cleanup the whole sshm path.
* For a slave: 1) unmap the shared pages, and cleanup related xs entries. If
   the system works normally, all the shared pages will be unmapped, so there
   won't be page leaks. In case of errors, the unmapping process will go on and
   unmap all the other pages that can be unmapped, so the other pages won't
   be leaked, either. 2) Decrease the refcount of the sshm region, if the
   refcount reaches 0, cleanup the whole sshm path.


May I ask to add a newline line 1) and 2). This would make clearer the 2 
steps.




This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).

[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html

Signed-off-by: Zhongze Liu 

Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: xen-de...@lists.xen.org
---
  tools/libxl/libxl_domain.c   |   5 ++
  tools/libxl/libxl_internal.h |   2 +
  tools/libxl/libxl_sshm.c | 106 +++
  3 files changed, 113 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index 13b1c73d40..37f001554b 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1026,6 +1026,11 @@ void libxl__destroy_domid(libxl__egc *egc, 
libxl__destroy_domid_state *dis)
  goto out;
  }
  
+rc = libxl__sshm_del(gc, domid);

+if (rc) {
+LOGD(ERROR, domid, "Deleting static shm failed.");
+}
+
  if (libxl__device_pci_destroy_all(gc, domid) < 0)
  LOGD(ERROR, domid, "Pci shutdown failed");
  rc = xc_domain_pause(ctx->xch, domid);
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2cfe4c08a7..c398b6a6b8 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4424,6 +4424,8 @@ static inline bool libxl__string_is_default(char **s)
  _hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
  libxl_static_shm *sshm, int len);
  
+_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);

+
  _hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
libxl_static_shm *sshms, int len);
  _hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
index 562f46f299..1bf4d4c2dc 100644
--- a/tools/libxl/libxl_sshm.c
+++ b/tools/libxl/libxl_sshm.c
@@ -86,6 +86,112 @@ int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
  return 0;
  }
  
+/* Decrease the refcount of an sshm. When refcount reaches 0,


NIT: Libxl coding style regarding the comment seems to be uncleared 
(Ian, Wei?). But I feel keep /* and */ in separate line is nicer.



+ * clean up the whole sshm path.
+ */
+static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
+   const char *sshm_path)
+{
+int count;
+const char *count_path, *count_string;
+
+count_path = GCSPRINTF("%s/usercnt", sshm_path);
+if (libxl__xs_read_checked(gc, xt, count_path, _string))
+return;
+count = atoi(count_string);
+
+if (--count == 0) {
+libxl__xs_path_cleanup(gc, xt, sshm_path);
+return;
+}
+
+count_string = GCSPRINTF("%d", count);
+libxl__xs_write_checked(gc, xt, count_path, count_string);


See my comment about incref in a patch #4.


+
+return;
+}
+
+static void libxl__sshm_do_unmap(libxl__gc *gc, uint32_t domid, const char *id,
+ uint64_t begin, uint64_t end)
+{
+begin >>= XC_PAGE_SHIFT;
+end >>= XC_PAGE_SHIFT;
+for (; begin < end; ++begin) {
+if (xc_domain_remove_from_physmap(CTX->xch, domid, begin)) {
+SSHM_ERROR(domid, id,
+   "unable to unmap shared page at 0x%"PRIx64".",
+   begin);
+}
+}
+}
+
+static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
+  uint32_t domid, const char *id, bool isretry)
+{
+const char *slave_path, *begin_str, *end_str;
+uint64_t begin, end;
+
+slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
+
+begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin", slave_path));
+end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
+begin = strtoull(begin_str, NULL, 16);
+end = strtoull(end_str, NULL, 16);
+
+/* Avoid calling do_unmap many times in case of xs transaction retry */
+if (!isretry)
+libxl__sshm_do_unmap(gc, domid, id, begin, 

Re: [Xen-devel] 回复: Re: [PATCH] Choose retpoline only when it is safe to use

[Andrew Cooper]

On 06/02/18 12:30, Zhenzhong Duan wrote:
> 在 2018/2/6 19:56, Andrew Cooper 写道:
>> On 06/02/18 11:41, Zhenzhong Duan wrote:
>>> On 2018/2/6 18:50, Andrew Cooper wrote:
 On 06/02/18 10:29, zhenzhong.duan wrote:
>
>
> 2018年2月6日 17:20于 Andrew Cooper  >写道：
> >
> > On 06/02/2018 09:13, Zhenzhong Duan wrote:
> > > 在 2018/2/6 16:59, Andrew Cooper 写道:
> > >> On 06/02/2018 08:43, Zhenzhong Duan wrote:
> > >>> When ( ibrs && thunk == THUNK_DEFAULT && !retpoline_safe() )
> is true,
> > >>> thunk is set to THUNK_JMP rather than THUNK_RETPOLINE.
> > >>>
> > >>> When (!ibrs && thunk == THUNK_DEFAULT && !retpoline_safe() )
> is true,
> > >>> we should do the same.
> > >>>
> > >>> Signed-off-by: Zhenzhong Duan  >
> > >> Why?  What improvement is this intended to give?
> > > No improvement, I just feel if retpoline isn't safe, THUNK_JMP is
> > > better and safer.
> > > Above first check is working that way.
> >
> > If your only two choices are unsafe repoline or plain jumps,
> then unsafe
> > repoline is far far far safer.
> >
> > Its unsafe properties only kick in on an RSB underflow, and an
> attacker
> > would have to do call-depths analysis of the running binary to
> identify
> > which rets to attempt to poison.
> >
> Thanks for explaining.
> So, for a retpoline safe processor, it just stop using RSB when
> it's empty to avoid underflow?
>

 The qualification of whether a processor is retpoline-safe or not
 is whether an RSB underflow causes a BTB lookup (unsafe) or not (safe).

 RSB underflows will always occur; you cannot get rid of them, but
 in most cases (i.e. pre-Skylake) they don't fall back to using a
 prediction source which can be poisoned by an attacker.
>>> Understood.

> Another question:
>
> if (opt_thunk == THUNK_DEFAULT && opt_ibrs == -1 &&
> CONFIG_INDIRECT_THUNK && !cpu_has_lfence_dispatch &&
> !retpoline_safe())
> results in "thunk = THUNK_JMP" regardless of the value of
> "boot_cpu_has(X86_FEATURE_IBRSB)"
>

 Your formatting is hard to follow,
>>> Sorry, sent from mobile.
 but cpu_has_lfence_dispatch can only be false when virtualised
 under an SP2-unaware hypervisor on AMD hardware, at which point
 retpoline_safe() will return true.  Also, AMD don't have IBRS in
 microcode and their future plans don't appear to involve using that
 particular CPUID bit.
>>> That does make sense for AMD. But what about Intel hardware which
>>> has (!cpu_has_lfence_dispatch && !retpoline_safe() &&
>>> !boot_cpu_has(X86_FEATURE_IBRSB)), should we  prefer THUNK_RETPOLINE? 
>>
>> Yes, and we do end up choosing RETPOLINE in those circumstances, as
>> we hit the default case you originally tried to patch.
>
> If that's the case, I think we need another patch like below.
>
> @@ -223,7 +223,7 @@ void __init init_speculation_mitigations(void)
>   */
>  else if ( retpoline_safe() )
>  thunk = THUNK_RETPOLINE;
> -    else
> +    else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
>  ibrs = true;
>  }
>  /* Without compiler thunk support, use IBRS if available. */
>
> As ibrs was set to true when !boot_cpu_has(X86_FEATURE_IBRSB) with
> current code, then thunk was set to THUNK_JMP rather than THUNK_RETPOLINE.

You are correct.  This is a side effect of an optimisation which was
requested during review.  I'll draft a patch.

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

Re: [Xen-devel] [PATCH] libxl: add libxl__is_driver_domain function

[Oleksandr Grytsov]

On Tue, Feb 6, 2018 at 2:36 PM, Wei Liu  wrote:

> On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov 
> >
> > We have following arm-based setup:
> >
> > - Dom0 with xen and xen tools;
> > - Dom1 with device backends (but it is not the driver domain);
>
> What is your definition of a "driver domain"? What does it do in this
> case?
>
> I seem to have seen people use this term in different contexts to mean
> slightly different things. I need to figure out what you actually mean
> first.
>
>
I see in the libxl/xl sources that closing PV devices is done differently
in case backends are in Dom0 and are in other domain. It is called as
driver domain in the sources. So, I don't have clear understanding
what does it mean. In our setup backends are in Dom1 and xl is in Dom0.
And I see that xl dosn't close PV device on domain reboot or shutdown.


> > - Dom2 with device frontend;
> >
> > On Dom2 destroying we have timeout error. Because xl treats our
> > Dom1 as driver domain and waits for backend path to be cleared
> > by the driver domain which is not our case.
> >
> > According to libxl__domain_make in case of driver domain it has
> > "libxl" xen store entry:
> >
> > if (libxl_defbool_val(info->driver_domain)) {
> > /*
> >  * Create a local "libxl" directory for each guest, since we
> might want
> >  * to use libxl from inside the guest
> >  */
> > libxl__xs_mknod(gc, t, GCSPRINTF("%s/libxl", dom_path), rwperm,
> > ARRAY_SIZE(rwperm));
> >
> > This patch introduces libxl__is_driver_domain which determines the driver
> > domain by checking if "libxl" entry is present and uses this function on
> > device destroy to check by whom domain path should be cleaned up (libxl
> > or the driver domain).
> >
> > Oleksandr Grytsov (1):
> >   libxl: add libxl__is_driver_domain function
> >
> >  tools/libxl/libxl_device.c   | 17 ++---
> >  tools/libxl/libxl_internal.c | 16 
> >  tools/libxl/libxl_internal.h |  4 
> >  3 files changed, 30 insertions(+), 7 deletions(-)
> >
> > --
> > 2.7.4
> >
>



-- 
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC] firmware/shim: fix Xen tree setup

[Jan Beulich]

>>> On 06.02.18 at 13:36,  wrote:
> On Wed, Jan 31, 2018 at 09:55:21AM -0700, Jan Beulich wrote:
>> - Excluding symlinks in the source tree is a problem for me: Short of
>>   out-of-tree builds, in order to easily build test multiple
>>   configurations, I'm setting up my build trees as trees of symlinks
>>   into the source tree. Hence the original logic would find only the few
>>   generated files under config/. I do realize though that find's -xtype
>>   primary is a non-standard extension (explicitly having "! type -l"
>>   seems pointless though, at least for standard conforming find, as
>>   "-type f" is supposed to only find non-symlinked files).
>> 
> 
> At the time I thought whatever symlinks we have in tree should be
> created by xen's build system itself hence there was no need to copy
> them around, and it would have to avoid latent problem like linking to
> wrong files etc.
> 
> I think you have valid usecase for symlinks, so I'm fine with the change
> you make.

The only symlinks I'm aware of are the ones putting some files from
common/efi/ into arch/*/efi/. These are relative ones, so I was
considering whether perhaps we should skip those but treat absolute
ones like ordinary files. Do you have any opinion in that direction?

>> Irrespective of the changes I'm still observing "mkdir -p" to report a
>> missing operand, as config/ has no subdirs. Oddly enough this doesn't
>> cause the whole command (and hence the build to fail), despite the
>> "set -e" now covering the entire set of commands - perhaps a quirk of
>> the relatively old bash I've seen this with (a few simple experiments
>> suggest that commands inside () producing a non-success status would
>> exit the inner shell, but not the outer one).
> 
> I did see error when I wrote this bit hence I specifically hacked the
> rune to preserve "." in the output. We can add that back if necessary.

Why was it dropped?

> I suppose you will send out a new version at some point?

Sure - I only need to (a) be clear about what changes to make and
(b) find the time. Hopefully things will be easier once the Spectre v2
backports are all done.

Jan


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

Re: [Xen-devel] Problem with IOMEM and domain reboot

[Oleksandr Andrushchenko]

Hi, Wei!


On 02/06/2018 02:36 PM, Wei Liu wrote:

On Wed, Dec 20, 2017 at 06:27:02PM +0200, Oleksandr Andrushchenko wrote:

Hi, all!

While trying to reboot a domain which has iomem configured
(we are passing through some devices), I found an issue,
that after domain reboot those iomem's are incorrectly re-mapped,
e.g. for the configuration snippet below fe960 -> 0.

Part of the domain config I use:
iomem=[
     "0xfd010,1@0xfd000",
     "fe960,8",
]

During domain creation:
libxl_create.c:210:libxl__domain_build_info_setdefault: iomem gfn fd000
start fd010
libxl_create.c:210:libxl__domain_build_info_setdefault: iomem gfn
 start fe960

which means that for fe960 initial value was set to LIBXL_INVALID_GFN
and then on domain configuration,
tools/libxl/libxl_create.c:libxl__domain_build_info_setdefault:

     for (i = 0 ; i < b_info->num_iomem; i++)
     if (b_info->iomem[i].gfn == LIBXL_INVALID_GFN)
     b_info->iomem[i].gfn = b_info->iomem[i].start;

made that GFN for fe960 to be set to the correct value.

But during domain reboot I see that
tools/xl/xl_vmcontrol.c:reload_domain_config
tries to replicate configuration from the original domain config
being rebooted, but that leads to iomem's GFN to be set to 0 (if configured
in form [IOMEM_START,NUM_PAGES], but for [IOMEM_START,NUM_PAGES[@GFN] it is
ok):

iomem gfn fd000 start fd010
iomem gfn 0 start fe960

Thus, further domain restart procedure leads to invalid mapping, e.g. fe960
-> 0.

I created a patch which allowed me to reboot the domain, but I would love
to hear comments on what would be the proper fix.

Thank you,
Oleksandr

 From aa1f20af73a5a3c8f2c904b857a79334d18d41ff Mon Sep 17 00:00:00 2001
From: Oleksandr Andrushchenko 
Date: Wed, 20 Dec 2017 17:51:18 +0200
Subject: [PATCH] [HACK] Reset iomem's gfn to LIBXL_INVALID_GFN on reboot

During domain reboot its configuration is partially reused
to re-create a new domain, but iomem's GFN field for the
iomem is only restored for those memory ranges, which are
configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
those in form of [IOMEM_START,NUM_PAGES], e.g. without GFN.
For the latter GFN is reset to 0, but while mapping ranges
to a domain during reboot there is a check that GFN treated
as valid if it is not equal to LIBXL_INVALID_GFN, thus making
Xen to map IOMEM_START to address 0 in the guest's address space.

Workaround it by resseting GFN to LIBXL_INVALID_GFN, so xl
can set proper values for mapping on reboot.

Signed-off-by: Oleksandr Andrushchenko 
---
  tools/libxl/libxl_domain.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/tools/libxl/libxl_domain.c b/tools/libxl/libxl_domain.c
index ef1a0927b00d..2678ad2ad54f 100644
--- a/tools/libxl/libxl_domain.c
+++ b/tools/libxl/libxl_domain.c
@@ -1647,6 +1647,15 @@ int libxl_retrieve_domain_configuration(libxl_ctx *ctx, 
uint32_t domid,
  }
  }
  
+/* reset IOMEM's GFN to initial value */

+{
+int i;
+
+for (i = 0; i < d_config->b_info.num_iomem; i++)
+if (d_config->b_info.iomem[i].gfn == 0)
+d_config->b_info.iomem[i].gfn = LIBXL_INVALID_GFN;
+}
+

I don't think this is necessary. Instead we should tell libxl to save
the generated value into the template. Add an update_config hook for the
iomem type should be better.

Agree, this is why I tagged the patch as [HACK]
Unfortunately, I have little knowledge of libxl and not sure
how to properly fix it. Can you tell a bit more on what
a proper fix could be?

Wei.

Thank you,
Oleksandr

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

Re: [Xen-devel] [PATCH] libxl: add libxl__is_driver_domain function

[Wei Liu]

On Thu, Dec 14, 2017 at 04:14:12PM +0200, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> We have following arm-based setup:
> 
> - Dom0 with xen and xen tools;
> - Dom1 with device backends (but it is not the driver domain);

What is your definition of a "driver domain"? What does it do in this
case?

I seem to have seen people use this term in different contexts to mean
slightly different things. I need to figure out what you actually mean
first.

> - Dom2 with device frontend;
> 
> On Dom2 destroying we have timeout error. Because xl treats our
> Dom1 as driver domain and waits for backend path to be cleared
> by the driver domain which is not our case.
> 
> According to libxl__domain_make in case of driver domain it has
> "libxl" xen store entry:
> 
> if (libxl_defbool_val(info->driver_domain)) {
> /*
>  * Create a local "libxl" directory for each guest, since we might 
> want
>  * to use libxl from inside the guest
>  */
> libxl__xs_mknod(gc, t, GCSPRINTF("%s/libxl", dom_path), rwperm,
> ARRAY_SIZE(rwperm));
> 
> This patch introduces libxl__is_driver_domain which determines the driver
> domain by checking if "libxl" entry is present and uses this function on
> device destroy to check by whom domain path should be cleaned up (libxl
> or the driver domain).
> 
> Oleksandr Grytsov (1):
>   libxl: add libxl__is_driver_domain function
> 
>  tools/libxl/libxl_device.c   | 17 ++---
>  tools/libxl/libxl_internal.c | 16 
>  tools/libxl/libxl_internal.h |  4 
>  3 files changed, 30 insertions(+), 7 deletions(-)
> 
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [PATCH v3] libxc: don't fail domain creation when unpacking initrd fails

[Wei Liu]

On Thu, Feb 01, 2018 at 12:22:43AM -0700, Jan Beulich wrote:
> At least Linux kernels have been able to work with gzip-ed initrd for
> quite some time; initrd compressed with other methods aren't even being
> attempted to unpack. Furthermore the unzip-ing routine used here isn't
> capable of dealing with various forms of concatenated files, each of
> which was gzip-ed separately (it is this particular case which has been
> the source of observed VM creation failures).
> 
> Hence, if unpacking fails, simply hand the compressed blob to the guest
> as is.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Wei Liu 

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