Re: [Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context

[Tian, Kevin]

> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Monday, January 23, 2017 10:41 PM
> 
> On 16/01/17 11:17, Andrew Cooper wrote:
> > If the hardware supports faulting, and the guest has chosen to use it, leave
> > faulting active in HVM context.
> >
> > It is more efficient to have hardware convert CPUID to a #GP fault (which we
> > don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
> >
> > Signed-off-by: Andrew Cooper 
> > ---
> > CC: Jan Beulich 
> > CC: Jun Nakajima 
> > CC: Kevin Tian 
> 
> Ping VT-x ?
> 

sorry overlooked this one:

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

[Jan Beulich]

>>> On 23.01.17 at 18:12,  wrote:
> On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote:
>> >>> On 23.01.17 at 17:42,  wrote:
>> > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote:
>> >> >>> On 17.01.17 at 18:14,  wrote:
>> >> > This can be solved by using a different ACPI name in order to describe 
>> >> > vCPUs in
>> >> > the ACPI namespace. Most hardware vendors tend to use CPU or PR 
>> >> > prefixes for
>> >> > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix 
>> >> > should
>> >> > prevent clashes.
>> >> 
>> >> I continue to think that this is insufficient, without seeing a nice
>> >> clean way to solve the issue properly.
>> > 
>> > But in this document the namespace path for processor objects will be
>> > _SB.XEN0.VPXX, which should prevent any namespace clashes. Maybe I should 
>> > have
>> > updated the wording here, every Xen-related ACPI bit will be inside the
>> > _SB.XEN0 namespace.
>> 
>> Well, if we want to introduce our own parent name space, why the
>> special naming convention then? Any name not colliding with other
>> things in _SB.XEN0 should do then, so the only remaining risk would
>> then be that the firmware also has _SB.XEN0.
> 
> Right, that's why I say that I should have reworded this. We can then use 
> PXXX,
> CXXX or whatever we want.
> 
> Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT there's
> no way to reserve anything in there (mostly because it's assumed that ACPI
> tables will be created by a single entity I guess).

Right.

> I think that the chance of this happening is 0%, and that there's no single
> system out there with a _SB.XEN0 node. I've been wondering whether I should 
> try
> to post this to the ACPI working group, and try to get some feedback there.

As you've said during some earlier discussion, it won't hurt to give
this a try.

Jan


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

Re: [Xen-devel] PVH CPU hotplug design document

[Jan Beulich]

>>> On 23.01.17 at 19:36,  wrote:

 I think this should be introduced in your DomU ACPI CPU hotplug series, 
 and not
 set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 
 also.

>>> Right, although my understanding is that the series is on hold until we
>>> come to agreement about what to do about dom0. But I guess if we agree
>>> that we'll have a single ACPI hotplug feature bit then we can go ahead
>>> with Linux domU patches without waiting for Xen ACPI support.

How would you test such Linux patches if the Xen side is missing? Or
am I misunderstanding the statement above?

>> My understanding is that the way forward now is to introduce this bit, use it
>> in your series and decide what we do with Dom0 when we get to a point that we
>> can start to test/implement vCPU hotplug there. There's still work to do 
>> until
>> we can get to the point of simply booting a static no-hotplug PVHv2 Dom0.
> 
> Jan, is that how you want to proceed?

Well, it's not just depending on my opinion, I think. As said, I could
live with the bimodal approach, but I'm not really happy with it.
Hence at least a second opinion (perhaps Andrew's, but others'
input would be more than welcome) should be waited for imo.

> If yes then do you want me to resubmit the series with CPUID support or
> should I wait for you to review v6
> (https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00060.html)
> first?

Well, as you may have seen there've been quite a few patch series
submitted during the last days. With the desire to also work on my
own series, and with the need to also work on other stuff, I can't
really predict when I'd get to look at your or any other patches (it
is, to be honest, quite a bit discouraging to see so much stuff
being submitted for review, yet so little participation in reviews,
but that's not a new/unusual situation at all). Hence I think not
waiting for review of v6 would be more reasonable, unless
aforementioned further input gathering turns out to take overly
long.

Jan


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

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

[Oleksandr Andrushchenko]

On 01/23/2017 09:49 PM, Stefano Stabellini wrote:

On Sat, 21 Jan 2017, Oleksandr Andrushchenko wrote:

In the mail-thread you mentioned above there is a picture of
the xenstore entries and conclusion:

1. No change to the existing kbd+ptr:
1.1. They still share a dedicated (single) connection
channel as they did before multi-touch: page-ref + event-channel:

/local/domain/2/device/vkbd/0/page-ref = "1248025"
/local/domain/2/device/vkbd/0/page-gref = "336"
/local/domain/2/device/vkbd/0/event-channel = "43"

1.2. No multi-touch events via that connection
1.3. Old backends/frontends will see no difference
after multi-touch

2. Each multi-touch device has its own:
2.1. Configuration (width x height, num-contacts)
2.2. Own connection channel (page-ref, event-channel)

/local/domain/2/device/vkbd/0/mtouch/0/width = "3200"
/local/domain/2/device/vkbd/0/mtouch/0/height = "3200"
/local/domain/2/device/vkbd/0/mtouch/0/num-contacts = "5"
/local/domain/2/device/vkbd/0/mtouch/0/page-ref = "1252386"
/local/domain/2/device/vkbd/0/mtouch/0/page-gref = "335"
/local/domain/2/device/vkbd/0/mtouch/0/event-channel = "44"

/local/domain/2/device/vkbd/0/mtouch/1/width = "6400"
/local/domain/2/device/vkbd/0/mtouch/1/height = "6400"
/local/domain/2/device/vkbd/0/mtouch/1/num-contacts = "10"
/local/domain/2/device/vkbd/0/mtouch/1/page-ref = "2376038"
/local/domain/2/device/vkbd/0/mtouch/1/page-gref = "337"
/local/domain/2/device/vkbd/0/mtouch/1/event-channel = "45"
So, for the example above: 1 kbd + 1 ptr + 2 mt devices
within a single driver, *3 connections*


There are no ring-ref and event-channel under mtouch, are there?

there are ring-refs and event-channels under mtouch *per multi-touch*
device

Now, it is clear. Sorry it took so many back and forth.

np

page-ref and event-channel should definitely be described under
"Multi-touch Device Parameters". When I asked you to remove them, I
meant not just from the description but also from the protocol. This is
where the confusion originated: in the current patch the two parameters
are not described, hence I assumed they didn't exist and you were
reusing the existing ring (/local/domain/2/device/vkbd/0/page-ref).

understood


Aside from new message structs, which look fine to me, we have two
important choices to make:

a) number of multitouch devices per PV frontend/backend connection
(By frontend/backend connection, I mean by xenstore device,
such as /local/domain/2/device/vkbd/0.)

b) number of multitouch devices sharing the same ring
(By ring I mean page-ref + event channel.)

Both these choices need to be motivated. As I wrote in the past, I would
go for 1 multitouch device per frontend/backend connection, reusing the
existing ring (/local/domain/2/device/vkbd/0/page-ref and
/local/domain/2/device/vkbd/0/event-channel), because I assume that
there won't be many multitouch devices, less than 5,

yes, I have 2 mt devices in my use-case

so we can afford to
create new PV devices for each of them.

see at the bottom

  I am also assuming that it is
fine for them to share ring with the keyboard or pointer devices without
effects on performance because they should be all low frequency devices.

sounds reasonable, but see below

The current proposal supports multiple multitouch devices per
frontend/backnend connection and allocates a new dedicated ring for each
multitouch device. Your proposal might very well be the best solution,
but why? The architectural choices need to be motivated. How many
multitouch devices is reasonable to expect to be present on a platform?
What is the multitouch events frequency we expect from them? The answer
to the first question motivates choice a), the answer to the second
question motivates choice b). Please add them both to the protocol
description.  It is OK to add the explanation to kbdif.h. You also
mentioned something about multiple PV devices causing troubles to Linux.
If that is an issue somehow, please add info about that too.

Well, all the above sounds reasonable, some comments:
1. Event frequency: here we are talking about 60-120(?)Hz
scan frequency of a touch screen generating at least 2
events for each contact: frame (syn) and position.
So, we can estimate for 10 fingers the value to be
60 * 2 * 10 = 1200 events a second per multi-touch device.
Of course, this is rough estimate which I believe would
be smaller in real life.

2. "create new PV devices for each of them"
2.1. Driver
This is something which you are seeing in xenstore as
  /local/domain/2/device/vkbd/0
0 - being index of the *driver*.
And the challenge here is that if you want multiple *devices*
to be allocated in this way:
  /local/domain/2/device/vkbd/0
  /local/domain/2/device/vkbd/1
  /local/domain/2/device/vkbd/2
then you have to register multiple *DRIVERS*.
What we normally do in the PV front driver is we call
*xenbus_register_frontend*,passing a structure
*struct xenbus_driver* with *.ids* set to a single entry "vkbd".

I am a little bit confused here about front 

[Xen-devel] Xen installation on Nvidia Jetson TK-1

[Methuku Karthik]

Hello,

I am trying to install xen on Nvidia Jetson TK1. I am using this repo

*git://xenbits.xen.org/people/ianc/xen.git
 branch :
tegra-tk1-jetson-v1*

I tried


*make dist-xen debug=y CONFIG_EARLY_PRINTK=jetson
XEN_TARGET_ARCH=arm32 to build using this command*



*but it doesnt work. instead i used **make dist-xen debug=y
CONFIG_EARLY_PRINTK=tegra XEN_TARGET_ARCH=arm32*

build was successful.


I checked Rules.mk file in xen/arch/arm there is no rule for
CONFIG_EARLY_PRINTK= jetson or tegra ?

I am setting my fdt chosen node values as follows

Tegra124 (Jetson TK1) # fdt print /chosen
 chosen {
xen,xen-bootargs = "console=dtuart dtuart=serial0
dom0_mem=512M loglvl=all guest_loglvl=all dom0_max_vcpus=1
dom0_vcpus_pin maxcpus=1";
module {
bootargs = "console=hvc0 console=tty1 earlyprintk=xen
root=/dev/mmcblk0p1 rw rootwait clk_ignore_unused";
reg = <0x 0x8100 0x 0x004fbab0>;
compatible = "xen,linux-zimage", "xen,multiboot-module";
};
};
Tegra124 (Jetson TK1) # bootz $xen_addr_r - $fdt_addr_r

but the log is as follows (Missing information about loading kernel image)

## Flattened Device Tree blob at 8200
   Booting using the fdt blob at 0x8200
   reserving fdt memory region: addr=8200 size=1
   Using Device Tree in place at 8200, end 82012fff

Starting kernel ...


Its stuck at this point...

I tried Ctrl + a multiple times only to see no other window.

Any thing to try to make it work will be great help.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 6671cd7444bc6c00ffe980bd43e0d2a09086ce86
baseline version:
 ovmf 223a99e524679a7f811755442897bfad7cf49830

Last test of basis   104607  2017-01-23 13:17:08 Z0 days
Testing same since   104615  2017-01-24 02:46:11 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Zhang, Chao B 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] Bad block Management Patch

[Anurag Raghavan (RBEI/ETW11)]

Hi Boris,


I am using kernel version-3.0.35
I am facing uncorrectable ECC error in ubifs. I am suspecting, it is because of 
bad blocks are not properly handled in my driver.
Is there any patches available to handle the bad block in the specified 
version...


Best regards

Raghavan Anurag
RBEI/ETW1

Tel. +91(422)667-4001 | Mobil 9986968950

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail in 104609 pass in 
104611
 test-armhf-armhf-libvirt-xsm 15 guest-start/debian.repeat  fail pass in 104609
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat  fail pass in 104609

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

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

version targeted for testing:
 qemuu3879284d6517dc22529395bdb259f4183b589127
baseline version:
 qemuud1c82f7cc34443841095f490345f86c9d8baca34

Last test of basis   104546  2017-01-21 19:44:02 Z2 days
Failing since104605  2017-01-23 10:15:04 Z0 days3 attempts
Testing same since   104609  2017-01-23 17:45:27 Z0 days2 attempts


People who touched revisions under test:
  Caoxinhua 
  Daniel P. Berrange 
  Eduardo Habkost 
  hangaohuai 
  Igor Mammedov 
  Leif Lindholm 

Re: [Xen-devel] xen/arm: Domain not fully destroyed when using credit2

[Stefano Stabellini]

On Mon, 23 Jan 2017, Julien Grall wrote:
> Hi all,
> 
> Before someone dig into the scheduler, I don't think this is an issue in
> credit2 but the use of it highlight a bug in another component (I think RCU).
> 
> Whilst testing other patches today, I have noticed that some part of the
> resources allocated to a guest were not released during the destruction.
> 
> The configuration of the test is:
>   - ARM platform with 6 cores
>   - staging Xen with credit2 enabled by default
>   - DOM0 using 2 pinned vCPUs
> 
> The test is creating a guest vCPUs and then destroyed. After the test, some
> resourced are not released (or could be released a long time
> after).
> 
> Looking at the code, domain resources are released in 2 phases:
>   - domain_destroy: called when there is no more reference on the domain
> (see put_domain)
>   - complete_domain_destroy: called when the RCU is quiescent
> 
> The function domain_destroy will setup the RCU callback
> (complete_domain_destroy) by calling call_rcu. call_rcu will add the callback
> into the RCU list and then will may send an IPI (see force_quiescent_state) if
> the threshold reached. This IPI is here to make sure all CPUs are quiescent
> before calling the callbacks (e.g complete_domain_destroy). In my case, the
> threshold has not reached and therefore an IPI is not sent.
> 
> On ARM, the idle will run when the pCPU has no work to do. This loop will wait
> to receive an interrupt (see wfi) and check if there is some work to do when
> the CPU has waken-up (i.e an interrupt was received).
> 
> The problem I encountered is the idle CPU will never receive interrupts (no
> timer, nor IPI...) and therefore never check whether the RCU has some work to
> do.
> 
> From my understanding, this is a bug in how RCU is handled (see comment above
> rcu_start_batch), it expects each CPU (no broadcast) to check whether there is
> RCU work. But this is relying on someone else (timer?) to fire an interrupt.
> 
> Any incoming interrupts will make a pCPU checking the RCU state. On ARM, the
> biggest source of IPI was credit1 or timer if a guest vCPU was scheduled on
> that pCPU. But it looks like the IPI traffic with credit2 was reduced to none
> (which is a really good thing :)), and no guest timer was scheduled because no
> vCPU ever run on this pCPU.
> 
> I think the bug has always been here (both ARM and x86), but never detected
> because any incoming interrupts will make the pCPU to check the RCU state.
> 
> However, I am not sure how to resolve this issue. Any thoughts?

Well done for finding the bug!

Sending an IPI on call_rcu is easy, but it would be better not to wake
up the sleeping cpus at all. If they are running the idle_loop, they
cannot be holding any rcu references for the domain which is about to be
destroyed, right?

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

Re: [Xen-devel] [DOC v7] PV Calls protocol design

[Stefano Stabellini]

On Fri, 20 Jan 2017, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 10, 2017 at 04:13:26PM -0800, Stefano Stabellini wrote:
> > Upon request from Konrad, I am attaching the output of pahole on the C
> > structs defined by PVCalls. As you can see, alignments and sizes of all
> 
> Thank you!
> > fields are the same, except for the padding at the end of many request
> > structs (they need to be multiple of 8 bytes on 64bit). However, struct
> 
> Would it make sense to add
> 
> #ifdef CONFIG_X86_32
> uint8_t[X] _pad;
> #endif
> 
> so it will nicely fill it out?

I added them for each struct in the union too.


> > xen_pvcalls_dummy dummy ensures that the overall size of struct
> > xen_pvcalls_request is the same on both 32 and 64.
> 
> Yes indeed. Thank you!
> 
> > > # PV Calls Protocol version 1
> > > 
> > > ## Glossary
> > > 
> > > The following is a list of terms and definitions used in the Xen
> > > community. If you are a Xen contributor you can skip this section.
> > > 
> > > * PV
> > > 
> > >   Short for paravirtualized.
> > > 
> > > * Dom0
> > > 
> > >   First virtual machine that boots. In most configurations Dom0 is
> > >   privileged and has control over hardware devices, such as network
> > >   cards, graphic cards, etc.
> > > 
> > > * DomU
> > > 
> > >   Regular unprivileged Xen virtual machine.
> > > 
> > > * Domain
> > > 
> > >   A Xen virtual machine. Dom0 and all DomUs are all separate Xen
> > >   domains.
> > > 
> > > * Guest
> > > 
> > >   Same as domain: a Xen virtual machine.
> > > 
> > > * Frontend
> > > 
> > >   Each DomU has one or more paravirtualized frontend drivers to access
> > >   disks, network, console, graphics, etc. The presence of PV devices is
> > >   advertized on XenStore, a cross domain key-value database. Frontends
> > >   are similar in intent to the virtio drivers in Linux.
> > > 
> > > * Backend
> > > 
> > >   A Xen paravirtualized backend typically runs in Dom0 and it is used to
> > >   export disks, network, console, graphics, etcs, to DomUs. Backends can
> > >   live both in kernel space and in userspace. For example xen-blkback
> > >   lives under drivers/block in the Linux kernel and xen_disk lives under
> > >   hw/block in QEMU. Paravirtualized backends are similar in intent to
> > >   virtio device emulators.
> > > 
> > > * VMX and SVM
> > >   
> > >   On Intel processors, VMX is the CPU flag for VT-x, hardware
> > >   virtualization support. It corresponds to SVM on AMD processors.
> > > 
> > > 
> > > 
> > > ## Rationale
> > > 
> > > PV Calls is a paravirtualized protocol that allows the implementation of
> > > a set of POSIX functions in a different domain. The PV Calls frontend
> > > sends POSIX function calls to the backend, which implements them and
> > > returns a value to the frontend.
> 
> "returns a value to the frontend and acts on the function call."

OK


> > > 
> > > This version of the document covers networking function calls, such as
> > > connect, accept, bind, release, listen, poll, recvmsg and sendmsg; but
> > > the protocol is meant to be easily extended to cover different sets of
> > > calls. Unimplemented commands return ENOTSUP.
> > > 
> > > PV Calls provide the following benefits:
> > > * full visibility of the guest behavior on the backend domain, allowing
> > >   for inexpensive filtering and manipulation of any guest calls
> > > * excellent performance
> > > 
> > > Specifically, PV Calls for networking offer these advantages:
> > > * guest networking works out of the box with VPNs, wireless networks and
> > >   any other complex configurations on the host
> > > * guest services listen on ports bound directly to the backend domain IP
> > >   addresses
> > > * localhost becomes a secure namespace for inter-VMs communications
> > >
> 
> [Not sure I understand that but it probably is explained in detail later on?]
> 
> Does it make sense to define what 'namespace' is ? I mean I know what it is
> in context of C++ but I presume with cgroups and such it is different? 

I reworded it to:

* localhost becomes a secure host wide network for inter-VMs 
  communications


> > > 
> > > ## Design
> > > 
> > > ### Why Xen?
> > > 
> > > PV Calls are part of an effort to create a secure runtime environment
> > > for containers (OCI images to be precise). PV Calls are based on Xen,
> 
> OCI = Open Containers Initiative?

That's right


> Perhaps mention that in glossary or just spell it out here, like:
> 
> s/OCI images/Open Containers Initiative, aka OCI/

OK


> > > although porting them to other hypervisors is possible. Xen was chosen
> > > because of its security and isolation properties and because it supports
> > > PV guests, a type of virtual machines that does not require hardware
> > > virtualization extensions (VMX on Intel processors and SVM on AMD
> > > processors). This is important because PV Calls is meant for containers
> > > and containers are often run on top of public cloud instances, which do
> > > not support nested VMX (or SVM) as 

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 qemuu3879284d6517dc22529395bdb259f4183b589127
baseline version:
 qemuud1c82f7cc34443841095f490345f86c9d8baca34

Last test of basis   104546  2017-01-21 19:44:02 Z2 days
Failing since104605  2017-01-23 10:15:04 Z0 days2 attempts
Testing same since   104609  2017-01-23 17:45:27 Z0 days1 attempts


People who touched revisions under test:
  Caoxinhua 
  Daniel P. Berrange 
  Eduardo Habkost 
  hangaohuai 
  Igor Mammedov 
  Leif Lindholm 
  Li Qiang 
  Marc-André Lureau 
  Marcelo Tosatti 
  Paolo 

[Xen-devel] [ovmf baseline-only test] 68423: tolerable trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i3863 host-install(3)   broken baseline untested
 build-amd64   3 host-install(3)   broken baseline untested
 build-i386-pvops  3 host-install(3)   broken baseline untested
 build-i386-xsm3 host-install(3)   broken baseline untested
 build-amd64-pvops 3 host-install(3)   broken baseline untested
 build-amd64-xsm   3 host-install(3)   broken baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf 223a99e524679a7f811755442897bfad7cf49830
baseline version:
 ovmf f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f

Last test of basis68421  2017-01-23 07:19:58 Z0 days
Testing same since68423  2017-01-23 15:17:10 Z0 days1 attempts


People who touched revisions under test:
  Nikolai SAOUKH  
  Nikolai SAOUKH 
  Yonghong Zhu 
  Zhang Lubo 
  Zhang, Lubo 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

broken-step build-i386 host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386-pvops host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)
broken-step build-amd64-xsm host-install(3)

Push not applicable.


commit 223a99e524679a7f811755442897bfad7cf49830
Author: Nikolai SAOUKH 
Date:   Sun Jan 22 11:27:18 2017 +0800

BaseTools: Convert incomplete expression with dangling while()

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

commit 0fdfe2742e4a76f586b16f370193b2d97f0ed04a
Author: Yonghong Zhu 
Date:   Sun Jan 22 09:59:32 2017 +0800

BaseTools: Extend the Macro used in the FDF !include statement

Current it only support the system environment variables in the !include
statement, $(WORKSPACE), $(PACKAGES_PATH), $(EFI_SOURCE), $(EDK_SOURCE),
$(ECP_SOURCE), this patch extend the usage to support the Global macros
and the macro which defined before the statement.

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

commit 7cf59c854f35c9680965fe83e9cfd863079ddd73
Author: Zhang, Lubo 
Date:   Sun Jan 22 09:40:30 2017 +0800

NetworkPkg: Fix protocol handler service in HttpDxe.

When we create a HTTP driver service binding private
instance, there may be different DriverBindingHandle
for Ipv4 or Ipv6, so it is essential to distinguish
the HttpService image which will be used in open
protocol or close protocol.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Zhang Lubo 
Cc: Sriram Subramanian 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Wu Jiaxin 
Reviewed-by: Sriram Subramanian 

[Xen-devel] [distros-debian-sid test] 68422: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf   3 host-install(3)  broken like 68374
 build-armhf-pvops 3 host-install(3)  broken like 68374
 build-amd64-pvops 3 host-install(3)  broken like 68374
 build-i386-pvops  3 host-install(3)  broken like 68374
 build-amd64   3 host-install(3)  broken like 68374
 build-i3863 host-install(3)  broken like 68374

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-sid-netboot-pvgrub  1 build-check(1)blocked n/a
 test-amd64-i386-i386-sid-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-armhf-armhf-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-sid-netboot-pygrub  1 build-check(1) blocked n/a

baseline version:
 flight   68374

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-sid-netboot-pvgrubblocked 
 test-amd64-i386-i386-sid-netboot-pvgrub  blocked 
 test-amd64-i386-amd64-sid-netboot-pygrub blocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubblocked 
 test-amd64-amd64-i386-sid-netboot-pygrub blocked 



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v1 2/2] xen/kbdif: add multi-touch support

[Stefano Stabellini]

On Sat, 21 Jan 2017, Oleksandr Andrushchenko wrote:
> In the mail-thread you mentioned above there is a picture of
> the xenstore entries and conclusion:
> 
> 1. No change to the existing kbd+ptr:
> 1.1. They still share a dedicated (single) connection
> channel as they did before multi-touch: page-ref + event-channel:
> 
> /local/domain/2/device/vkbd/0/page-ref = "1248025"
> /local/domain/2/device/vkbd/0/page-gref = "336"
> /local/domain/2/device/vkbd/0/event-channel = "43"
> 
> 1.2. No multi-touch events via that connection
> 1.3. Old backends/frontends will see no difference
> after multi-touch
> 
> 2. Each multi-touch device has its own:
> 2.1. Configuration (width x height, num-contacts)
> 2.2. Own connection channel (page-ref, event-channel)
> 
> /local/domain/2/device/vkbd/0/mtouch/0/width = "3200"
> /local/domain/2/device/vkbd/0/mtouch/0/height = "3200"
> /local/domain/2/device/vkbd/0/mtouch/0/num-contacts = "5"
> /local/domain/2/device/vkbd/0/mtouch/0/page-ref = "1252386"
> /local/domain/2/device/vkbd/0/mtouch/0/page-gref = "335"
> /local/domain/2/device/vkbd/0/mtouch/0/event-channel = "44"
> 
> /local/domain/2/device/vkbd/0/mtouch/1/width = "6400"
> /local/domain/2/device/vkbd/0/mtouch/1/height = "6400"
> /local/domain/2/device/vkbd/0/mtouch/1/num-contacts = "10"
> /local/domain/2/device/vkbd/0/mtouch/1/page-ref = "2376038"
> /local/domain/2/device/vkbd/0/mtouch/1/page-gref = "337"
> /local/domain/2/device/vkbd/0/mtouch/1/event-channel = "45"
> So, for the example above: 1 kbd + 1 ptr + 2 mt devices
> within a single driver, *3 connections*
> 
>> There are no ring-ref and event-channel under mtouch, are there? 
> 
> there are ring-refs and event-channels under mtouch *per multi-touch*
> device

Now, it is clear. Sorry it took so many back and forth.

page-ref and event-channel should definitely be described under
"Multi-touch Device Parameters". When I asked you to remove them, I
meant not just from the description but also from the protocol. This is
where the confusion originated: in the current patch the two parameters
are not described, hence I assumed they didn't exist and you were
reusing the existing ring (/local/domain/2/device/vkbd/0/page-ref).


Aside from new message structs, which look fine to me, we have two
important choices to make:

a) number of multitouch devices per PV frontend/backend connection
(By frontend/backend connection, I mean by xenstore device,
such as /local/domain/2/device/vkbd/0.)

b) number of multitouch devices sharing the same ring
(By ring I mean page-ref + event channel.)

Both these choices need to be motivated. As I wrote in the past, I would
go for 1 multitouch device per frontend/backend connection, reusing the
existing ring (/local/domain/2/device/vkbd/0/page-ref and
/local/domain/2/device/vkbd/0/event-channel), because I assume that
there won't be many multitouch devices, less than 5, so we can afford to
create new PV devices for each of them. I am also assuming that it is
fine for them to share ring with the keyboard or pointer devices without
effects on performance because they should be all low frequency devices.

The current proposal supports multiple multitouch devices per
frontend/backnend connection and allocates a new dedicated ring for each
multitouch device. Your proposal might very well be the best solution,
but why? The architectural choices need to be motivated. How many
multitouch devices is reasonable to expect to be present on a platform?
What is the multitouch events frequency we expect from them? The answer
to the first question motivates choice a), the answer to the second
question motivates choice b). Please add them both to the protocol
description.  It is OK to add the explanation to kbdif.h. You also
mentioned something about multiple PV devices causing troubles to Linux.
If that is an issue somehow, please add info about that too.

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

[Xen-devel] xen/arm: Domain not fully destroyed when using credit2

[Julien Grall]

Hi all,

Before someone dig into the scheduler, I don't think this is an issue in 
credit2 but the use of it highlight a bug in another component (I think 
RCU).


Whilst testing other patches today, I have noticed that some part of the 
resources allocated to a guest were not released during the destruction.


The configuration of the test is:
- ARM platform with 6 cores
- staging Xen with credit2 enabled by default
- DOM0 using 2 pinned vCPUs

The test is creating a guest vCPUs and then destroyed. After the test, 
some resourced are not released (or could be released a long time

after).

Looking at the code, domain resources are released in 2 phases:
	- domain_destroy: called when there is no more reference on the domain 
(see put_domain)

- complete_domain_destroy: called when the RCU is quiescent

The function domain_destroy will setup the RCU callback 
(complete_domain_destroy) by calling call_rcu. call_rcu will add the 
callback into the RCU list and then will may send an IPI (see 
force_quiescent_state) if the threshold reached. This IPI is here to 
make sure all CPUs are quiescent before calling the callbacks (e.g 
complete_domain_destroy). In my case, the threshold has not reached and 
therefore an IPI is not sent.


On ARM, the idle will run when the pCPU has no work to do. This loop 
will wait to receive an interrupt (see wfi) and check if there is some 
work to do when the CPU has waken-up (i.e an interrupt was received).


The problem I encountered is the idle CPU will never receive interrupts 
(no timer, nor IPI...) and therefore never check whether the RCU has 
some work to do.


From my understanding, this is a bug in how RCU is handled (see comment 
above rcu_start_batch), it expects each CPU (no broadcast) to check 
whether there is RCU work. But this is relying on someone else (timer?) 
to fire an interrupt.


Any incoming interrupts will make a pCPU checking the RCU state. On ARM, 
the biggest source of IPI was credit1 or timer if a guest vCPU was 
scheduled on that pCPU. But it looks like the IPI traffic with credit2 
was reduced to none (which is a really good thing :)), and no guest 
timer was scheduled because no vCPU ever run on this pCPU.


I think the bug has always been here (both ARM and x86), but never 
detected because any incoming interrupts will make the pCPU to check the 
RCU state.


However, I am not sure how to resolve this issue. Any thoughts?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 3/3] xen: optimize xenbus driver for multiple concurrent xenstore accesses

[Boris Ostrovsky]

On 01/23/2017 05:09 AM, Juergen Gross wrote:
> Handling of multiple concurrent Xenstore accesses through xenbus driver
> either from the kernel or user land is rather lame today: xenbus is
> capable to have one access active only at one point of time.
>
> Rewrite xenbus to handle multiple requests concurrently by making use
> of the request id of the Xenstore protocol. This requires to:
>
> - Instead of blocking inside xb_read() when trying to read data from
>   the xenstore ring buffer do so only in the main loop of
>   xenbus_thread().
>
> - Instead of doing writes to the xenstore ring buffer in the context of
>   the caller just queue the request and do the write in the dedicated
>   xenbus thread.
>
> - Instead of just forwarding the request id specified by the caller of
>   xenbus to xenstore use a xenbus internal unique request id. This will
>   allow multiple outstanding requests.
>
> - Modify the locking scheme in order to allow multiple requests being
>   active in parallel.
>
> - Instead of waiting for the reply of a user's xenstore request after
>   writing the request to the xenstore ring buffer return directly to
>   the caller and do the waiting in the read path.
>
> Additionally signal handling was optimized by avoiding waking up the
> xenbus thread or sending an event to Xenstore in case the addressed
> entity is known to be running already.
>
> As a result communication with Xenstore is sped up by a factor of up
> to 5: depending on the request type (read or write) and the amount of
> data transferred the gain was at least 20% (small reads) and went up to
> a factor of 5 for large writes.
>
> In the end some more rough edges of xenbus have been smoothed:
>
> - Handling of memory shortage when reading from xenstore ring buffer in
>   the xenbus driver was not optimal: it was busy looping and issuing a
>   warning in each loop.
>
> - In case of xenstore not running in dom0 but in a stubdom we end up
>   with two xenbus threads running as the initialization of xenbus in
>   dom0 expecting a local xenstored will be redone later when connecting
>   to the xenstore domain. Up to now this was no problem as locking
>   would prevent the two xenbus threads interfering with each other, but
>   this was just a waste of kernel resources.
>
> - An out of memory situation while writing to or reading from the
>   xenstore ring buffer no longer will lead to a possible loss of
>   synchronization with xenstore.
>
> - The user read and write part are now interruptible by signals.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()

[Boris Ostrovsky]

On 01/23/2017 09:39 AM, Andrew Cooper wrote:
> Leaf 0x801c contains LWP information.  edx contains hardware supported
> features (and is clamped against the maximum), while ecx and ebx contain
> various properties of the implementation.  eax is entirely dynamic, depending
> on xcr0 and MSR_LWP_CFG.
>
> The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
> reading the data straight out of the cpuid_policy block.
>
> Signed-off-by: Andrew Cooper 

Reviewed-by: Boris Ostrovsky 


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

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

>>> I think this should be introduced in your DomU ACPI CPU hotplug series, and 
>>> not
>>> set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 
>>> also.
>>>
>> Right, although my understanding is that the series is on hold until we
>> come to agreement about what to do about dom0. But I guess if we agree
>> that we'll have a single ACPI hotplug feature bit then we can go ahead
>> with Linux domU patches without waiting for Xen ACPI support.
> My understanding is that the way forward now is to introduce this bit, use it
> in your series and decide what we do with Dom0 when we get to a point that we
> can start to test/implement vCPU hotplug there. There's still work to do until
> we can get to the point of simply booting a static no-hotplug PVHv2 Dom0.

Jan, is that how you want to proceed?

If yes then do you want me to resubmit the series with CPUID support or
should I wait for you to review v6
(https://lists.xenproject.org/archives/html/xen-devel/2017-01/msg00060.html)
first?

-boris


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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Daniel Kiper]

On Mon, Jan 23, 2017 at 10:07:36AM -0600, Doug Goldstein wrote:
> On 1/23/17 9:45 AM, Daniel Kiper wrote:
> > On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
> >> On 1/23/17 7:08 AM, Daniel Kiper wrote:
> >>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>  On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> >> Hi,
> >>
> >> I am sending twelfth version of multiboot2 protocol support for
> >> legacy BIOS and EFI platforms. This patch series release contains
> >> fixes for all known/confirmed issues.
> >
> > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> > get the following on some of the systems I have access to:
> >
> > (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> > (XEN) [7.012109] Stuck ??
> > (XEN) [7.012129] Failed to bring up CPU 1 (error -5)
> > (XEN) [   12.023606] Stuck ??
> > (XEN) [   12.023622] Failed to bring up CPU 2 (error -5)
> > (XEN) [   17.035099] Stuck ??
> > (XEN) [   17.035115] Failed to bring up CPU 3 (error -5)
> > (XEN) [   17.035116] Brought up 1 CPUs
> >
> > On other machines they reset when setting PAGING into cr0 (actually the
> > jmp following it) on line 124 of trampoline.S
> 
>  Thanks! I will take a look.
> 
> > If I drop the series to just 2-5 against staging (since patch 1 has
> > already gone in) and apply the fix to efi_multiboot2() then all the
> > machines I presently have access to boot.
> 
>  Great!
> 
> > Effectively the fix to efi_multiboot2() gets us back to the same level
> > of hardware support that v11 + my v5 was at for 1-5. So I will extend 
> > my:
> >
> > Reviewed-by: Doug Goldstein 
> > Tested-by: Doug Goldstein 
> 
>  Thanks!
> 
> > on the condition that the fix is applied to 5/10 prior to commit.
> 
>  Will do.
> 
>  By the way, I have asked my team colleagues to do more tests of this 
>  series.
>  I will come back to you if I have something in hand.
> >>>
> >>> Once you told me that you applied some patches on top of my patch series 
> >>> to get
> >>> it working. Is it still true? If you still use some extra patches could 
> >>> you send
> >>> me them? What about ExitBootServices() call? Did you disabled it? If yes 
> >>> on which
> >>> machines it have to be disabled?
> >>>
> >>> Daniel
> >>
> >> I previously used the patch that I linked to you authored by Konrad. I
> >> have since switched to the patches that XenServer uses to no-op
> >> efi_get_time() and to map additional ranges of reserved memory to make
> >> EBS() work.
> >
> > Could you send me them?
> >
> > Daniel
>
> I apply them only for 2 out of the roughly dozen machines. Its not those
> changes.
>
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0002-efi-Ensure-incorrectly-typed-runtime-services-get-ma.patch
>
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-x86-time-Don-t-use-EFI-s-GetTime-call.patch

Thanks! I will take a look.

Daniel

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

[Xen-devel] [PATCH v14 3/3] iommu: add rmrr Xen command line option for extra rmrrs

[Venu Busireddy]

On some platforms firmware fails to specify RMRR regions in ACPI tables and
thus those regions will not be mapped in dom0 or guests and may cause IO
Page Faults and prevent dom0 from booting if "iommu=dom0-strict" option is
specified on the Xen command line.

New Xen command line option rmrr allows to specify such devices and
memory regions. These regions are added to the list of RMRR defined in ACPI
if the device is present in system. As a result, additional RMRRs will be
mapped 1:1 in dom0 with correct permissions.

The above mentioned problems were discovered during the PVH work with
ThinkCentre M and Dell 5600T. No official documentation was found so far
in regards to what devices and why cause this. Experiments show that
ThinkCentre M USB devices with enabled debug port generate DMA read
transactions to the regions of memory marked reserved in host e820 map.

For Dell 5600T the device and faulting addresses are not found yet.
For detailed history of the discussion please check following threads:
http://lists.Xen.org/archives/html/xen-devel/2015-02/msg01724.html
http://lists.Xen.org/archives/html/xen-devel/2015-01/msg02513.html

Format for rmrr Xen command line option:

rmrr=start<-end>=[s1]bdf1[,[s1]bdf2[,...]];start<-end>=[s2]bdf1[,[s2]bdf2[,...]]
For example, for Lenovo ThinkCentre M, use:
rmrr=0xd5d45=0:0:1d.0;0xd5d46=0:0:1a.0
If grub2 used and multiple ranges are specified, ';' should be
quoted/escaped, refer to grub2 manual for more information.

Signed-off-by: Elena Ufimtseva 
Signed-off-by: Venu Busireddy 
Acked-by: Kevin Tian 
---
 docs/misc/xen-command-line.markdown |  13 +++
 xen/drivers/passthrough/vtd/dmar.c  | 203 +++-
 2 files changed, 215 insertions(+), 1 deletion(-)

Changes in v14:
 - Implement Jan's feedback.
   Rename some #defines and take care of boundary conditions.

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 0138978..a11fdf9 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1377,6 +1377,19 @@ Specify the host reboot method.
 'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
  default it will use that method first).
 
+### rmrr
+> '= 
start<-end>=[s1]bdf1[,[s1]bdf2[,...]];start<-end>=[s2]bdf1[,[s2]bdf2[,...]]
+
+Define RMRR units that are missing from ACPI table along with device they
+belong to and use them for 1:1 mapping. End addresses can be omitted and one
+page will be mapped. The ranges are inclusive when start and end are specified.
+If segment of the first device is not specified, segment zero will be used.
+If other segments are not specified, first device segment will be used.
+If a segment is specified for other than the first device and it does not match
+the one specified for the first one, an error will be reported.
+Note: grub2 requires to escape or use quotations if special characters are 
used,
+namely ';', refer to the grub2 documentation if multiple ranges are specified.
+
 ### ro-hpet
 > `= `
 
diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 3c7c9b2..7c12b17 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -859,6 +859,134 @@ out:
 return ret;
 }
 
+#define MAX_USER_RMRR_PAGES 16
+#define MAX_USER_RMRR 10
+
+/* RMRR units derived from command line rmrr option. */
+#define MAX_USER_RMRR_DEV 20
+struct user_rmrr {
+struct list_head list;
+unsigned long base_pfn, end_pfn;
+unsigned int dev_count;
+u32 sbdf[MAX_USER_RMRR_DEV];
+};
+
+static __initdata unsigned int nr_rmrr;
+static struct __initdata user_rmrr user_rmrrs[MAX_USER_RMRR];
+
+/* Macro for RMRR inclusive range formatting. */
+#define ERMRRU_FMT "[%lx-%lx]"
+#define ERMRRU_ARG(eru) eru.base_pfn, eru.end_pfn
+
+static int __init add_user_rmrr(void)
+{
+struct acpi_rmrr_unit *rmrr, *rmrru;
+unsigned int idx, seg, i;
+unsigned long base, end;
+bool overlap;
+
+for ( i = 0; i < nr_rmrr; i++ )
+{
+base = user_rmrrs[i].base_pfn;
+end = user_rmrrs[i].end_pfn;
+
+if ( base > end )
+{
+printk(XENLOG_ERR VTDPREFIX
+   "Invalid RMRR Range "ERMRRU_FMT"\n",
+   ERMRRU_ARG(user_rmrrs[i]));
+continue;
+}
+
+if ( (end - base) >= MAX_USER_RMRR_PAGES )
+{
+printk(XENLOG_ERR VTDPREFIX
+   "RMRR range "ERMRRU_FMT" exceeds "\
+   __stringify(MAX_USER_RMRR_PAGES)" pages\n",
+   ERMRRU_ARG(user_rmrrs[i]));
+continue;
+}
+
+overlap = false;
+list_for_each_entry(rmrru, _rmrr_units, list)
+{
+if ( pfn_to_paddr(base) <= rmrru->end_address &&
+ rmrru->base_address <= pfn_to_paddr(end) )
+{
+   

[Xen-devel] [PATCH v14 2/3] pci: add wrapper for parse_pci.

[Venu Busireddy]

For sbdf's parsing in RMRR command line, add parse_pci_seg with additional
parameter def_seg. parse_pci_seg will help to identify if segment was
found in string being parsed or default segment was used.
Make a wrapper parse_pci so the rest of the callers are not affected.

Signed-off-by: Elena Ufimtseva 
Signed-off-by: Venu Busireddy 
Acked-by: Kevin Tian 
---
 xen/drivers/pci/pci.c | 11 +++
 xen/include/xen/pci.h |  3 +++
 2 files changed, 14 insertions(+)

Changes in v14:
 - No new changes. Included this patch file for the sake of completeness.

diff --git a/xen/drivers/pci/pci.c b/xen/drivers/pci/pci.c
index ca07ed0..13d3309 100644
--- a/xen/drivers/pci/pci.c
+++ b/xen/drivers/pci/pci.c
@@ -119,11 +119,21 @@ const char *__init parse_pci(const char *s, unsigned int 
*seg_p,
  unsigned int *bus_p, unsigned int *dev_p,
  unsigned int *func_p)
 {
+bool def_seg;
+
+return parse_pci_seg(s, seg_p, bus_p, dev_p, func_p, _seg);
+}
+
+const char *__init parse_pci_seg(const char *s, unsigned int *seg_p,
+ unsigned int *bus_p, unsigned int *dev_p,
+ unsigned int *func_p, bool *def_seg)
+{
 unsigned long seg = simple_strtoul(s, , 16), bus, dev, func;
 
 if ( *s != ':' )
 return NULL;
 bus = simple_strtoul(s + 1, , 16);
+*def_seg = false;
 if ( *s == ':' )
 dev = simple_strtoul(s + 1, , 16);
 else
@@ -131,6 +141,7 @@ const char *__init parse_pci(const char *s, unsigned int 
*seg_p,
 dev = bus;
 bus = seg;
 seg = 0;
+*def_seg = true;
 }
 if ( func_p )
 {
diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
index 0872401..59b6e8a 100644
--- a/xen/include/xen/pci.h
+++ b/xen/include/xen/pci.h
@@ -159,6 +159,9 @@ int pci_find_ext_capability(int seg, int bus, int devfn, 
int cap);
 int pci_find_next_ext_capability(int seg, int bus, int devfn, int pos, int 
cap);
 const char *parse_pci(const char *, unsigned int *seg, unsigned int *bus,
   unsigned int *dev, unsigned int *func);
+const char *parse_pci_seg(const char *, unsigned int *seg, unsigned int *bus,
+  unsigned int *dev, unsigned int *func, bool 
*def_seg);
+
 
 bool_t pcie_aer_get_firmware_first(const struct pci_dev *);
 

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

[Xen-devel] [PATCH v14 1/3] iommu VT-d: separate rmrr addition function.

[Venu Busireddy]

In preparation for auxiliary RMRR data provided on Xen command line,
make RMRR adding a separate function.
Also free memery for rmrr device scope in error path.

Signed-off-by: Elena Ufimtseva 
Signed-off-by: Venu Busireddy 
Acked-by: Kevin Tian 
---
 xen/drivers/passthrough/vtd/dmar.c | 123 -
 1 file changed, 65 insertions(+), 58 deletions(-)

Changes in v14:
 - Capture the return value from register_one_rmrr() and use it.

diff --git a/xen/drivers/passthrough/vtd/dmar.c 
b/xen/drivers/passthrough/vtd/dmar.c
index 08c1d2d..3c7c9b2 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -579,6 +579,68 @@ out:
 return ret;
 }
 
+static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
+{
+bool ignore = false;
+unsigned int i = 0;
+int ret = 0;
+
+/* Skip checking if segment is not accessible yet. */
+if ( !pci_known_segment(rmrru->segment) )
+i = UINT_MAX;
+
+for ( ; i < rmrru->scope.devices_cnt; i++ )
+{
+u8 b = PCI_BUS(rmrru->scope.devices[i]);
+u8 d = PCI_SLOT(rmrru->scope.devices[i]);
+u8 f = PCI_FUNC(rmrru->scope.devices[i]);
+
+if ( pci_device_detect(rmrru->segment, b, d, f) == 0 )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+" Non-existent device (%04x:%02x:%02x.%u) is reported"
+" in RMRR (%"PRIx64", %"PRIx64")'s scope!\n",
+rmrru->segment, b, d, f,
+rmrru->base_address, rmrru->end_address);
+ignore = true;
+}
+else
+{
+ignore = false;
+break;
+}
+}
+
+if ( ignore )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+"  Ignore the RMRR (%"PRIx64", %"PRIx64") due to "
+"devices under its scope are not PCI discoverable!\n",
+rmrru->base_address, rmrru->end_address);
+scope_devices_free(>scope);
+xfree(rmrru);
+}
+else if ( rmrru->base_address > rmrru->end_address )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+"  The RMRR (%"PRIx64", %"PRIx64") is incorrect!\n",
+rmrru->base_address, rmrru->end_address);
+scope_devices_free(>scope);
+xfree(rmrru);
+ret = -EFAULT;
+}
+else
+{
+if ( iommu_verbose )
+dprintk(VTDPREFIX,
+"  RMRR region: base_addr %"PRIx64" end_addr %"PRIx64"\n",
+rmrru->base_address, rmrru->end_address);
+acpi_register_rmrr_unit(rmrru);
+}
+
+return ret;
+}
+
 static int __init
 acpi_parse_one_rmrr(struct acpi_dmar_header *header)
 {
@@ -628,65 +690,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
 ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
>scope, RMRR_TYPE, rmrr->segment);
 
-if ( ret || (rmrru->scope.devices_cnt == 0) )
-xfree(rmrru);
+if ( !ret && (rmrru->scope.devices_cnt != 0) )
+ret = register_one_rmrr(rmrru);
 else
-{
-u8 b, d, f;
-bool_t ignore = 0;
-unsigned int i = 0;
-
-/* Skip checking if segment is not accessible yet. */
-if ( !pci_known_segment(rmrr->segment) )
-i = UINT_MAX;
-
-for ( ; i < rmrru->scope.devices_cnt; i++ )
-{
-b = PCI_BUS(rmrru->scope.devices[i]);
-d = PCI_SLOT(rmrru->scope.devices[i]);
-f = PCI_FUNC(rmrru->scope.devices[i]);
-
-if ( !pci_device_detect(rmrr->segment, b, d, f) )
-{
-printk(XENLOG_WARNING VTDPREFIX
-   " Non-existent device (%04x:%02x:%02x.%u) reported in 
RMRR (%"PRIx64", %"PRIx64")'s scope!\n",
-   rmrr->segment, b, d, f,
-   rmrru->base_address, rmrru->end_address);
-ignore = 1;
-}
-else
-{
-ignore = 0;
-break;
-}
-}
-
-if ( ignore )
-{
-printk(XENLOG_WARNING VTDPREFIX
-   "  Ignore RMRR (%"PRIx64", %"PRIx64") (some devices in its 
scope are not PCI discoverable)\n",
-   rmrru->base_address, rmrru->end_address);
-scope_devices_free(>scope);
-xfree(rmrru);
-}
-else if ( base_addr > end_addr )
-{
-printk(XENLOG_WARNING VTDPREFIX
-   "  RMRR (%"PRIx64", %"PRIx64") is incorrect\n",
-   rmrru->base_address, rmrru->end_address);
-scope_devices_free(>scope);
-xfree(rmrru);
-ret = -EFAULT;
-}
-else
-{
-if ( iommu_verbose )
-printk(VTDPREFIX
-   "  RMRR region: base_addr %"PRIx64" end_address 

[Xen-devel] [PATCH v14 0/3] iommu: add rmrr Xen command line option

[Venu Busireddy]

Add Xen command line option rmrr to specify RMRR regions that are not
defined in ACPI thus causing IO Page Faults and prevent dom0 from booting
if "iommu=dom0-strict" option is specified on the Xen command line.
These additional regions will be added to the list of RMRR regions parsed
from ACPI.

Changes in v14:
 - Implement Jan's feedback.
   Rename some #defines and take care of boundary conditions.

Changes in v13:
 - Implement feedback from Kevin Tian.
   https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03169.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03170.html
   https://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03171.html
 - Limit all source lines and comments to 80 characters per line.
 - Implement coding style suggestions from Konrad Wilk.
 - Changed the Author to Elena Ufimtseva 

Changes in v12:
 - Mostly cosmetic fixes from Jan's review on v11.

Changes in v11:
 - changed macro to print extra RMRR ranges and added argument macro;
 - fixed the overlapping check if condition error;
 - fixed the loop exit condition when checking pfn in RMRR region;

Elena Ufimtseva (3):
  iommu VT-d: separate rmrr addition function.
  pci: add wrapper for parse_pci.
  iommu: add rmrr Xen command line option for extra rmrrs

 docs/misc/xen-command-line.markdown |  13 ++
 xen/drivers/passthrough/vtd/dmar.c  | 326 +---
 xen/drivers/pci/pci.c   |  11 ++
 xen/include/xen/pci.h   |   3 +
 4 files changed, 294 insertions(+), 59 deletions(-)


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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Daniel Kiper]

On Mon, Jan 23, 2017 at 10:03:52AM -0600, Doug Goldstein wrote:
> On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote:
> > On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
> >> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> >>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
>  On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > Hi,
> >
> > I am sending twelfth version of multiboot2 protocol support for
> > legacy BIOS and EFI platforms. This patch series release contains
> > fixes for all known/confirmed issues.
> 
>  With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
>  get the following on some of the systems I have access to:
> >
> > Both me and Daniel seem to have test machines with EFI that are not soo .. 
> > defective.
>
> What machines? Model numbers? Manufacture?

We are doing the tests. Until now everything works. I will compile full
list for you when we are finished.

> I'd also argue that this series continues to write into reserved memory
> regions (as confirmed by the fix to 5/10 that I sent in) and you're able

We do tests with your fix for #05 and full v12 patch series.

> to still boot so I wouldn't put much value into the hardware you've been
> using.

I would not comment on that until I know why it does not work on your boxes.

> > Could you mention which boxes have these kinds of trouble so we can
> > get to the bottom of this?
>
> HP ML10v2
> Lenovo T430
> Intel NUC NUC5i5MYHE
> Intel NUC NUC5i3MYHE (oddly has a pretty different firmware than above)
> Mercury LDS3506
> Dell Precision 3420 (co-worker says this is setup to boot BIOS)
> ASUS M3A78-CM motherboard
> ASUS AMD motherboard (I don't have it near me and its not powered on
> right now)
> SuperMicro  (I don't have it near me and its not powered on right
> now so I can't figure it out)
> QEMU + OVMF from Ubuntu 16.10
> QEMU (master from last week) + OVMF (master from last week)

Thanks for the list. Do you use latest firmware on above mentioned machines?
I hope that yes. I am asking just in case.

I am going to release v13 by the end of Wednesday. Should I remove your
Reviewed-by from patch 6-10?

[...]

> > And would it be possible to get serial/power access to this box (Intel NUC?)
> > to figure out what is going on?
>
> Likely not. Both those operations are only available over AMT which is
> connected on our internal corporate network. I can see if I can bring it
> home for a period of time and give you access from my home.

It would be nice.

Daniel

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-boot fail REGR. vs. 104546
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 104546

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

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

version targeted for testing:
 qemuu598cf1c805271564686f2d732b36f50c3c40dcdd
baseline version:
 qemuud1c82f7cc34443841095f490345f86c9d8baca34

Last test of basis   104546  2017-01-21 19:44:02 Z1 days
Testing same since   104605  2017-01-23 10:15:04 Z0 days1 attempts


People who touched revisions under test:
  Caoxinhua 
  Eduardo Habkost 
  hangaohuai 
  Igor Mammedov 
  Leif Lindholm 
  Li Qiang 
  Marc-André Lureau 
  Marcelo Tosatti 
  Paolo Bonzini 
  Peter Lieven 
  Peter Maydell 
  Peter Xu 
  Roman Kapl 
  Stefan Weil 
  Vincent Palatin 
  zhanghailiang 

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

Re: [Xen-devel] PVH CPU hotplug design document

[Roger Pau Monné]

On Mon, Jan 23, 2017 at 12:05:11PM -0500, Boris Ostrovsky wrote:
> On 01/23/2017 11:50 AM, Roger Pau Monné wrote:
> > On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote:
> >> On 01/23/2017 10:58 AM, Jan Beulich wrote:
> >> On 23.01.17 at 16:49,  wrote:
>  On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
> >>> From Linux perspective one option could be to have domU with PV-style
> >>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
> >>> it becomes available. This, however, will need an indication from the
> >>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
> >>> discussed earlier.
> >> I think we shouldn't overload that flag. Didn't we settle already on 
> >> using
> >> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
> >> hot(un)plug)? With that I think I could then be talked into accepting 
> >> the
> >> existence of two different models (and kernels could pick which one(s)
> >> they would like to support).
> > I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
> > which is why I mentioned it now.
> >
> > We can go with CPUID flags although I am not sure why we'd need two. I'd
> > think that OS can be expected to always support PV-style so the flag
> > would indicate support for ACPI-based hotplug.
>  In fact, it doesn't matter whether OS supports PV-style hotplug. It's
>  that Xen will always set appropriate xenstore entry. It's up to the OS
>  whether to watch it and act upon this.
> >>> That's a good point, perhaps just one CPUID flag will do then indeed.
> >> Roger, are you going to include this in your patchset or do you want me
> >> to do it?
> > I think this should be introduced in your DomU ACPI CPU hotplug series, and 
> > not
> > set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 
> > also.
> >
> 
> Right, although my understanding is that the series is on hold until we
> come to agreement about what to do about dom0. But I guess if we agree
> that we'll have a single ACPI hotplug feature bit then we can go ahead
> with Linux domU patches without waiting for Xen ACPI support.

My understanding is that the way forward now is to introduce this bit, use it
in your series and decide what we do with Dom0 when we get to a point that we
can start to test/implement vCPU hotplug there. There's still work to do until
we can get to the point of simply booting a static no-hotplug PVHv2 Dom0.

Roger.

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

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

[Roger Pau Monné]

On Mon, Jan 23, 2017 at 09:55:19AM -0700, Jan Beulich wrote:
> >>> On 23.01.17 at 17:42,  wrote:
> > On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote:
> >> >>> On 17.01.17 at 18:14,  wrote:
> >> > This can be solved by using a different ACPI name in order to describe 
> >> > vCPUs in
> >> > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes 
> >> > for
> >> > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix 
> >> > should
> >> > prevent clashes.
> >> 
> >> I continue to think that this is insufficient, without seeing a nice
> >> clean way to solve the issue properly.
> > 
> > But in this document the namespace path for processor objects will be
> > _SB.XEN0.VPXX, which should prevent any namespace clashes. Maybe I should 
> > have
> > updated the wording here, every Xen-related ACPI bit will be inside the
> > _SB.XEN0 namespace.
> 
> Well, if we want to introduce our own parent name space, why the
> special naming convention then? Any name not colliding with other
> things in _SB.XEN0 should do then, so the only remaining risk would
> then be that the firmware also has _SB.XEN0.

Right, that's why I say that I should have reworded this. We can then use PXXX,
CXXX or whatever we want.

Yes, the only remaining risk is some vendor using _SB.XEN0, and AFAICT there's
no way to reserve anything in there (mostly because it's assumed that ACPI
tables will be created by a single entity I guess).

I think that the chance of this happening is 0%, and that there's no single
system out there with a _SB.XEN0 node. I've been wondering whether I should try
to post this to the ACPI working group, and try to get some feedback there.

Roger.

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

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

On 01/23/2017 11:50 AM, Roger Pau Monné wrote:
> On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote:
>> On 01/23/2017 10:58 AM, Jan Beulich wrote:
>> On 23.01.17 at 16:49,  wrote:
 On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
>>> discussed earlier.
>> I think we shouldn't overload that flag. Didn't we settle already on 
>> using
>> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
>> hot(un)plug)? With that I think I could then be talked into accepting the
>> existence of two different models (and kernels could pick which one(s)
>> they would like to support).
> I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
> which is why I mentioned it now.
>
> We can go with CPUID flags although I am not sure why we'd need two. I'd
> think that OS can be expected to always support PV-style so the flag
> would indicate support for ACPI-based hotplug.
 In fact, it doesn't matter whether OS supports PV-style hotplug. It's
 that Xen will always set appropriate xenstore entry. It's up to the OS
 whether to watch it and act upon this.
>>> That's a good point, perhaps just one CPUID flag will do then indeed.
>> Roger, are you going to include this in your patchset or do you want me
>> to do it?
> I think this should be introduced in your DomU ACPI CPU hotplug series, and 
> not
> set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 also.
>

Right, although my understanding is that the series is on hold until we
come to agreement about what to do about dom0. But I guess if we agree
that we'll have a single ACPI hotplug feature bit then we can go ahead
with Linux domU patches without waiting for Xen ACPI support.


-boris


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

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

[Jan Beulich]

>>> On 23.01.17 at 17:42,  wrote:
> On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote:
>> >>> On 17.01.17 at 18:14,  wrote:
>> > This can be solved by using a different ACPI name in order to describe 
>> > vCPUs in
>> > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes 
>> > for
>> > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix 
>> > should
>> > prevent clashes.
>> 
>> I continue to think that this is insufficient, without seeing a nice
>> clean way to solve the issue properly.
> 
> But in this document the namespace path for processor objects will be
> _SB.XEN0.VPXX, which should prevent any namespace clashes. Maybe I should have
> updated the wording here, every Xen-related ACPI bit will be inside the
> _SB.XEN0 namespace.

Well, if we want to introduce our own parent name space, why the
special naming convention then? Any name not colliding with other
things in _SB.XEN0 should do then, so the only remaining risk would
then be that the firmware also has _SB.XEN0.

Jan


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

Re: [Xen-devel] PVH CPU hotplug design document

[Roger Pau Monné]

On Mon, Jan 23, 2017 at 11:24:19AM -0500, Boris Ostrovsky wrote:
> On 01/23/2017 10:58 AM, Jan Beulich wrote:
>  On 23.01.17 at 16:49,  wrote:
> >> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
> > From Linux perspective one option could be to have domU with PV-style
> > vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
> > it becomes available. This, however, will need an indication from the
> > hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
> > discussed earlier.
>  I think we shouldn't overload that flag. Didn't we settle already on 
>  using
>  two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
>  hot(un)plug)? With that I think I could then be talked into accepting the
>  existence of two different models (and kernels could pick which one(s)
>  they would like to support).
> >>> I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
> >>> which is why I mentioned it now.
> >>>
> >>> We can go with CPUID flags although I am not sure why we'd need two. I'd
> >>> think that OS can be expected to always support PV-style so the flag
> >>> would indicate support for ACPI-based hotplug.
> >> In fact, it doesn't matter whether OS supports PV-style hotplug. It's
> >> that Xen will always set appropriate xenstore entry. It's up to the OS
> >> whether to watch it and act upon this.
> > That's a good point, perhaps just one CPUID flag will do then indeed.
> 
> Roger, are you going to include this in your patchset or do you want me
> to do it?

I think this should be introduced in your DomU ACPI CPU hotplug series, and not
set for Dom0 until we found a way to perform ACPI vCPU hotplug for Dom0 also.

Roger.

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

Re: [Xen-devel] [sun8i][H3] Question about running Xen on OrangePi PC

[bharat gohil]

Thanks Julien,

Finally, I am able to run latest Xen 4.9,latest Linux kernel 4.9 and latest
buildroot on orangepi PC and NenoPi-M1 board.

Now,I want to run RTOS VM on Xen and pin the CPU to RTOS VM so i can
achieve real time response from RTOS VM.

Long term I want to do GPU(on Mali) virtualization If anyone have
experience on GPU(on Mali) virtualization on ARM board,Please provide me
some pointer.

following log of xen on orangePi PC board

U-Boot SPL 2016.09-rc1-00231-g7351bf2-dirty (Aug 09 2016 - 15:01:33)
DRAM: 1024 MiB
Failed to set core voltage! Can't set CPU frequency
Trying to boot from MMC1


U-Boot 2016.09-rc1-00231-g7351bf2-dirty (Aug 09 2016 - 15:01:33 +0530)
Allwinney

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0
*** Warning - bad CRC, using default
environment


In:
serial
Out:
serial
Err:
serial
Net:   phy
interface0
eth0: ethernet@01c3

starting
USB...
USB0:   USB EHCI
1.00
USB1:   USB OHCI
1.0
USB2:   USB EHCI
1.00
USB3:   USB OHCI
1.0
USB4:   USB EHCI
1.00
USB5:   USB OHCI
1.0
scanning bus 0 for devices... 1 USB Device(s)
found
scanning bus 2 for devices... 1 USB Device(s)
found
scanning bus 4 for devices... 1 USB Device(s)
found
Hit any key to stop autoboot:
0
=>

=> setenv bootcmd 'setenv ipaddr 10.90.30.11;setenv serverip
10.90.30.111;tftp '
=>
boot

Using ethernet@01c3
device
TFTP from server 10.90.30.111; our IP address is
10.90.30.11
Filename
'boot.scr'.
Load address:
0x4100
Loading:
#
 10.7
KiB/s
done

Bytes transferred = 1373 (55d
hex)
CACHE: Misaligned operation at range [4100,
4100055d]
## Executing script at
4100
Using ethernet@01c3
device
TFTP from server 10.90.30.111; our IP address is
10.90.30.11
Filename
'xen'.
Load address:
0x7ea0
Loading:
#

#

##
 507.8
KiB/s
done

Bytes transferred = 753680 (b8010
hex)
CACHE: Misaligned operation at range [7ea0,
7eab8010]
Using ethernet@01c3
device
TFTP from server 10.90.30.111; our IP address is
10.90.30.11
Filename
'sun8i-h3-orangepi-pc.dtb'.
Load address:
0x7ec0
Loading:
###
 343.8
KiB/s
done

Bytes transferred = 13056 (3300
hex)
Using ethernet@01c3
device
TFTP from server 10.90.30.111; our IP address is
10.90.30.11
Filename
'zImage'.
Load address:
0x7f60
Loading:
#

#

#

#

#

#

#
 T
#

#

#

#

#
 297.9
KiB/s
done

Bytes transferred = 3660928 (37dc80
hex)
## Flattened Device Tree blob at
7ec0
   Booting using the fdt blob at
0x7ec0
   reserving fdt memory region: addr=7ec0
size=4000
   Using Device Tree in place at 7ec0, end
7ec06fff


Starting kernel
...


- UART enabled
-
- CPU  booting
-
- Xen starting in Hyp mode
-
- Zero BSS
-
- Setting up control registers
-
- Turning on paging
-
- Ready
-
(XEN) Checking for initrd in
/chosen
(XEN) RAM: 4000 -
7fff
(XEN)

(XEN) MODULE[0]: 7ec0 - 7ec04000 Device
Tree
(XEN) MODULE[1]: 7f60 - 7f97dc80 Kernel
console=hvc0 d
(XEN)  RESVD[0]: 7ff9f000 -
7ffa1000
(XEN)  RESVD[1]: 7ec0 -
7ec04000
(XEN)

(XEN) Command line: console=dtuart dtuart=serial0
dom0_mem=128M
(XEN) Placing Xen at
0x7fc0-0x7fe0
(XEN) Update BOOTMOD_XEN from 7ea0-7eafd781 =>
7fc01
(XEN) Xen heap: 7c00-7e00 (8192
pages)
(XEN) Dom heap: 253952
pages
(XEN) Domain heap
initialised
(XEN) Platform: Generic
System
(XEN) Looking for dtuart at "serial0", options
""
 Xen
4.9-unstable
(XEN) Xen version 4.9-unstable (bgohil@) (arm-linux-gnueabi-gcc
(Ubuntu/Linaro 6
(XEN) Latest ChangeSet: Tue Dec 20 11:47:00 2016 -0800
git:74858c9
(XEN) Processor: 410fc075: "ARM Limited", variant: 0x0, part 0xc07, rev
0x5
(XEN) 32-bit
Execution:
(XEN)   Processor Features:
1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE
Jazelle
(XEN) Extensions: GenericTimer
Security
(XEN)   Debug Features:
02010555
(XEN)   Auxiliary Features:

(XEN)   Memory Model Features: 10101105 4000 0124
02102211
(XEN)  ISA Features: 02101110 13112111 

[Xen-devel] [PATCH RFC 1/8] golang/xenlight: Create stub package

[Ronald Rojas]

Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package which only opens libxl context.

Include a global xenlight.Ctx variable which can be used as the
default context by the entire program if desired.

For now, return simple errors. Proper error handling will be
added in next patch.

Signed-off-by: Ronald Rojas 
---
 tools/Makefile| 17 
 tools/golang/xenlight/Makefile| 31 ++
 tools/golang/xenlight/xenlight.go | 86 +++
 3 files changed, 134 insertions(+)
 create mode 100644 tools/golang/xenlight/Makefile
 create mode 100644 tools/golang/xenlight/xenlight.go

diff --git a/tools/Makefile b/tools/Makefile
index 77e0723..c1e975f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -11,6 +11,8 @@ SUBDIRS-y += xenstore
 SUBDIRS-y += misc
 SUBDIRS-y += examples
 SUBDIRS-y += hotplug
+#Uncomment line to build Golang libxl
+#SUBDIRS-y += golang/xenlight
 SUBDIRS-y += xentrace
 SUBDIRS-$(CONFIG_XCUTILS) += xcutils
 SUBDIRS-$(CONFIG_X86) += firmware
@@ -303,6 +305,21 @@ subdir-clean-qemu-xen-dir:
$(MAKE) -C qemu-xen-dir clean; \
fi
 
+subdir-clean-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight clean
+
+subdir-distclean-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight distclean
+
+subdir-install-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight install
+
+subdir-all-golang/xenlight: .phony
+   $(MAKE) -C golang/xenlight all
+
+subdir-distclean-firmware: .phony
+   $(MAKE) -C firmware distclean
+
 subdir-clean-debugger/gdbsx subdir-distclean-debugger/gdbsx: .phony
$(MAKE) -C debugger/gdbsx clean
 
diff --git a/tools/golang/xenlight/Makefile b/tools/golang/xenlight/Makefile
new file mode 100644
index 000..1c2a2b7
--- /dev/null
+++ b/tools/golang/xenlight/Makefile
@@ -0,0 +1,31 @@
+XEN_ROOT=$(CURDIR)/../../..
+GOLANG_SRC=$(GOPATH)/src/xenproject.org/xenlight
+CGO_CFLAGS = -I$(DESTDIR)$(includedir)
+CGO_LDFLAGS = -L$(DESTDIR)$(libdir) -Wl,-rpath-link=$(DESTDIR)$(libdir)
+include $(XEN_ROOT)/tools/Rules.mk
+
+BINARY = xenlight.a
+GO ?= go
+
+.PHONY: all
+all: build
+
+.PHONY: build
+build: xenlight.a
+
+.PHONY: install
+install: build
+   $(INSTALL_DIR) $(DESTDIR)$(GOLANG_SRC)
+   $(INSTALL_DATA) xenlight.go $(DESTDIR)$(GOLANG_SRC)
+
+.PHONY: clean
+clean:
+   $(RM) $(BINARY)
+
+.PHONY: distclean
+distclean: clean
+
+xenlight.a: xenlight.go
+   CGO_CFLAGS="$(CGO_CFLAGS)" CGO_LDFLAGS="$(CGO_LDFLAGS)" $(GO) build -o 
$@ $<
+
+-include $(DEPS)
diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
new file mode 100644
index 000..f82e14e
--- /dev/null
+++ b/tools/golang/xenlight/xenlight.go
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2016 George W. Dunlap, Citrix Systems UK Ltd
+ *
+ * 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; version 2 of the
+ * License only.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ */
+package xenlight
+
+/*
+#cgo LDFLAGS: -lxenlight -lyajl
+#include 
+#include 
+*/
+import "C"
+
+/*
+ * Other flags that may be needed at some point:
+ *  -lnl-route-3 -lnl-3
+ *
+ * To get back to static linking:
+ * #cgo LDFLAGS: -lxenlight -lyajl_s -lxengnttab -lxenstore -lxenguest 
-lxentoollog -lxenevtchn -lxenctrl -lblktapctl -lxenforeignmemory -lxencall -lz 
-luuid -lutil
+*/
+
+import (
+   "fmt"
+   "unsafe"
+)
+
+
+/*
+ * Types: Builtins
+ */
+type Context struct {
+   ctx *C.libxl_ctx
+}
+
+/*
+ * Context
+ */
+var Ctx Context
+
+func (Ctx *Context) IsOpen() bool {
+   return Ctx.ctx != nil
+}
+
+func (Ctx *Context) Open() (err error) {
+   if Ctx.ctx != nil {
+   return
+   }
+
+   ret := C.libxl_ctx_alloc(unsafe.Pointer(), C.LIBXL_VERSION, 0, 
nil)
+
+   if ret != 0 {
+   err = Error(-ret)
+   }
+   return
+}
+
+func (Ctx *Context) Close() (err error) {
+   ret := C.libxl_ctx_free(unsafe.Pointer(Ctx.ctx))
+   Ctx.ctx = nil
+
+   if ret != 0 {
+   err = Error(-ret)
+   }
+   return
+}
+
+func (Ctx *Context) CheckOpen() (err error) {
+   if Ctx.ctx == nil {
+   err = fmt.Errorf("Context not opened")
+   }
+   return
+}
\ No newline at end of file
-- 
2.7.4


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

[Xen-devel] [PATCH RFC 6/8] golang/xenlight: Implement libxl_bitmap and helper operations

[Ronald Rojas]

Implement Bitmap type, along with helper functions.

The Bitmap type is implemented interllay in a way which makes it
easy to copy into and out of the C libxl_bitmap type.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
 tools/golang/xenlight/xenlight.go | 166 ++
 1 file changed, 166 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index dd6893c..54692fd 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -131,6 +131,19 @@ func (chwcap C.libxl_hwcap)CToGo() (ghwcap Hwcap) {
return
 }
 
+// typedef struct {
+// uint32_t size;  /* number of bytes in map */
+// uint8_t *map;
+// } libxl_bitmap;
+
+// Implement the Go bitmap type such that the underlying data can
+// easily be copied in and out.  NB that we still have to do copies
+// both directions, because cgo runtime restrictions forbid passing to
+// a C function a pointer to a Go-allocated structure which contains a
+// pointer.
+type Bitmap struct {
+   bitmap []C.uint8_t
+}
 
 /*
  * Types: IDL
@@ -199,6 +212,159 @@ type Dominfo struct {
 }
 
 /*
+ * Bitmap operations
+ */
+
+// Return a Go bitmap which is a copy of the referred C bitmap.
+func (cbm C.libxl_bitmap) CToGo() (gbm Bitmap) {
+   // Alloc a Go slice for the bytes
+   size := int(cbm.size)
+   gbm.bitmap = make([]C.uint8_t, size)
+
+   // Make a slice pointing to the C array
+   mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
+
+   // And copy the C array into the Go array
+   copy(gbm.bitmap, mapslice)
+
+   return
+}
+
+// Must be C.libxl_bitmap_dispose'd of afterwards
+func (gbm Bitmap)GoToC() (cbm C.libxl_bitmap) {
+   C.libxl_bitmap_init()
+
+   size := len(gbm.bitmap)
+   cbm._map = (*C.uint8_t)(C.malloc(C.size_t(size)))
+   cbm.size = C.uint32_t(size)
+   if cbm._map == nil {
+   panic("C.calloc failed!")
+   }
+
+   // Make a slice pointing to the C array
+   mapslice := (*[1 << 30]C.uint8_t)(unsafe.Pointer(cbm._map))[:size:size]
+
+   // And copy the Go array into the C array
+   copy(mapslice, gbm.bitmap)
+
+   return
+}
+
+func (bm *Bitmap) Test(bit int) bool {
+   ubit := uint(bit)
+   if bit > bm.Max() || bm.bitmap == nil {
+   return false
+   }
+
+   return (bm.bitmap[bit/8] & (1 << (ubit & 7))) != 0
+}
+
+func (bm *Bitmap) Set(bit int) {
+   ibit := bit / 8
+   if ibit+1 > len(bm.bitmap) {
+   bm.bitmap = append(bm.bitmap, make([]C.uint8_t, 
ibit+1-len(bm.bitmap))...)
+   }
+
+   bm.bitmap[ibit] |= 1 << (uint(bit) & 7)
+}
+
+func (bm *Bitmap) SetRange(start int, end int) {
+   for i := start; i <= end; i++ {
+   bm.Set(i)
+   }
+}
+
+func (bm *Bitmap) Clear(bit int) {
+   ubit := uint(bit)
+   if bit > bm.Max() || bm.bitmap == nil {
+   return
+   }
+
+   bm.bitmap[bit/8] &= ^(1 << (ubit & 7))
+}
+
+func (bm *Bitmap) ClearRange(start int, end int) {
+   for i := start; i <= end; i++ {
+   bm.Clear(i)
+   }
+}
+
+func (bm *Bitmap) Max() int {
+   return len(bm.bitmap)*8 - 1
+}
+
+func (bm *Bitmap) IsEmpty() bool {
+   for i := 0; i < len(bm.bitmap); i++ {
+   if bm.bitmap[i] != 0 {
+   return false
+   }
+   }
+   return true
+}
+
+func (a Bitmap) And(b Bitmap) (c Bitmap) {
+   var max, min int
+   if len(a.bitmap) > len(b.bitmap) {
+   max = len(a.bitmap)
+   min = len(b.bitmap)
+   } else {
+   max = len(b.bitmap)
+   min = len(a.bitmap)
+   }
+   c.bitmap = make([]C.uint8_t, max)
+
+   for i := 0; i < min; i++ {
+   c.bitmap[i] = a.bitmap[i] & b.bitmap[i]
+   }
+   return
+}
+
+func (bm Bitmap) String() (s string) {
+   lastOnline := false
+   crange := false
+   printed := false
+   var i int
+   /// --x-x-x -> 2,4-8,10
+   /// --x-xxx -> 2,4-10
+   for i = 0; i <= bm.Max(); i++ {
+   if bm.Test(i) {
+   if !lastOnline {
+   // Switching offline -> online, print this cpu
+   if printed {
+   s += ","
+   }
+   s += fmt.Sprintf("%d", i)
+   printed = true
+   } else if !crange {
+   // last was online, but we're not in a range; 
print -
+   crange = true
+   s += "-"
+   } else {
+   // last was online, we're in a range,  nothing 
else to do
+   }
+   

[Xen-devel] [PATCH RFC 4/8] golang/xenlight: Implement libxl_domain_info and libxl_domain_unpause

[Ronald Rojas]

Add calls for the following host-related functionality:
- libxl_domain_info
- libxl_domain_unpause

Include Golang version for the libxl_domain_info as
DomainInfo.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
 tools/golang/xenlight/xenlight.go | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 92410a8..dd6893c 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -36,6 +36,7 @@ import "C"
 import (
"fmt"
"unsafe"
+   "time"
 )
 
 /*
@@ -104,6 +105,12 @@ var errors = [...]string{
  * Types: Builtins
  */
 
+type Domid uint32
+
+type MemKB uint64
+
+type Uuid C.libxl_uuid
+
 type Context struct {
ctx *C.libxl_ctx
 }
@@ -165,6 +172,32 @@ type VersionInfo struct {
BuildId  string
 }
 
+type Dominfo struct {
+   Uuid   Uuid
+   Domid  Domid
+   Ssidref uint32
+   SsidLabel string
+   Runningbool
+   Blockedbool
+   Paused bool
+   Shutdown   bool
+   Dying  bool
+   NeverStop bool
+
+   ShutdownReason   int32 // FIXME shutdown_reason enumeration
+   OutstandingMemkb MemKB
+   CurrentMemkb MemKB
+   SharedMemkb  MemKB
+   PagedMemkb   MemKB
+   MaxMemkb MemKB
+   CpuTime  time.Duration
+   VcpuMaxId   uint32
+   VcpuOnline   uint32
+   Cpupool   uint32
+   DomainType   int32 //FIXME libxl_domain_type enumeration
+
+}
+
 /*
  * Context
  */
@@ -343,3 +376,62 @@ func (Ctx *Context) GetVersionInfo() (info *VersionInfo, 
err error) {
 
return
 }
+
+func (Ctx *Context) DomainInfo(Id Domid) (di *Dominfo, err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var cdi C.libxl_dominfo
+
+   ret := C.libxl_domain_info(Ctx.ctx, unsafe.Pointer(), 
C.uint32_t(Id))
+
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   // We could consider having this boilerplate generated by the
+   // idl, in a function like this:
+   //
+   // di = translateCdomaininfoToGoDomaininfo(cdi)
+   di = {}
+   di.Uuid = Uuid(cdi.uuid)
+   di.Domid = Domid(cdi.domid)
+   di.Ssidref = uint32(cdi.ssidref)
+   di.SsidLabel = C.GoString(cdi.ssid_label)
+   di.Running = bool(cdi.running)
+   di.Blocked = bool(cdi.blocked)
+   di.Paused = bool(cdi.paused)
+   di.Shutdown = bool(cdi.shutdown)
+   di.Dying = bool(cdi.dying)
+   di.NeverStop= bool(cdi.never_stop)
+   di.ShutdownReason= int32(cdi.shutdown_reason)
+   di.OutstandingMemkb= MemKB(cdi.outstanding_memkb)
+   di.CurrentMemkb = MemKB(cdi.current_memkb)
+   di.SharedMemkb = MemKB(cdi.shared_memkb)
+   di.PagedMemkb = MemKB(cdi.paged_memkb)
+   di.MaxMemkb= MemKB(cdi.max_memkb)
+   di.CpuTime= time.Duration(cdi.cpu_time)
+   di.VcpuMaxId = uint32(cdi.vcpu_max_id)
+   di.VcpuOnline = uint32(cdi.vcpu_online)
+   di.Cpupool = uint32(cdi.cpupool)
+   di.DomainType = int32(cdi.domain_type)
+
+   return
+}
+
+func (Ctx *Context) DomainUnpause(Id Domid) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_domain_unpause(Ctx.ctx, C.uint32_t(Id))
+
+   if ret != 0 {
+   err = Error(-ret)
+   }
+   return
+}
-- 
2.7.4


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

[Xen-devel] [PATCH RFC 8/8] golang/xenlight: Implement cpupool operations

[Ronald Rojas]

Include some useful "Utility" functions:
- CpupoolFindByName
- CpupoolMakeFree

Still need to implement the following functions:
- libxl_cpupool_rename
- libxl_cpupool_cpuadd_node
- libxl_cpupool_cpuremove_node
- libxl_cpupool_movedomain

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
 tools/golang/xenlight/xenlight.go | 238 ++
 1 file changed, 238 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 0990f07..c856284 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -273,6 +273,244 @@ func SchedulerFromString(name string) (s Scheduler, err 
error) {
return
 }
 
+
+// libxl_cpupoolinfo = Struct("cpupoolinfo", [
+// ("poolid",  uint32),
+// ("pool_name",   string),
+// ("sched",   libxl_scheduler),
+// ("n_dom",   uint32),
+// ("cpumap",  libxl_bitmap)
+// ], dir=DIR_OUT)
+
+type CpupoolInfo struct {
+   Poolid  uint32
+   PoolNamestring
+   Scheduler   Scheduler
+   DomainCount int
+   Cpumap  Bitmap
+}
+
+func (cci C.libxl_cpupoolinfo)CToGo ()(gci CpupoolInfo) {
+   gci.Poolid = uint32(cci.poolid)
+   gci.PoolName = C.GoString(cci.pool_name)
+   gci.Scheduler = Scheduler(cci.sched)
+   gci.DomainCount = int(cci.n_dom)
+   gci.Cpumap = cci.cpumap.CToGo()
+
+   return
+}
+
+// libxl_cpupoolinfo * libxl_list_cpupool(libxl_ctx*, int *nb_pool_out);
+// void libxl_cpupoolinfo_list_free(libxl_cpupoolinfo *list, int nb_pool);
+func (Ctx *Context) ListCpupool() (list []CpupoolInfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var nbPool C.int
+
+   c_cpupool_list := C.libxl_list_cpupool(Ctx.ctx, )
+
+   defer C.libxl_cpupoolinfo_list_free(c_cpupool_list, nbPool)
+
+   if int(nbPool) == 0 {
+   return
+   }
+
+   // Magic
+   cpupoolListSlice := (*[1 << 
30]C.libxl_cpupoolinfo)(unsafe.Pointer(c_cpupool_list))[:nbPool:nbPool]
+
+   for i := range cpupoolListSlice {
+   info := cpupoolListSlice[i].CToGo()
+
+   list = append(list, info)
+   }
+
+   return
+}
+
+// int libxl_cpupool_info(libxl_ctx *ctx, libxl_cpupoolinfo *info, uint32_t 
poolid);
+func (Ctx *Context) CpupoolInfo(Poolid uint32) (pool CpupoolInfo) {
+   err := Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   var c_cpupool C.libxl_cpupoolinfo
+
+   ret := C.libxl_cpupool_info(Ctx.ctx, _cpupool, C.uint32_t(Poolid))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+   defer C.libxl_cpupoolinfo_dispose(_cpupool)
+
+   pool = c_cpupool.CToGo()
+
+   return
+}
+
+// int libxl_cpupool_create(libxl_ctx *ctx, const char *name,
+//  libxl_scheduler sched,
+//  libxl_bitmap cpumap, libxl_uuid *uuid,
+//  uint32_t *poolid);
+// FIXME: uuid
+// FIXME: Setting poolid
+func (Ctx *Context) CpupoolCreate(Name string, Scheduler Scheduler, Cpumap 
Bitmap) (err error, Poolid uint32) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   poolid := C.uint32_t(0)
+   name := C.CString(Name)
+   defer C.free(unsafe.Pointer(name))
+
+   // For now, just do what xl does, and make a new uuid every time we 
create the pool
+   var uuid C.libxl_uuid
+   C.libxl_uuid_generate()
+
+   cbm := Cpumap.GoToC()
+   defer C.libxl_bitmap_dispose()
+
+   ret := C.libxl_cpupool_create(Ctx.ctx, name, 
C.libxl_scheduler(Scheduler),
+   cbm, , )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   Poolid = uint32(poolid)
+
+   return
+}
+
+// int libxl_cpupool_destroy(libxl_ctx *ctx, uint32_t poolid);
+func (Ctx *Context) CpupoolDestroy(Poolid uint32) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_cpupool_destroy(Ctx.ctx, C.uint32_t(Poolid))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   return
+}
+
+// int libxl_cpupool_cpuadd(libxl_ctx *ctx, uint32_t poolid, int cpu);
+func (Ctx *Context) CpupoolCpuadd(Poolid uint32, Cpu int) (err error) {
+   err = Ctx.CheckOpen()
+   if err != nil {
+   return
+   }
+
+   ret := C.libxl_cpupool_cpuadd(Ctx.ctx, C.uint32_t(Poolid), C.int(Cpu))
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   return
+}
+
+// int libxl_cpupool_cpuadd_cpumap(libxl_ctx *ctx, uint32_t poolid,
+// const libxl_bitmap *cpumap);
+func (Ctx *Context) CpupoolCpuaddCpumap(Poolid uint32, Cpumap Bitmap) (err 
error) {
+   err = 

[Xen-devel] [PATCH RFC 7/8] golang/xenlight: Implement libxl_scheduler enumeration

[Ronald Rojas]

Include both constants and a Stringification for libxl_scheduler.

Signed-off-by: George Dunlap 
Signed-off-by: Ronald Rojas 
---
 tools/golang/xenlight/xenlight.go | 62 +++
 1 file changed, 62 insertions(+)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index 54692fd..0990f07 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -211,6 +211,68 @@ type Dominfo struct {
 
 }
 
+// # Consistent with values defined in domctl.h
+// # Except unknown which we have made up
+// libxl_scheduler = Enumeration("scheduler", [
+// (0, "unknown"),
+// (4, "sedf"),
+// (5, "credit"),
+// (6, "credit2"),
+// (7, "arinc653"),
+// (8, "rtds"),
+// ])
+type Scheduler int
+
+var (
+   SchedulerUnknown  Scheduler = C.LIBXL_SCHEDULER_UNKNOWN
+   SchedulerSedf Scheduler = C.LIBXL_SCHEDULER_SEDF
+   SchedulerCredit   Scheduler = C.LIBXL_SCHEDULER_CREDIT
+   SchedulerCredit2  Scheduler = C.LIBXL_SCHEDULER_CREDIT2
+   SchedulerArinc653 Scheduler = C.LIBXL_SCHEDULER_ARINC653
+   SchedulerRTDS Scheduler = C.LIBXL_SCHEDULER_RTDS
+)
+
+// const char *libxl_scheduler_to_string(libxl_scheduler p);
+func (s Scheduler) String() string {
+   cs := C.libxl_scheduler_to_string(C.libxl_scheduler(s))
+   // No need to free const return value
+
+   return C.GoString(cs)
+}
+
+// int libxl_scheduler_from_string(const char *s, libxl_scheduler *e);
+func (s *Scheduler) FromString(gstr string) (err error) {
+   cstr := C.CString(gstr)
+   defer C.free(unsafe.Pointer(cstr))
+
+   var cs C.libxl_scheduler
+   ret := C.libxl_scheduler_from_string(cstr, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   *s = Scheduler(cs)
+   return
+}
+
+func SchedulerFromString(name string) (s Scheduler, err error) {
+   cname := C.CString(name)
+   defer C.free(unsafe.Pointer(cname))
+
+   var cs C.libxl_scheduler
+
+   ret := C.libxl_scheduler_from_string(cname, )
+   if ret != 0 {
+   err = Error(-ret)
+   return
+   }
+
+   s = Scheduler(cs)
+
+   return
+}
+
 /*
  * Bitmap operations
  */
-- 
2.7.4


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

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

[Roger Pau Monné]

On Mon, Jan 23, 2017 at 09:30:30AM -0700, Jan Beulich wrote:
> >>> On 17.01.17 at 18:14,  wrote:
> > This can be solved by using a different ACPI name in order to describe 
> > vCPUs in
> > the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for
> > the processor objects, so using a 'VP' (ie: Virtual Processor) prefix should
> > prevent clashes.
> 
> I continue to think that this is insufficient, without seeing a nice
> clean way to solve the issue properly.

But in this document the namespace path for processor objects will be
_SB.XEN0.VPXX, which should prevent any namespace clashes. Maybe I should have
updated the wording here, every Xen-related ACPI bit will be inside the
_SB.XEN0 namespace.

Roger.

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

[Xen-devel] [PATCH RFC 2/8] golang/xenlight: Add error constants and standard handling

[Ronald Rojas]

Create error type Errorxl for throwing proper xenlight
errors.

Update Ctx functions to throw Errorxl errors.

Signed-off-by: Ronald Rojas 
---
 tools/golang/xenlight/xenlight.go | 75 ++-
 1 file changed, 74 insertions(+), 1 deletion(-)

diff --git a/tools/golang/xenlight/xenlight.go 
b/tools/golang/xenlight/xenlight.go
index f82e14e..eee2254 100644
--- a/tools/golang/xenlight/xenlight.go
+++ b/tools/golang/xenlight/xenlight.go
@@ -38,10 +38,72 @@ import (
"unsafe"
 )
 
+/*
+ * Errors
+ */
+
+type Error int
+
+const (
+   ErrorNonspecific  = Error(-C.ERROR_NONSPECIFIC)
+   ErrorVersion  = Error(-C.ERROR_VERSION)
+   ErrorFail = Error(-C.ERROR_FAIL)
+   ErrorNi   = Error(-C.ERROR_NI)
+   ErrorNomem= Error(-C.ERROR_NOMEM)
+   ErrorInval= Error(-C.ERROR_INVAL)
+   ErrorBadfail  = Error(-C.ERROR_BADFAIL)
+   ErrorGuestTimedout= Error(-C.ERROR_GUEST_TIMEDOUT)
+   ErrorTimedout = Error(-C.ERROR_TIMEDOUT)
+   ErrorNoparavirt   = Error(-C.ERROR_NOPARAVIRT)
+   ErrorNotReady = Error(-C.ERROR_NOT_READY)
+   ErrorOseventRegFail   = Error(-C.ERROR_OSEVENT_REG_FAIL)
+   ErrorBufferfull   = Error(-C.ERROR_BUFFERFULL)
+   ErrorUnknownChild = Error(-C.ERROR_UNKNOWN_CHILD)
+   ErrorLockFail = Error(-C.ERROR_LOCK_FAIL)
+   ErrorJsonConfigEmpty  = Error(-C.ERROR_JSON_CONFIG_EMPTY)
+   ErrorDeviceExists = Error(-C.ERROR_DEVICE_EXISTS)
+   ErrorCheckpointDevopsDoesNotMatch = 
Error(-C.ERROR_CHECKPOINT_DEVOPS_DOES_NOT_MATCH)
+   ErrorCheckpointDeviceNotSupported = 
Error(-C.ERROR_CHECKPOINT_DEVICE_NOT_SUPPORTED)
+   ErrorVnumaConfigInvalid   = Error(-C.ERROR_VNUMA_CONFIG_INVALID)
+   ErrorDomainNotfound   = Error(-C.ERROR_DOMAIN_NOTFOUND)
+   ErrorAborted  = Error(-C.ERROR_ABORTED)
+   ErrorNotfound = Error(-C.ERROR_NOTFOUND)
+   ErrorDomainDestroyed  = Error(-C.ERROR_DOMAIN_DESTROYED)
+   ErrorFeatureRemoved   = Error(-C.ERROR_FEATURE_REMOVED)
+)
+
+var errors = [...]string{
+   ErrorNonspecific: "Non-specific error",
+   ErrorVersion: "Wrong version",
+   ErrorFail: "Failed",
+   ErrorNi: "Not Implemented",
+   ErrorNomem: "No memory",
+   ErrorInval: "Invalid argument",
+   ErrorBadfail: "Bad Fail",
+   ErrorGuestTimedout: "Guest timed out",
+   ErrorTimedout: "Timed out",
+   ErrorNoparavirt: "No Paravirtualization",
+   ErrorNotReady: "Not ready",
+   ErrorOseventRegFail: "OS event registration failed",
+   ErrorBufferfull: "Buffer full",
+   ErrorUnknownChild: "Unknown child",
+   ErrorLockFail: "Lock failed",
+   ErrorJsonConfigEmpty: "JSON config empty",
+   ErrorDeviceExists: "Device exists",
+   ErrorCheckpointDevopsDoesNotMatch: "Checkpoint devops does not match",
+   ErrorCheckpointDeviceNotSupported: "Checkpoint device not supported",
+   ErrorVnumaConfigInvalid: "VNUMA config invalid",
+   ErrorDomainNotfound: "Domain not found",
+   ErrorAborted: "Aborted",
+   ErrorNotfound: "Not found",
+   ErrorDomainDestroyed: "Domain destroyed",
+   ErrorFeatureRemoved: "Feature removed",
+}
 
 /*
  * Types: Builtins
  */
+
 type Context struct {
ctx *C.libxl_ctx
 }
@@ -51,6 +113,17 @@ type Context struct {
  */
 var Ctx Context
 
+func (e Error) Error() string{
+   if 0< int(e) && int(e) < len(errors){
+   s:= errors[e]
+   if s != ""{
+   return s
+   }
+   }
+   return fmt.Sprintf("libxl error: %d", -e)
+
+}
+
 func (Ctx *Context) IsOpen() bool {
return Ctx.ctx != nil
 }
@@ -83,4 +156,4 @@ func (Ctx *Context) CheckOpen() (err error) {
err = fmt.Errorf("Context not opened")
}
return
-}
\ No newline at end of file
+}
-- 
2.7.4


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

Re: [Xen-devel] [DRAFT C] PVH CPU hotplug design document

[Jan Beulich]

>>> On 17.01.17 at 18:14,  wrote:
> This can be solved by using a different ACPI name in order to describe vCPUs 
> in
> the ACPI namespace. Most hardware vendors tend to use CPU or PR prefixes for
> the processor objects, so using a 'VP' (ie: Virtual Processor) prefix should
> prevent clashes.

I continue to think that this is insufficient, without seeing a nice
clean way to solve the issue properly.

Jan


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

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

On 01/23/2017 10:58 AM, Jan Beulich wrote:
 On 23.01.17 at 16:49,  wrote:
>> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
> From Linux perspective one option could be to have domU with PV-style
> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
> it becomes available. This, however, will need an indication from the
> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
> discussed earlier.
 I think we shouldn't overload that flag. Didn't we settle already on using
 two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
 hot(un)plug)? With that I think I could then be talked into accepting the
 existence of two different models (and kernels could pick which one(s)
 they would like to support).
>>> I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
>>> which is why I mentioned it now.
>>>
>>> We can go with CPUID flags although I am not sure why we'd need two. I'd
>>> think that OS can be expected to always support PV-style so the flag
>>> would indicate support for ACPI-based hotplug.
>> In fact, it doesn't matter whether OS supports PV-style hotplug. It's
>> that Xen will always set appropriate xenstore entry. It's up to the OS
>> whether to watch it and act upon this.
> That's a good point, perhaps just one CPUID flag will do then indeed.

Roger, are you going to include this in your patchset or do you want me
to do it?

-boris


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

Re: [Xen-devel] [PATCH v7 06/14] firmware/Makefile: force recompilation if makefile changes

[Luis R. Rodriguez]

On Thu, Jan 19, 2017 at 12:19:15PM +0100, Greg KH wrote:
> On Sun, Jan 15, 2017 at 01:10:49PM -0800, Luis R. Rodriguez wrote:
> > If you modify the target asm we currently do not force the
> > recompilation of the firmware files. The target asm is in
> > the firmware/Makefile, peg this file as a dependency to
> > require re-compilation of firmware targets when the asm
> > changes.
> > 
> > v3: introduced in this series
> > 
> > Signed-off-by: Luis R. Rodriguez 
> > ---
> >  firmware/Makefile | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/firmware/Makefile b/firmware/Makefile
> > index e297e1b52636..fa3e81c2a97b 100644
> > --- a/firmware/Makefile
> > +++ b/firmware/Makefile
> > @@ -176,7 +176,8 @@ quiet_cmd_fwbin = MK_FW   $@
> >  wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \
> > include/config/ppc32.h include/config/ppc64.h \
> > include/config/superh32.h include/config/superh64.h \
> > -   include/config/x86_32.h include/config/x86_64.h)
> > +   include/config/x86_32.h include/config/x86_64.h \
> > +   firmware/Makefile)
> >  
> >  $(patsubst %,$(obj)/%.gen.S, $(fw-shipped-y)): %: $(wordsize_deps)
> > $(call cmd,fwbin,$(patsubst %.gen.S,%,$@))
> 
> I don't understand why this patch is in this series :(

I've taken it out and it has now been routed via kbuild folks as you
requested.

Thanks!

  Luis

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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Doug Goldstein]

On 1/23/17 9:45 AM, Daniel Kiper wrote:
> On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
>> On 1/23/17 7:08 AM, Daniel Kiper wrote:
>>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
 On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>> Hi,
>>
>> I am sending twelfth version of multiboot2 protocol support for
>> legacy BIOS and EFI platforms. This patch series release contains
>> fixes for all known/confirmed issues.
>
> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> get the following on some of the systems I have access to:
>
> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> (XEN) [7.012109] Stuck ??
> (XEN) [7.012129] Failed to bring up CPU 1 (error -5)
> (XEN) [   12.023606] Stuck ??
> (XEN) [   12.023622] Failed to bring up CPU 2 (error -5)
> (XEN) [   17.035099] Stuck ??
> (XEN) [   17.035115] Failed to bring up CPU 3 (error -5)
> (XEN) [   17.035116] Brought up 1 CPUs
>
> On other machines they reset when setting PAGING into cr0 (actually the
> jmp following it) on line 124 of trampoline.S

 Thanks! I will take a look.

> If I drop the series to just 2-5 against staging (since patch 1 has
> already gone in) and apply the fix to efi_multiboot2() then all the
> machines I presently have access to boot.

 Great!

> Effectively the fix to efi_multiboot2() gets us back to the same level
> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>
> Reviewed-by: Doug Goldstein 
> Tested-by: Doug Goldstein 

 Thanks!

> on the condition that the fix is applied to 5/10 prior to commit.

 Will do.

 By the way, I have asked my team colleagues to do more tests of this 
 series.
 I will come back to you if I have something in hand.
>>>
>>> Once you told me that you applied some patches on top of my patch series to 
>>> get
>>> it working. Is it still true? If you still use some extra patches could you 
>>> send
>>> me them? What about ExitBootServices() call? Did you disabled it? If yes on 
>>> which
>>> machines it have to be disabled?
>>>
>>> Daniel
>>>
>>
>> I previously used the patch that I linked to you authored by Konrad. I
>> have since switched to the patches that XenServer uses to no-op
>> efi_get_time() and to map additional ranges of reserved memory to make
>> EBS() work.
> 
> Could you send me them?
> 
> Daniel
> 

I apply them only for 2 out of the roughly dozen machines. Its not those
changes.

https://github.com/xenserver/xen-4.7.pg/blob/master/master/0002-efi-Ensure-incorrectly-typed-runtime-services-get-ma.patch

https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-x86-time-Don-t-use-EFI-s-GetTime-call.patch

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Doug Goldstein]

On 1/23/17 8:28 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
>> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
 On 1/19/17 8:34 PM, Daniel Kiper wrote:
> Hi,
>
> I am sending twelfth version of multiboot2 protocol support for
> legacy BIOS and EFI platforms. This patch series release contains
> fixes for all known/confirmed issues.

 With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
 get the following on some of the systems I have access to:
> 
> 
> Both me and Daniel seem to have test machines with EFI that are not soo .. 
> defective.

What machines? Model numbers? Manufacture?

I'd also argue that this series continues to write into reserved memory
regions (as confirmed by the fix to 5/10 that I sent in) and you're able
to still boot so I wouldn't put much value into the hardware you've been
using.

> 
> Could you mention which boxes have these kinds of trouble so we can
> get to the bottom of this?

HP ML10v2
Lenovo T430
Intel NUC NUC5i5MYHE
Intel NUC NUC5i3MYHE (oddly has a pretty different firmware than above)
Mercury LDS3506
Dell Precision 3420 (co-worker says this is setup to boot BIOS)
ASUS M3A78-CM motherboard
ASUS AMD motherboard (I don't have it near me and its not powered on
right now)
SuperMicro  (I don't have it near me and its not powered on right
now so I can't figure it out)
QEMU + OVMF from Ubuntu 16.10
QEMU (master from last week) + OVMF (master from last week)

The two unknowns are machines I've got at home and I had unplugged
everything while I was on vacation to hopefully avoid lightning strike
damage.

> 
> [Is it by any chance a T420 or x230 laptop - I am using legacy BIOS on them
> as I couldn't even get them to suspend properly]

I'm using EFI on my T430.

> 
> And would it be possible to get serial/power access to this box (Intel NUC?)
> to figure out what is going on?

Likely not. Both those operations are only available over AMT which is
connected on our internal corporate network. I can see if I can bring it
home for a period of time and give you access from my home.

-- 
Doug Goldstein



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

Re: [Xen-devel] PVH CPU hotplug design document

[Jan Beulich]

>>> On 23.01.17 at 16:49,  wrote:
> On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
 From Linux perspective one option could be to have domU with PV-style
 vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
 it becomes available. This, however, will need an indication from the
 hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
 discussed earlier.
>>> I think we shouldn't overload that flag. Didn't we settle already on using
>>> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
>>> hot(un)plug)? With that I think I could then be talked into accepting the
>>> existence of two different models (and kernels could pick which one(s)
>>> they would like to support).
>> I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
>> which is why I mentioned it now.
>>
>> We can go with CPUID flags although I am not sure why we'd need two. I'd
>> think that OS can be expected to always support PV-style so the flag
>> would indicate support for ACPI-based hotplug.
> 
> In fact, it doesn't matter whether OS supports PV-style hotplug. It's
> that Xen will always set appropriate xenstore entry. It's up to the OS
> whether to watch it and act upon this.

That's a good point, perhaps just one CPUID flag will do then indeed.

Jan


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

Re: [Xen-devel] [PATCH 4/5] xen: sched: impove use of cpumask scratch space in Credit1.

[George Dunlap]

On Tue, Jan 17, 2017 at 5:27 PM, Dario Faggioli
 wrote:
> It is ok to use just cpumask_scratch in csched_runq_steal().
> In fact, the cpu parameter comes from the cpu local variable
> in csched_load_balance(), which in turn comes from cpu in
> csched_schedule(), which is smp_processor_id().
>
> While there, also:
>  - move the comment about cpumask_scratch in the header
>where the scratch space is declared;
>  - spell more clearly (in that same comment) what are the
>serialization rules.
>
> No functional change intended.
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

And...

> +/*
> + * Scratch space, for avoiding having too many cpumask_var_t on the stack.

I can fix this up on check-in.

 -George

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

Re: [Xen-devel] [PATCH 5/5] xen: sched: simplify ACPI S3 resume path.

[George Dunlap]

On Tue, Jan 17, 2017 at 5:27 PM, Dario Faggioli
 wrote:
> In fact, when domains are being unpaused:
>  - it's not necessary to put the vcpu to sleep, as
>they are all already paused;
>  - it is not necessary to call vcpu_migrate(), as
>the vcpus are still paused, and therefore won't
>wakeup anyway.
>
> Basically, the only important thing is to call
> pick_cpu, to let the scheduler run and figure out
> what would be the best initial placement (i.e., the
> value stored in v->processor), for the vcpus, as
> they come back up, one after another.
>
> Note that this is consistent with what was happening
> before this change, as vcpu_migrate() calls pick_cpu.
> But much simpler and quicker.
>
> Signed-off-by: Dario Faggioli 

Reviewed-by: George Dunlap 

> ---
> Cc: George Dunlap 
> ---
>  xen/common/schedule.c |   22 ++
>  1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index bee5d1f..43b5b99 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -635,7 +635,11 @@ void restore_vcpu_affinity(struct domain *d)
>
>  for_each_vcpu ( d, v )
>  {
> -spinlock_t *lock = vcpu_schedule_lock_irq(v);
> +spinlock_t *lock;
> +
> +ASSERT(!vcpu_runnable(v));
> +
> +lock = vcpu_schedule_lock_irq(v);
>
>  if ( v->affinity_broken )
>  {
> @@ -659,17 +663,11 @@ void restore_vcpu_affinity(struct domain *d)
>  cpupool_domain_cpumask(v->domain));
>  v->processor = cpumask_any(cpumask_scratch_cpu(cpu));
>
> -if ( v->processor == cpu )
> -{
> -set_bit(_VPF_migrating, >pause_flags);
> -spin_unlock_irq(lock);;
> -vcpu_sleep_nosync(v);
> -vcpu_migrate(v);
> -}
> -else
> -{
> -spin_unlock_irq(lock);
> -}
> +spin_unlock_irq(lock);;
> +
> +lock = vcpu_schedule_lock_irq(v);
> +v->processor = SCHED_OP(VCPU2OP(v), pick_cpu, v);
> +spin_unlock_irq(lock);
>  }
>
>  domain_update_node_affinity(d);
>
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] PVH CPU hotplug design document

[Jan Beulich]

>>> On 23.01.17 at 16:43,  wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
>>> discussed earlier.
>> I think we shouldn't overload that flag. Didn't we settle already on using
>> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
>> hot(un)plug)? With that I think I could then be talked into accepting the
>> existence of two different models (and kernels could pick which one(s)
>> they would like to support).
> 
> I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
> which is why I mentioned it now.
> 
> We can go with CPUID flags although I am not sure why we'd need two. I'd
> think that OS can be expected to always support PV-style so the flag
> would indicate support for ACPI-based hotplug.

Well, to date PV style wasn't meant to be supported, was it? In which
case it would be legitimate to put it behind a feature flag. That would
then also pave a road towards removing the support for this (and
simply no longer setting that flag).

Jan


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

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

On 01/23/2017 10:43 AM, Boris Ostrovsky wrote:
>>> From Linux perspective one option could be to have domU with PV-style
>>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>>> it becomes available. This, however, will need an indication from the
>>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
>>> discussed earlier.
>> I think we shouldn't overload that flag. Didn't we settle already on using
>> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
>> hot(un)plug)? With that I think I could then be talked into accepting the
>> existence of two different models (and kernels could pick which one(s)
>> they would like to support).
> I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
> which is why I mentioned it now.
>
> We can go with CPUID flags although I am not sure why we'd need two. I'd
> think that OS can be expected to always support PV-style so the flag
> would indicate support for ACPI-based hotplug.

In fact, it doesn't matter whether OS supports PV-style hotplug. It's
that Xen will always set appropriate xenstore entry. It's up to the OS
whether to watch it and act upon this.

-boris


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

Re: [Xen-devel] [PATCH 3/5] xen: credit2: fix shutdown/suspend when playing with cpupools.

[George Dunlap]

On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli
 wrote:
> In fact, during shutdown/suspend, we temporarily move all
> the vCPUs to the BSP (i.e., pCPU 0, as of now). For Credit2
> domains, we call csched2_vcpu_migrate(), expects to find the
> target pCPU in the domain's pool
>
> Therefore, if Credit2 is the default scheduler and we have
> removed pCPU 0 from cpupool0, shutdown/suspend fails like
> this:
>
>  RIP:e008:[] sched_credit2.c#migrate+0x274/0x2d1
>  Xen call trace:
> [] sched_credit2.c#migrate+0x274/0x2d1
> [] sched_credit2.c#csched2_vcpu_migrate+0x6e/0x86
> [] schedule.c#vcpu_move_locked+0x69/0x6f
> [] cpu_disable_scheduler+0x3d7/0x430
> [] __cpu_disable+0x299/0x2b0
> [] cpu.c#take_cpu_down+0x2f/0x38
> [] stop_machine.c#stopmachine_action+0x7f/0x8d
> [] tasklet.c#do_tasklet_work+0x74/0xab
> [] do_tasklet+0x66/0x8b
> [] domain.c#idle_loop+0x3b/0x5e
>
>  
>  Panic on CPU 8:
>  Assertion 'svc->vcpu->processor < nr_cpu_ids' failed at sched_credit2.c:1729
>  
>
> On the other hand, if Credit2 is the scheduler of another
> pool, when trying (still during shutdown/suspend) to move
> the vCPUs of the Credit2 domains to pCPU 0, it figures
> out that pCPU 0 is not a Credit2 pCPU, and fails like this:
>
>  RIP:e008:[] 
> sched_credit2.c#csched2_vcpu_migrate+0xa1/0x107
>  Xen call trace:
> [] sched_credit2.c#csched2_vcpu_migrate+0xa1/0x107
> [] schedule.c#vcpu_move_locked+0x69/0x6f
> [] cpu_disable_scheduler+0x3d7/0x430
> [] __cpu_disable+0x299/0x2b0
> [] cpu.c#take_cpu_down+0x2f/0x38
> [] stop_machine.c#stopmachine_action+0x7f/0x8d
> [] tasklet.c#do_tasklet_work+0x74/0xab
> [] do_tasklet+0x66/0x8b
> [] domain.c#idle_loop+0x3b/0x5e
>
> The solution is to recognise the specific situation, inside
> csched2_vcpu_migrate() and, considering it is something temporary,
> which only happens during shutdown/suspend, quickly deal with it.
>
> Then, in the resume path, in restore_vcpu_affinity(), things
> are set back to normal, and a new v->processor is chosen, for
> each vCPU, from the proper set of pCPUs (i.e., the ones of
> the proper cpupool).
>
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Daniel Kiper]

On Mon, Jan 23, 2017 at 09:35:55AM -0600, Doug Goldstein wrote:
> On 1/23/17 7:08 AM, Daniel Kiper wrote:
> > On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> >> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> >>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
>  Hi,
> 
>  I am sending twelfth version of multiboot2 protocol support for
>  legacy BIOS and EFI platforms. This patch series release contains
>  fixes for all known/confirmed issues.
> >>>
> >>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> >>> get the following on some of the systems I have access to:
> >>>
> >>> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> >>> (XEN) [7.012109] Stuck ??
> >>> (XEN) [7.012129] Failed to bring up CPU 1 (error -5)
> >>> (XEN) [   12.023606] Stuck ??
> >>> (XEN) [   12.023622] Failed to bring up CPU 2 (error -5)
> >>> (XEN) [   17.035099] Stuck ??
> >>> (XEN) [   17.035115] Failed to bring up CPU 3 (error -5)
> >>> (XEN) [   17.035116] Brought up 1 CPUs
> >>>
> >>> On other machines they reset when setting PAGING into cr0 (actually the
> >>> jmp following it) on line 124 of trampoline.S
> >>
> >> Thanks! I will take a look.
> >>
> >>> If I drop the series to just 2-5 against staging (since patch 1 has
> >>> already gone in) and apply the fix to efi_multiboot2() then all the
> >>> machines I presently have access to boot.
> >>
> >> Great!
> >>
> >>> Effectively the fix to efi_multiboot2() gets us back to the same level
> >>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
> >>>
> >>> Reviewed-by: Doug Goldstein 
> >>> Tested-by: Doug Goldstein 
> >>
> >> Thanks!
> >>
> >>> on the condition that the fix is applied to 5/10 prior to commit.
> >>
> >> Will do.
> >>
> >> By the way, I have asked my team colleagues to do more tests of this 
> >> series.
> >> I will come back to you if I have something in hand.
> >
> > Once you told me that you applied some patches on top of my patch series to 
> > get
> > it working. Is it still true? If you still use some extra patches could you 
> > send
> > me them? What about ExitBootServices() call? Did you disabled it? If yes on 
> > which
> > machines it have to be disabled?
> >
> > Daniel
> >
>
> I previously used the patch that I linked to you authored by Konrad. I
> have since switched to the patches that XenServer uses to no-op
> efi_get_time() and to map additional ranges of reserved memory to make
> EBS() work.

Could you send me them?

Daniel

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

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

>> From Linux perspective one option could be to have domU with PV-style
>> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
>> it becomes available. This, however, will need an indication from the
>> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
>> discussed earlier.
> I think we shouldn't overload that flag. Didn't we settle already on using
> two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
> hot(un)plug)? With that I think I could then be talked into accepting the
> existence of two different models (and kernels could pick which one(s)
> they would like to support).

I forgot about existence of ACPI_FADT_HW_REDUCED until this morning,
which is why I mentioned it now.

We can go with CPUID flags although I am not sure why we'd need two. I'd
think that OS can be expected to always support PV-style so the flag
would indicate support for ACPI-based hotplug.

-boris


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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Doug Goldstein]

On 1/23/17 7:08 AM, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
>> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
>>> On 1/19/17 8:34 PM, Daniel Kiper wrote:
 Hi,

 I am sending twelfth version of multiboot2 protocol support for
 legacy BIOS and EFI platforms. This patch series release contains
 fixes for all known/confirmed issues.
>>>
>>> With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
>>> get the following on some of the systems I have access to:
>>>
>>> (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
>>> (XEN) [7.012109] Stuck ??
>>> (XEN) [7.012129] Failed to bring up CPU 1 (error -5)
>>> (XEN) [   12.023606] Stuck ??
>>> (XEN) [   12.023622] Failed to bring up CPU 2 (error -5)
>>> (XEN) [   17.035099] Stuck ??
>>> (XEN) [   17.035115] Failed to bring up CPU 3 (error -5)
>>> (XEN) [   17.035116] Brought up 1 CPUs
>>>
>>> On other machines they reset when setting PAGING into cr0 (actually the
>>> jmp following it) on line 124 of trampoline.S
>>
>> Thanks! I will take a look.
>>
>>> If I drop the series to just 2-5 against staging (since patch 1 has
>>> already gone in) and apply the fix to efi_multiboot2() then all the
>>> machines I presently have access to boot.
>>
>> Great!
>>
>>> Effectively the fix to efi_multiboot2() gets us back to the same level
>>> of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
>>>
>>> Reviewed-by: Doug Goldstein 
>>> Tested-by: Doug Goldstein 
>>
>> Thanks!
>>
>>> on the condition that the fix is applied to 5/10 prior to commit.
>>
>> Will do.
>>
>> By the way, I have asked my team colleagues to do more tests of this series.
>> I will come back to you if I have something in hand.
> 
> Once you told me that you applied some patches on top of my patch series to 
> get
> it working. Is it still true? If you still use some extra patches could you 
> send
> me them? What about ExitBootServices() call? Did you disabled it? If yes on 
> which
> machines it have to be disabled?
> 
> Daniel
> 

I previously used the patch that I linked to you authored by Konrad. I
have since switched to the patches that XenServer uses to no-op
efi_get_time() and to map additional ranges of reserved memory to make
EBS() work.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[George Dunlap]

On Tue, Jan 17, 2017 at 5:26 PM, Dario Faggioli
 wrote:
> In fact, relying on the mask of what pCPUs belong to
> which Credit2 runqueue is not enough. If we only do that,
> when Credit2 is the boot scheduler, we may ASSERT() or
> panic when moving a pCPU from Pool-0 to another cpupool.
>
> This is because pCPUs outside of any pool are considered
> part of cpupool0. This puts us at risk of crash when those
> same pCPUs are added to another pool and something
> different than the idle domain is found to be running
> on them.
>
> Note that, even if we prevent the above to happen (which
> is the purpose of this patch), this is still pretty bad,
> in fact, when we remove a pCPU from Pool-0:
> - in Credit1, as we do *not* update prv->ncpus and
>   prv->credit, which means we're considering the wrong
>   total credits when doing accounting;
> - in Credit2, the pCPU remains part of one runqueue,
>   and is hence at least considered during load balancing,
>   even if no vCPU should really run there.
>
> In Credit1, this "only" causes skewed accounting and
> no crashes because there is a lot of `cpumask_and`ing
> going on with the cpumask of the domains' cpupool
> (which, BTW, comes at a price).
>
> A quick and not to involved (and easily backportable)
> solution for Credit2, is to do exactly the same.
>
> Signed-off-by: Dario Faggioli 

> ---
> Cc: George Dunlap 
> Cc: Juergen Gross 
> Cc: Jan Beulich 
> ---
> This is a bugfix, and should be backported to 4.8.
> ---
> The proper solution would mean calling deinit_pdata() when removing a pCPU 
> from
> cpupool0, as well as a bit more of code reshuffling.
>
> And, although worth doing, it certainly will take more work, more time, and
> will probably be hard (well, surely harder than this) to backport.
>
> Therefore, I'd argue in favor of both taking and backporting this change, 
> which
> at least enables using Credit2 as default scheduler without risking a crash
> when creating a second cpupool.
>
> Afterwards, a proper solution would be proposed for Xen 4.9.
>
> Finally, given the wide number of issues similar to this that I've found and
> fixed in the last release cycle, I think it would be good to take a stab at
> whether the interface between cpupools and the schedulers could not be
> simplified. :-O
>
> Regards,
> Dario
> ---
>  xen/common/sched_credit2.c |   59 
> 
>  1 file changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 523922e..ce0e146 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -510,19 +510,22 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t 
> *mask)
>   */
>  static int get_fallback_cpu(struct csched2_vcpu *svc)
>  {
> -int fallback_cpu, cpu = svc->vcpu->processor;
> +struct vcpu *v = svc->vcpu;
> +int cpu = v->processor;
>
> -if ( likely(cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity)) )
> -return cpu;
> +cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
> +cpupool_domain_cpumask(v->domain));
>
> -cpumask_and(cpumask_scratch_cpu(cpu), svc->vcpu->cpu_hard_affinity,
> ->rqd->active);
> -fallback_cpu = cpumask_first(cpumask_scratch_cpu(cpu));
> -if ( likely(fallback_cpu < nr_cpu_ids) )
> -return fallback_cpu;
> +if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> +return cpu;
>
> -cpumask_and(cpumask_scratch, svc->vcpu->cpu_hard_affinity,
> -cpupool_domain_cpumask(svc->vcpu->domain));
> +if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> +   >rqd->active)) )
> +{
> +cpumask_and(cpumask_scratch_cpu(cpu), >rqd->active,
> +cpumask_scratch_cpu(cpu));
> +return cpumask_first(cpumask_scratch_cpu(cpu));
> +}
>
>  ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
>
> @@ -940,6 +943,9 @@ runq_tickle(const struct scheduler *ops, struct 
> csched2_vcpu *new, s_time_t now)
>  (unsigned char *));
>  }
>
> +cpumask_and(cpumask_scratch_cpu(cpu), new->vcpu->cpu_hard_affinity,
> +cpupool_domain_cpumask(new->vcpu->domain));
> +
>  /*
>   * First of all, consider idle cpus, checking if we can just
>   * re-use the pcpu where we were running before.
> @@ -952,7 +958,7 @@ runq_tickle(const struct scheduler *ops, struct 
> csched2_vcpu *new, s_time_t now)
>  cpumask_andnot(, >idle, >smt_idle);
>  else
>  cpumask_copy(, >smt_idle);
> -cpumask_and(, , new->vcpu->cpu_hard_affinity);
> +cpumask_and(, , cpumask_scratch_cpu(cpu));
>  i = cpumask_test_or_cycle(cpu, );
>  if ( i < 

[Xen-devel] [PATCH] xen-blkfront: correct maximum segment accounting

[Jan Beulich]

Making use of "max_indirect_segments=" has issues:
- blkfront_setup_indirect() may end up with zero psegs when PAGE_SIZE
  is sufficiently much larger than XEN_PAGE_SIZE
- the variable driven by the command line option
  (xen_blkif_max_segments) has a somewhat different purpose, and hence
  should namely never end up being zero
- as long as the specified value is lower than the legacy default,
  we better don't use indirect segments at all (or we'd in fact lower
  throughput)

Signed-off-by: Jan Beulich 
---
 drivers/block/xen-blkfront.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- 4.10-rc5/drivers/block/xen-blkfront.c
+++ 4.10-rc5-xen-blkfront-seg-accounting/drivers/block/xen-blkfront.c
@@ -2223,7 +2223,7 @@ static int blkfront_setup_indirect(struc
}
else
grants = info->max_indirect_segments;
-   psegs = grants / GRANTS_PER_PSEG;
+   psegs = DIV_ROUND_UP(grants, GRANTS_PER_PSEG);
 
err = fill_grant_buffer(rinfo,
(grants + INDIRECT_GREFS(grants)) * 
BLK_RING_SIZE(info));
@@ -2328,8 +2328,11 @@ static void blkfront_gather_backend_feat
 
indirect_segments = xenbus_read_unsigned(info->xbdev->otherend,
"feature-max-indirect-segments", 0);
-   info->max_indirect_segments = min(indirect_segments,
- xen_blkif_max_segments);
+   if (indirect_segments > xen_blkif_max_segments)
+   indirect_segments = xen_blkif_max_segments;
+   if (indirect_segments <= BLKIF_MAX_SEGMENTS_PER_REQUEST)
+   indirect_segments = 0;
+   info->max_indirect_segments = indirect_segments;
 }
 
 /*
@@ -2652,6 +2655,9 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
 
+   if (xen_blkif_max_segments < BLKIF_MAX_SEGMENTS_PER_REQUEST)
+   xen_blkif_max_segments = BLKIF_MAX_SEGMENTS_PER_REQUEST;
+
if (xen_blkif_max_ring_order > XENBUS_MAX_RING_GRANT_ORDER) {
pr_info("Invalid max_ring_order (%d), will use default max: 
%d.\n",
xen_blkif_max_ring_order, XENBUS_MAX_RING_GRANT_ORDER);




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

Re: [Xen-devel] PVH CPU hotplug design document

[Jan Beulich]

>>> On 23.01.17 at 15:28,  wrote:
> On 01/23/2017 05:35 AM, Jan Beulich wrote:
> On 22.01.17 at 19:39,  wrote:
>>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>>> On 18.01.17 at 12:54,  wrote:
> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's 
> returned
> from dom0_max_vcpus, and mark them as enabled in the MADT. That's 
> basically all
> we need in order to match current PV Dom0 functionality?
 Yes, I think so.
>>>
>>> Have we then decided that we are not supporting ACPI hotplug for both 
>>> dom0 and domU?
>> I don't think anything has been decided yet, it's just that the road to
>> (consistent) ACPI hotplug support still seems somewhat cloudy, so
>> getting there (if we're convinced this is a worthwhile goal) may still
>> take some time.
> 
> 
> I am mostly interested in domU support at this point. This is the only
> feature that I can think of right now that blocks domU support in Linux.
> 
> As I said in an earlier message I don't think dom0 needs ACPI hotplug
> (or hotplug at all) while domU would benefit from it. But perhaps by
> "consistent" you meant that you prefer both to behave in the same manner.

Yes.

> From Linux perspective one option could be to have domU with PV-style
> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
> it becomes available. This, however, will need an indication from the
> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
> discussed earlier.

I think we shouldn't overload that flag. Didn't we settle already on using
two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
hot(un)plug)? With that I think I could then be talked into accepting the
existence of two different models (and kernels could pick which one(s)
they would like to support).

Jan


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

[Xen-devel] [PATCH] xen-blkfront: feature flags handling adjustments

[Jan Beulich]

Don't truncate the "feature-persistent" value read from xenstore: Any
non-zero value is supposed to enable the feature, just like is already
being done for feature_secdiscard.

Just like the other feature_* fields, feature_flush and feature_fua are
boolean flags, and hence fit well into a single bit.

Keep all bit fields together to limit gaps.

Signed-off-by: Jan Beulich 
---
 drivers/block/xen-blkfront.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

--- 4.10-rc5/drivers/block/xen-blkfront.c
+++ 4.10-rc5-xen-blkfront-feature-flags/drivers/block/xen-blkfront.c
@@ -197,13 +197,13 @@ struct blkfront_info
/* Number of pages per ring buffer. */
unsigned int nr_ring_pages;
struct request_queue *rq;
-   unsigned int feature_flush;
-   unsigned int feature_fua;
+   unsigned int feature_flush:1;
+   unsigned int feature_fua:1;
unsigned int feature_discard:1;
unsigned int feature_secdiscard:1;
+   unsigned int feature_persistent:1;
unsigned int discard_granularity;
unsigned int discard_alignment;
-   unsigned int feature_persistent:1;
/* Number of 4KB segments handled */
unsigned int max_indirect_segments;
int is_ready;
@@ -2323,8 +2323,8 @@ static void blkfront_gather_backend_feat
blkfront_setup_discard(info);
 
info->feature_persistent =
-   xenbus_read_unsigned(info->xbdev->otherend,
-"feature-persistent", 0);
+   !!xenbus_read_unsigned(info->xbdev->otherend,
+  "feature-persistent", 0);
 
indirect_segments = xenbus_read_unsigned(info->xbdev->otherend,
"feature-max-indirect-segments", 0);




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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 223a99e524679a7f811755442897bfad7cf49830
baseline version:
 ovmf 7cf59c854f35c9680965fe83e9cfd863079ddd73

Last test of basis   104603  2017-01-23 07:45:18 Z0 days
Testing same since   104607  2017-01-23 13:17:08 Z0 days1 attempts


People who touched revisions under test:
  Nikolai SAOUKH  
  Nikolai SAOUKH 
  Yonghong Zhu 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [ovmf baseline-only test] 68421: tolerable trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i3863 host-install(3)   broken baseline untested
 build-amd64   3 host-install(3)   broken baseline untested
 build-i386-pvops  3 host-install(3)   broken baseline untested
 build-i386-xsm3 host-install(3)   broken baseline untested
 build-amd64-pvops 3 host-install(3)   broken baseline untested
 build-amd64-xsm   3 host-install(3)   broken baseline untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 ovmf f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f
baseline version:
 ovmf 70420e31a04b56f99c1306e281434532a86bde70

Last test of basis68418  2017-01-22 17:46:43 Z0 days
Testing same since68421  2017-01-23 07:19:58 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 
  Jiaxin Wu 
  Thomas Huth 
  Wu Jiaxin 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

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

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

broken-step build-i386 host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386-pvops host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)
broken-step build-amd64-xsm host-install(3)

Push not applicable.


commit f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f
Author: Thomas Huth 
Date:   Thu Jan 19 17:37:31 2017 +0800

NetworkPkg: Remove superfluous return statement.

If the code eventually returns "Status" anyway, it does not make
sense to explicitely return "Status" in case of an error, too.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth 
Reviewed-by: Wu Jiaxin 

commit 4b2fb7986d571827a6e4885377e531002d806681
Author: Jiaxin Wu 
Date:   Thu Jan 19 11:53:08 2017 +0800

OvmfPkg: Allow HTTP connections if HTTP Boot enabled

v2
* Move the setting above the "!ifndef $(USE_OLD_SHELL)" part.
* Un-indent the setting to column zero.
(Comments from Laszlo)

Overwrite the value of PcdAllowHttpConnections to allow HTTP
connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE).

Cc: Laszlo Ersek 
Cc: Justen Jordan L 
Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Kinney Michael D 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 
Reviewed-by: Fu Siyuan 
Reviewed-by: Gary Lin 
Tested-by: Gary Lin 

commit 7c3c53e5e8ee066904e56d9e6dd85dad4933f29e
Author: Jiaxin Wu 
Date:   Fri Jan 6 11:55:47 2017 +0800

Nt32Pkg.dsc: Add flag to control HTTP connections

v3:
* Correct the commits grammar

v2:
* Rename the flag.

This flag is to overwrite the value of PcdAllowHttpConnections,
then the platform can make a decision whether to allow HTTP
connections or not.

Cc: Ye Ting 
Cc: Fu Siyuan 

Re: [Xen-devel] [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()

[Wei Liu]

On Mon, Jan 23, 2017 at 02:39:14PM +, Andrew Cooper wrote:
> Leaves 800b-18 are reserved.  Leaf 8019 is 1G TLB information and leaf
> 0x801a is performance hints.  These leaves have previously been hidden
> from guests, but are perfectly safe to expose.
> 
> Update libxc to also expose these leaves.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Ian Jackson 
> CC: Wei Liu 
> 
> v2:
>  * New
> ---
>  tools/libxc/xc_cpuid_x86.c | 2 ++
>  xen/arch/x86/cpuid.c   | 8 +---
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
> index 918590f..73a2ded 100644
> --- a/tools/libxc/xc_cpuid_x86.c
> +++ b/tools/libxc/xc_cpuid_x86.c
> @@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
>  case 0x8005: /* AMD L1 cache/TLB info (dumped by Intel policy) */
>  case 0x8006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */
>  case 0x800a: /* AMD SVM feature bits */
> +case 0x8019: /* AMD 1G TLB */
> +case 0x801a: /* AMD perf hints */

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v2 14/14] x86/cpuid: Remove the legacy path handling extd leaves

[Andrew Cooper]

All leaves in the extd union are handled in guest_cpuid() now, so remove
legacy handling.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpuid.c| 14 +++---
 xen/include/asm-x86/cpuid.h |  4 ++--
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 78cd287..d28735a 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -741,7 +741,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801c:
+case 0x8000 ... 0x:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -823,7 +823,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801c:
+case 0x8000 ... 0x:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -901,15 +901,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
  ARRAY_SIZE(p->extd.raw) - 1) )
 return;
 
-switch ( leaf )
-{
-default:
-goto legacy;
-
-case 0x8000 ... 0x801c:
-*res = p->extd.raw[leaf & 0x];
-break;
-}
+*res = p->extd.raw[leaf & 0x];
 break;
 
 default:
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 6cc23aa..bc3fc7c 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -78,7 +78,7 @@ struct cpuid_policy
  * Global *_policy objects:
  *
  * - Guest accurate:
- *   - All of the feat and xstate unions
+ *   - All of the feat, xstate and extd unions
  *   - max_{,sub}leaf
  *   - All FEATURESET_* words
  *   - Short vendor infomation
@@ -86,7 +86,7 @@ struct cpuid_policy
  * Per-domain objects:
  *
  * - Guest accurate:
- *   - All of the feat and xstate unions
+ *   - All of the feat, xstate and extd unions
  *   - max_{,sub}leaf
  *   - All FEATURESET_* words
  *   - Short vendor infomation
-- 
2.1.4


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

[Xen-devel] [PATCH v2 13/14] x86/cpuid: Handle leaf 0x8000001c in guest_cpuid()

[Andrew Cooper]

Leaf 0x801c contains LWP information.  edx contains hardware supported
features (and is clamped against the maximum), while ecx and ebx contain
various properties of the implementation.  eax is entirely dynamic, depending
on xcr0 and MSR_LWP_CFG.

The call to guest_cpuid() in svm_update_lwp_cfg() can now be replaced by
reading the data straight out of the cpuid_policy block.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Boris Ostrovsky 
CC: Suravee Suthikulpanit 
---
 xen/arch/x86/cpuid.c   | 34 --
 xen/arch/x86/hvm/svm/svm.c |  5 +
 2 files changed, 17 insertions(+), 22 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index b9dcc71..78cd287 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -213,6 +213,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 zero_leaves(p->extd.raw, 0xb, 0x18);
 
 p->extd.raw[0x1b] = EMPTY_LEAF; /* IBS - not supported. */
+
+p->extd.raw[0x1c].a = 0; /* LWP.a entirely dynamic. */
 break;
 }
 }
@@ -513,6 +515,11 @@ void recalculate_cpuid_policy(struct domain *d)
 
 if ( !p->extd.svm )
 p->extd.raw[0xa] = EMPTY_LEAF;
+
+if ( p->extd.lwp )
+p->extd.raw[0x1c].d &= max->extd.raw[0x1c].d;
+else
+p->extd.raw[0x1c] = EMPTY_LEAF;
 }
 
 int init_domain_cpuid_policy(struct domain *d)
@@ -726,7 +733,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 
 case 0x0005: /* MONITOR/MWAIT */
 case 0x000b: /* Extended Topology Enumeration */
-case 0x801c: /* Light Weight Profiling */
 unsupported:
 *res = EMPTY_LEAF;
 break;
@@ -735,7 +741,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801b:
+case 0x8000 ... 0x801c:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -813,25 +819,11 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x801c:
-if ( !cpu_has_svm )
-{
-*res = EMPTY_LEAF;
-break;
-}
-
-if ( cpu_has_lwp && (v->arch.xcr0 & XSTATE_LWP) )
-/* Turn on available bit and other features specified in lwp_cfg. 
*/
-res->a = (res->d & v->arch.hvm_svm.guest_lwp_cfg) | 1;
-else
-res->a = 0;
-break;
-
 case 0x0:
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801b:
+case 0x8000 ... 0x801c:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -914,7 +906,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x801b:
+case 0x8000 ... 0x801c:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
@@ -1024,6 +1016,12 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 res->d |= cpufeat_mask(X86_FEATURE_MTRR);
 }
 break;
+
+case 0x801c:
+if ( (v->arch.xcr0 & XSTATE_LWP) && cpu_has_svm )
+/* Turn on available bit and other features specified in lwp_cfg. 
*/
+res->a = (res->d & v->arch.hvm_svm.guest_lwp_cfg) | 1;
+break;
 }
 
 /* Done. */
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index e8ef88d..01c7b58 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -931,13 +931,10 @@ static int svm_update_lwp_cfg(struct vcpu *v, uint64_t 
msr_content)
 
 if ( xsave_enabled(v) && cpu_has_lwp )
 {
-struct cpuid_leaf res;
-
-guest_cpuid(v, 0x801c, 0, );
 msr_low = (uint32_t)msr_content;
 
 /* generate #GP if guest tries to turn on unsupported features. */
-if ( msr_low & ~res.d)
+if ( msr_low & ~v->domain->arch.cpuid->extd.raw[0x1c].d )
 return -1;
 
 v->arch.hvm_svm.guest_lwp_cfg = msr_content;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 12/14] x86/cpufeatures: Hide Instruction Based Sampling from guests

[Andrew Cooper]

Xen advertises the IBS feature flag to guests on capable AMD hardware.
However, the PV path in Xen, and both the PV and HVM paths in libxc
deliberately clobber the IBS CPUID leaf.

Furthermore, Xen has nothing providing an implementation of the IBS MSRs, so
guests can't actually use the feature at all.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c| 9 +
 xen/include/public/arch-x86/cpufeatureset.h | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index c75ba31..b9dcc71 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -211,6 +211,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.raw[0x9] = EMPTY_LEAF;
 
 zero_leaves(p->extd.raw, 0xb, 0x18);
+
+p->extd.raw[0x1b] = EMPTY_LEAF; /* IBS - not supported. */
 break;
 }
 }
@@ -724,7 +726,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 
 case 0x0005: /* MONITOR/MWAIT */
 case 0x000b: /* Extended Topology Enumeration */
-case 0x801b: /* Instruction Based Sampling */
 case 0x801c: /* Light Weight Profiling */
 unsupported:
 *res = EMPTY_LEAF;
@@ -734,7 +735,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801a:
+case 0x8000 ... 0x801b:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -830,7 +831,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x801a:
+case 0x8000 ... 0x801b:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -913,7 +914,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x801a:
+case 0x8000 ... 0x801b:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 70f1e30..97dd353 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -172,7 +172,7 @@ XEN_CPUFEATURE(SSE4A, 3*32+ 6) /*A  SSE-4A */
 XEN_CPUFEATURE(MISALIGNSSE,   3*32+ 7) /*A  Misaligned SSE mode */
 XEN_CPUFEATURE(3DNOWPREFETCH, 3*32+ 8) /*A  3DNow prefetch instructions */
 XEN_CPUFEATURE(OSVW,  3*32+ 9) /*   OS Visible Workaround */
-XEN_CPUFEATURE(IBS,   3*32+10) /*S  Instruction Based Sampling */
+XEN_CPUFEATURE(IBS,   3*32+10) /*   Instruction Based Sampling */
 XEN_CPUFEATURE(XOP,   3*32+11) /*A  extended AVX instructions */
 XEN_CPUFEATURE(SKINIT,3*32+12) /*   SKINIT/STGI instructions */
 XEN_CPUFEATURE(WDT,   3*32+13) /*   Watchdog timer */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 11/14] x86/cpuid: Handle leaves 0x8000000b-1a in guest_cpuid()

[Andrew Cooper]

Leaves 800b-18 are reserved.  Leaf 8019 is 1G TLB information and leaf
0x801a is performance hints.  These leaves have previously been hidden
from guests, but are perfectly safe to expose.

Update libxc to also expose these leaves.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 

v2:
 * New
---
 tools/libxc/xc_cpuid_x86.c | 2 ++
 xen/arch/x86/cpuid.c   | 8 +---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 918590f..73a2ded 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -479,6 +479,8 @@ static void xc_cpuid_hvm_policy(xc_interface *xch,
 case 0x8005: /* AMD L1 cache/TLB info (dumped by Intel policy) */
 case 0x8006: /* AMD L2/3 cache/TLB info ; Intel L2 cache features */
 case 0x800a: /* AMD SVM feature bits */
+case 0x8019: /* AMD 1G TLB */
+case 0x801a: /* AMD perf hints */
 case 0x801c: /* AMD lightweight profiling */
 break;
 
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 17738c8..c75ba31 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -209,6 +209,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.raw[0x8].c &= 0x0003f0ff;
 
 p->extd.raw[0x9] = EMPTY_LEAF;
+
+zero_leaves(p->extd.raw, 0xb, 0x18);
 break;
 }
 }
@@ -732,7 +734,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x800a:
+case 0x8000 ... 0x801a:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -828,7 +830,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x800a:
+case 0x8000 ... 0x801a:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -911,7 +913,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x800a:
+case 0x8000 ... 0x801a:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
-- 
2.1.4


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

[Xen-devel] [PATCH v2 10/14] x86/cpuid: Handle leaf 0x8000000a in guest_cpuid()

[Andrew Cooper]

Leaf 0x800a contains SVM information.  The feature choices are borrowed
straight from the libxc policy code.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c | 26 ++
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index a8dce40..17738c8 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -282,6 +283,19 @@ static void __init calculate_host_policy(void)
 cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
 recalculate_xstate(p);
 recalculate_misc(p);
+
+if ( p->extd.svm )
+{
+/* Clamp to implemented features which require hardware support. */
+p->extd.raw[0xa].d &= ((1u << SVM_FEATURE_NPT) |
+   (1u << SVM_FEATURE_LBRV) |
+   (1u << SVM_FEATURE_NRIPS) |
+   (1u << SVM_FEATURE_PAUSEFILTER) |
+   (1u << SVM_FEATURE_DECODEASSISTS));
+/* Enable features which are always emulated. */
+p->extd.raw[0xa].d |= ((1u << SVM_FEATURE_VMCBCLEAN) |
+   (1u << SVM_FEATURE_TSCRATEMSR));
+}
 }
 
 static void __init calculate_pv_max_policy(void)
@@ -302,6 +316,8 @@ static void __init calculate_pv_max_policy(void)
 sanitise_featureset(pv_featureset);
 cpuid_featureset_to_policy(pv_featureset, p);
 recalculate_xstate(p);
+
+p->extd.raw[0xa] = EMPTY_LEAF; /* No SVM for PV guests. */
 }
 
 static void __init calculate_hvm_max_policy(void)
@@ -490,6 +506,9 @@ void recalculate_cpuid_policy(struct domain *d)
 
 recalculate_xstate(p);
 recalculate_misc(p);
+
+if ( !p->extd.svm )
+p->extd.raw[0xa] = EMPTY_LEAF;
 }
 
 int init_domain_cpuid_policy(struct domain *d)
@@ -703,7 +722,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 
 case 0x0005: /* MONITOR/MWAIT */
 case 0x000b: /* Extended Topology Enumeration */
-case 0x800a: /* SVM revision and features */
 case 0x801b: /* Instruction Based Sampling */
 case 0x801c: /* Light Weight Profiling */
 unsupported:
@@ -714,7 +732,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8009:
+case 0x8000 ... 0x800a:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -810,7 +828,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8009:
+case 0x8000 ... 0x800a:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -893,7 +911,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x8009:
+case 0x8000 ... 0x800a:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Roger Pau Monne]

On Mon, Jan 23, 2017 at 09:11:06AM -0500, Boris Ostrovsky wrote:
> 
> >  
> > +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> > +   unsigned long nr_pages, bool map)
> > +{
> > +int rc;
> > +
> > +for ( ; ; )
> > +{
> > +rc = (map ? map_mmio_regions : unmap_mmio_regions)
> 
> This can be taken outside the loop.

Maybe I can instead make map const, and the compiler should optimize this
itself?

I find it a little cumbersome to store function pointers, ie:

int (*mapf)(struct domain *, gfn_t, unsigned long, mfn_t) = ...;

Roger.

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

[Xen-devel] [linux-next test] 104604: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10 fail baseline untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2 fail baseline untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2 fail baseline untested
 test-amd64-amd64-xl-credit2  17 guest-localmigrate/x10  fail baseline untested
 test-amd64-amd64-xl  17 guest-localmigrate/x10  fail baseline untested
 test-amd64-amd64-pair 22 guest-migrate/dst_host/src_host fail baseline untested
 test-amd64-i386-xl   17 guest-localmigrate/x10  fail baseline untested
 test-amd64-i386-xl-xsm   15 guest-localmigrate  fail baseline untested
 test-amd64-i386-pair 22 guest-migrate/dst_host/src_host fail baseline untested
 test-amd64-amd64-xl-rtds 15 guest-localmigrate  fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail baseline untested
 build-armhf-pvops 5 kernel-buildfail baseline untested
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 linuxf9dd6f6cc63cda037c932c5bfcc159343ae33120

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsfail
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-amd64-amd64-xl  fail
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 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-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  fail
 

Re: [Xen-devel] [PATCH] x86/hvm: Conditionally leave CPUID Faulting active in HVM context

[Andrew Cooper]

On 16/01/17 11:17, Andrew Cooper wrote:
> If the hardware supports faulting, and the guest has chosen to use it, leave
> faulting active in HVM context.
>
> It is more efficient to have hardware convert CPUID to a #GP fault (which we
> don't intercept), than to take a VMExit and have Xen re-inject a #GP fault.
>
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Jun Nakajima 
> CC: Kevin Tian 

Ping VT-x ?

> ---
>  xen/arch/x86/cpu/intel.c   |  5 +++--
>  xen/arch/x86/hvm/vmx/vmx.c | 12 ++--
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
> index 2e11662..d0e380c 100644
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -175,8 +175,9 @@ static void intel_ctxt_switch_levelling(const struct vcpu 
> *next)
>* generating the maximum full cpuid policy into Xen, at which
>* this problem will disappear.
>*/
> - set_cpuid_faulting(nextd && is_pv_domain(nextd) &&
> -!is_control_domain(nextd));
> + set_cpuid_faulting(nextd && !is_control_domain(nextd) &&
> +(is_pv_domain(nextd) ||
> + next->arch.cpuid_faulting));
>   return;
>   }
>  
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 61925cf..19294cb 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2866,11 +2866,19 @@ static int vmx_msr_write_intercept(unsigned int msr, 
> uint64_t msr_content)
>  break;
>  
>  case MSR_INTEL_MISC_FEATURES_ENABLES:
> +{
> +bool old_cpuid_faulting = v->arch.cpuid_faulting;
> +
>  if ( msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )
>  goto gp_fault;
> -v->arch.cpuid_faulting =
> -!!(msr_content & MSR_MISC_FEATURES_CPUID_FAULTING);
> +
> +v->arch.cpuid_faulting = msr_content & 
> MSR_MISC_FEATURES_CPUID_FAULTING;
> +
> +if ( cpu_has_cpuid_faulting &&
> + (old_cpuid_faulting ^ v->arch.cpuid_faulting) )
> +ctxt_switch_levelling(v);
>  break;
> +}
>  
>  default:
>  if ( passive_domain_do_wrmsr(msr, msr_content) )


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

Re: [Xen-devel] [PATCH 2/5] xen: credit2: never consider CPUs outside of our cpupool.

[George Dunlap]

On Thu, Jan 19, 2017 at 8:08 AM, Juergen Gross  wrote:
> On 17/01/17 18:26, Dario Faggioli wrote:
>> In fact, relying on the mask of what pCPUs belong to
>> which Credit2 runqueue is not enough. If we only do that,
>> when Credit2 is the boot scheduler, we may ASSERT() or
>> panic when moving a pCPU from Pool-0 to another cpupool.
>>
>> This is because pCPUs outside of any pool are considered
>> part of cpupool0. This puts us at risk of crash when those
>> same pCPUs are added to another pool and something
>> different than the idle domain is found to be running
>> on them.
>>
>> Note that, even if we prevent the above to happen (which
>> is the purpose of this patch), this is still pretty bad,
>> in fact, when we remove a pCPU from Pool-0:
>> - in Credit1, as we do *not* update prv->ncpus and
>>   prv->credit, which means we're considering the wrong
>>   total credits when doing accounting;
>> - in Credit2, the pCPU remains part of one runqueue,
>>   and is hence at least considered during load balancing,
>>   even if no vCPU should really run there.
>>
>> In Credit1, this "only" causes skewed accounting and
>> no crashes because there is a lot of `cpumask_and`ing
>> going on with the cpumask of the domains' cpupool
>> (which, BTW, comes at a price).
>>
>> A quick and not to involved (and easily backportable)
>> solution for Credit2, is to do exactly the same.
>>
>> Signed-off-by: Dario Faggioli > ---
>> Cc: George Dunlap 
>> Cc: Juergen Gross 
>> Cc: Jan Beulich 
>> ---
>> This is a bugfix, and should be backported to 4.8.
>> ---
>> The proper solution would mean calling deinit_pdata() when removing a pCPU 
>> from
>> cpupool0, as well as a bit more of code reshuffling.
>>
>> And, although worth doing, it certainly will take more work, more time, and
>> will probably be hard (well, surely harder than this) to backport.
>>
>> Therefore, I'd argue in favor of both taking and backporting this change, 
>> which
>> at least enables using Credit2 as default scheduler without risking a crash
>> when creating a second cpupool.
>>
>> Afterwards, a proper solution would be proposed for Xen 4.9.
>>
>> Finally, given the wide number of issues similar to this that I've found and
>> fixed in the last release cycle, I think it would be good to take a stab at
>> whether the interface between cpupools and the schedulers could not be
>> simplified. :-O
>
> The first patch version for support of cpupools I sent used an own
> scheduler instance for the free cpus. Keir merged this instance with
> the one for Pool-0.

You mean he just made the change unilaterally without posting it to
the list?  I just went back and skimmed through the old cpupools
threads and didn't see this discussed.

Having a "cpupool-remove" operation that doesn't actually remove the
cpu from the pool is a bit mad...

 -George

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

[Xen-devel] [PATCH v2 04/14] x86/cpuid: Handle more simple Intel leaves in guest_cpuid()

[Andrew Cooper]

Intel now document leaf 2 as a plain leaf, with %al always containing the
value 0x01.  Collect this leaf normally in calculate_raw_policy() and expose
it to guests.  The leaf is reserved by AMD.

Intel leaves 3 and 9 (PSN and DCA respectively) are not exposed to guests at
all.  They are reserved by AMD.

Leaves 8 and 0xc are reserved by both vendors.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c| 32 ++--
 xen/include/asm-x86/cpuid.h |  3 +++
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 87ec02f..7af5900 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -17,6 +17,11 @@ static const uint32_t hvm_hap_featuremask[] = 
INIT_HVM_HAP_FEATURES;
 static const uint32_t deep_features[] = INIT_DEEP_FEATURES;
 
 #define EMPTY_LEAF ((struct cpuid_leaf){})
+static void zero_leaves(struct cpuid_leaf *l,
+unsigned int first, unsigned int last)
+{
+memset([first], 0, sizeof(*l) * (last - first + 1));
+}
 
 struct cpuid_policy __read_mostly raw_policy,
 __read_mostly host_policy,
@@ -153,21 +158,31 @@ static void recalculate_xstate(struct cpuid_policy *p)
 
 /*
  * Misc adjustments to the policy.  Mostly clobbering reserved fields and
- * duplicating shared fields.
+ * duplicating shared fields.  Intentionally hidden fields are annotated.
  */
 static void recalculate_misc(struct cpuid_policy *p)
 {
+p->basic.raw[0x8] = EMPTY_LEAF;
+p->basic.raw[0xc] = EMPTY_LEAF;
+
 p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
 
 switch ( p->x86_vendor )
 {
 case X86_VENDOR_INTEL:
+p->basic.l2_nr_queries = 1; /* Fixed to 1 query. */
+p->basic.raw[0x3] = EMPTY_LEAF; /* PSN - always hidden. */
+p->basic.raw[0x9] = EMPTY_LEAF; /* DCA - always hidden. */
+
 p->extd.vendor_ebx = 0;
 p->extd.vendor_ecx = 0;
 p->extd.vendor_edx = 0;
 break;
 
 case X86_VENDOR_AMD:
+zero_leaves(p->basic.raw, 0x2, 0x3);
+p->basic.raw[0x9] = EMPTY_LEAF;
+
 p->extd.vendor_ebx = p->basic.vendor_ebx;
 p->extd.vendor_ecx = p->basic.vendor_ecx;
 p->extd.vendor_edx = p->basic.vendor_edx;
@@ -188,7 +203,7 @@ static void __init calculate_raw_policy(void)
 {
 switch ( i )
 {
-case 0x2: case 0x4: case 0x7: case 0xd:
+case 0x4: case 0x7: case 0xd:
 /* Multi-invocation leaves.  Deferred. */
 continue;
 }
@@ -694,8 +709,9 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 break;
 
 case 0x0:
-case 0x7:
-case XSTATE_CPUID:
+case 0x2 ... 0x3:
+case 0x7 ... 0x9:
+case 0xc ... XSTATE_CPUID:
 case 0x8000:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
@@ -841,8 +857,9 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 break;
 
 case 0x0:
-case 0x7:
-case XSTATE_CPUID:
+case 0x2 ... 0x3:
+case 0x7 ... 0x9:
+case 0xc ... XSTATE_CPUID:
 case 0x8000:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
@@ -894,6 +911,9 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 goto legacy;
 
 case 0x0:
+case 0x2 ... 0x3:
+case 0x8 ... 0x9:
+case 0xc:
 *res = p->basic.raw[leaf];
 break;
 }
diff --git a/xen/include/asm-x86/cpuid.h b/xen/include/asm-x86/cpuid.h
index 4712b73..a15270a 100644
--- a/xen/include/asm-x86/cpuid.h
+++ b/xen/include/asm-x86/cpuid.h
@@ -115,6 +115,9 @@ struct cpuid_policy
 uint32_t _1d;
 struct { DECL_BITFIELD(1d); };
 };
+
+/* Leaf 0x2 - TLB/Cache/Prefetch. */
+uint8_t l2_nr_queries; /* Documented as fixed to 1. */
 };
 } basic;
 
-- 
2.1.4


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

[Xen-devel] [PATCH v2 02/14] x86/cpuid: Handle leaf 0x80000000 in guest_cpuid()

[Andrew Cooper]

The calculations for p->extd.max_leaf are reworked to force a value of at
least 0x8000, and to take the domains chosen vendor into account when
clamping maximum value.

The high short vendor information is clobbered or duplicated according to the
chosen vendor.

As a side effect of handing out an audited max_leaf value, the 0x801e case
can be dropped from pv_cpuid(), as it outside of the visible range.

Signed-off-by: Andrew Cooper 
Reviewed-by: Doug Goldstein 
Reviewed-by: Jan Beulich 
---
v2:
 * Drop 0x801e from pv_cpuid()
 * s/recalculate_common/recalculate_misc/
---
 xen/arch/x86/cpuid.c| 53 +++--
 xen/include/asm-x86/cpuid.h |  6 ++---
 2 files changed, 49 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 85c829d..3f398b5 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -163,6 +163,28 @@ static void recalculate_xstate(struct cpuid_policy *p)
 }
 }
 
+/*
+ * Misc adjustments to the policy.  Mostly clobbering reserved fields and
+ * duplicating shared fields.
+ */
+static void recalculate_misc(struct cpuid_policy *p)
+{
+switch ( p->x86_vendor )
+{
+case X86_VENDOR_INTEL:
+p->extd.vendor_ebx = 0;
+p->extd.vendor_ecx = 0;
+p->extd.vendor_edx = 0;
+break;
+
+case X86_VENDOR_AMD:
+p->extd.vendor_ebx = p->basic.vendor_ebx;
+p->extd.vendor_ecx = p->basic.vendor_ecx;
+p->extd.vendor_edx = p->basic.vendor_edx;
+break;
+}
+}
+
 static void __init calculate_raw_policy(void)
 {
 struct cpuid_policy *p = _policy;
@@ -227,12 +249,12 @@ static void __init calculate_host_policy(void)
 min_t(uint32_t, p->basic.max_leaf,   ARRAY_SIZE(p->basic.raw) - 1);
 p->feat.max_subleaf =
 min_t(uint32_t, p->feat.max_subleaf, ARRAY_SIZE(p->feat.raw) - 1);
-p->extd.max_leaf =
-min_t(uint32_t, p->extd.max_leaf,
-  0x8000u + ARRAY_SIZE(p->extd.raw) - 1);
+p->extd.max_leaf = 0x8000 | min_t(uint32_t, p->extd.max_leaf & 0x,
+  ARRAY_SIZE(p->extd.raw) - 1);
 
 cpuid_featureset_to_policy(boot_cpu_data.x86_capability, p);
 recalculate_xstate(p);
+recalculate_misc(p);
 }
 
 static void __init calculate_pv_max_policy(void)
@@ -360,7 +382,10 @@ void recalculate_cpuid_policy(struct domain *d)
 
 p->basic.max_leaf   = min(p->basic.max_leaf,   max->basic.max_leaf);
 p->feat.max_subleaf = min(p->feat.max_subleaf, max->feat.max_subleaf);
-p->extd.max_leaf= min(p->extd.max_leaf,max->extd.max_leaf);
+p->extd.max_leaf= 0x8000 | min(p->extd.max_leaf & 0x,
+   (p->x86_vendor == X86_VENDOR_AMD
+? CPUID_GUEST_NR_EXTD_AMD
+: CPUID_GUEST_NR_EXTD_INTEL) - 1);
 
 cpuid_policy_to_featureset(p, fs);
 cpuid_policy_to_featureset(max, max_fs);
@@ -428,6 +453,7 @@ void recalculate_cpuid_policy(struct domain *d)
 
 cpuid_featureset_to_policy(fs, p);
 recalculate_xstate(p);
+recalculate_misc(p);
 }
 
 int init_domain_cpuid_policy(struct domain *d)
@@ -675,7 +701,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x800a: /* SVM revision and features */
 case 0x801b: /* Instruction Based Sampling */
 case 0x801c: /* Light Weight Profiling */
-case 0x801e: /* Extended topology reporting */
 unsupported:
 *res = EMPTY_LEAF;
 break;
@@ -683,6 +708,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x0:
 case 0x7:
 case XSTATE_CPUID:
+case 0x8000:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -832,6 +858,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x0:
 case 0x7:
 case XSTATE_CPUID:
+case 0x8000:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -901,9 +928,21 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 return cpuid_hypervisor_leaves(v, leaf, subleaf, res);
 
 case 0x8000 ... 0x8000 + CPUID_GUEST_NR_EXTD - 1:
-if ( leaf > p->extd.max_leaf )
+ASSERT((p->extd.max_leaf & 0x) < ARRAY_SIZE(p->extd.raw));
+if ( (leaf & 0x) > min_t(uint32_t, p->extd.max_leaf & 0x,
+ ARRAY_SIZE(p->extd.raw) - 1) )
 return;
-goto legacy;
+
+switch ( leaf )
+{
+default:
+goto legacy;
+
+case 0x8000:
+*res = p->extd.raw[leaf & 0x];
+break;
+}
+break;
 
 default:
 return;
diff --git a/xen/include/asm-x86/cpuid.h 

[Xen-devel] [PATCH v2 01/14] x86/cpufeatures: Expose self-snoop to all guests

[Andrew Cooper]

Self-snoop describes a property of the CPU cache behaviour, which FreeBSD uses
to optimise its cache flushing algorithm.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Roger Pau Monné 

v2:
 * New
---
 xen/include/public/arch-x86/cpufeatureset.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 306200b..70f1e30 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -114,6 +114,7 @@ XEN_CPUFEATURE(MMX,   0*32+23) /*A  Multimedia 
Extensions */
 XEN_CPUFEATURE(FXSR,  0*32+24) /*A  FXSAVE and FXRSTOR instructions */
 XEN_CPUFEATURE(SSE,   0*32+25) /*A  Streaming SIMD Extensions */
 XEN_CPUFEATURE(SSE2,  0*32+26) /*A  Streaming SIMD Extensions-2 */
+XEN_CPUFEATURE(SS,0*32+27) /*A  CPU self snoop */
 XEN_CPUFEATURE(HTT,   0*32+28) /*!A Hyper-Threading Technology */
 XEN_CPUFEATURE(TM1,   0*32+29) /*   Thermal Monitor 1 */
 XEN_CPUFEATURE(PBE,   0*32+31) /*   Pending Break Enable */
-- 
2.1.4


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

[Xen-devel] [PATCH v2 06/14] x86/cpuid: Handle the long vendor string in guest_cpuid()

[Andrew Cooper]

Leaves 0x8002 through 0x8004 are plain ASCII text, and are left
exactly as the toolstack chooses.

Signed-off-by: Andrew Cooper 
Reviewed-by: Doug Goldstein 
Reviewed-by: Jan Beulich 
---
v2:
 * Rebased, but no significant changes
---
 xen/arch/x86/cpuid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index c06b5a6..9cea13c 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -698,7 +698,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8001:
+case 0x8000 ... 0x8004:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -815,7 +815,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8001:
+case 0x8000 ... 0x8004:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -898,7 +898,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x8001:
+case 0x8000 ... 0x8004:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
-- 
2.1.4


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

[Xen-devel] [PATCH v2 00/14] x86/cpuid: Handling of simple leaves in guest_cpuid()

[Andrew Cooper]

The series has been extended substantially, and now handles the entire extd
union in the guest_cpuid() path.

Andrew Cooper (14):
  x86/cpufeatures: Expose self-snoop to all guests
  x86/cpuid: Handle leaf 0x8000 in guest_cpuid()
  x86/cpuid: Only recalculate the shared feature bits once
  x86/cpuid: Handle more simple Intel leaves in guest_cpuid()
  x86/cpuid: Handle leaf 0x8001 in guest_cpuid()
  x86/cpuid: Handle the long vendor string in guest_cpuid()
  x86/cpuid: Handle leaves 0x8005-7 in guest_cpuid()
  x86/cpuid: Handle leaf 0x8008 in guest_cpuid()
  x86/cpuid: Handle leaf 0x8009 in guest_cpuid()
  x86/cpuid: Handle leaf 0x800a in guest_cpuid()
  x86/cpuid: Handle leaves 0x800b-1a in guest_cpuid()
  x86/cpufeatures: Hide Instruction Based Sampling from guests
  x86/cpuid: Handle leaf 0x801c in guest_cpuid()
  x86/cpuid: Remove the legacy path handling extd leaves

 tools/libxc/xc_cpuid_x86.c  |  21 +-
 xen/arch/x86/cpuid.c| 307 
 xen/arch/x86/hvm/mtrr.c |   7 +-
 xen/arch/x86/hvm/svm/svm.c  |   5 +-
 xen/include/asm-x86/cpuid.h |  17 +-
 xen/include/public/arch-x86/cpufeatureset.h |   3 +-
 xen/tools/gen-cpuid.py  |  29 +--
 7 files changed, 205 insertions(+), 184 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH v2 07/14] x86/cpuid: Handle leaves 0x80000005-7 in guest_cpuid()

[Andrew Cooper]

Leaf 0x8005 contains L1 cache/TLB information, 0x8006 L2 & L3
cache/TLB information, and 0x8007 Power management information.

Intel reserves all of this information other than the L2 cache information,
and the ITSC bit from the power management leaf.

AMD passes all of the cache/TLB information through to the guest, while most
of of the power management information is explicitly clobbered by the
toolstack.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 9cea13c..3338045 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -167,6 +167,9 @@ static void recalculate_misc(struct cpuid_policy *p)
 
 p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
 
+/* Most of Power/RAS hidden from guests. */
+p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
+
 switch ( p->x86_vendor )
 {
 case X86_VENDOR_INTEL:
@@ -179,6 +182,9 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.vendor_edx = 0;
 
 p->extd.raw[0x1].a = p->extd.raw[0x1].b = 0;
+
+p->extd.raw[0x5] = EMPTY_LEAF;
+p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
 break;
 
 case X86_VENDOR_AMD:
@@ -676,10 +682,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x8007:
-res->d = p->extd.e7d;
-break;
-
 case 0x8008:
 res->a = paddr_bits | (vaddr_bits << 8);
 res->b = p->extd.e8b;
@@ -698,7 +700,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8004:
+case 0x8000 ... 0x8007:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -778,10 +780,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x8007:
-res->d = p->extd.e7d;
-break;
-
 case 0x8008:
 res->a &= 0xff;
 tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
@@ -815,7 +813,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8004:
+case 0x8000 ... 0x8007:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -898,7 +896,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x8004:
+case 0x8000 ... 0x8007:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
-- 
2.1.4


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

[Xen-devel] [PATCH v2 08/14] x86/cpuid: Handle leaf 0x80000008 in guest_cpuid()

[Andrew Cooper]

The entirety of edx is reserved.

Intel only defines the lower 16 bits of eax, although ebx is covered by the
featureset ABI, so left unclobbered.

AMD uses 24 bits in eax, although nothing thus far has ever exposed a non-zero
guest maxphysaddr to HVM guests.  ecx contains some reserved bits, and several
pieces of static topology information, which are left as the toolstack
chooses.

A side effect of the common recalculation of maxlinaddr is that 32bit PV
guests see a maximum linear address of 32, which is consistent with the hiding
of other long mode information from them.

Finally, the call to guest_cpuid() in mtrr_var_range_msr_set() (introduced in
c/s fff8160a) can be dropped, now that maxphysaddr can be read straight out of
the cpuid_policy block.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c| 45 -
 xen/arch/x86/hvm/mtrr.c |  7 +--
 xen/include/asm-x86/cpuid.h |  2 +-
 3 files changed, 22 insertions(+), 32 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3338045..4d48552 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -170,6 +170,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 /* Most of Power/RAS hidden from guests. */
 p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
 
+p->extd.raw[0x8].d = 0;
+
 switch ( p->x86_vendor )
 {
 case X86_VENDOR_INTEL:
@@ -185,6 +187,9 @@ static void recalculate_misc(struct cpuid_policy *p)
 
 p->extd.raw[0x5] = EMPTY_LEAF;
 p->extd.raw[0x6].a = p->extd.raw[0x6].b = p->extd.raw[0x6].d = 0;
+
+p->extd.raw[0x8].a &= 0x;
+p->extd.raw[0x8].c = 0;
 break;
 
 case X86_VENDOR_AMD:
@@ -198,6 +203,9 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.raw_fms = p->basic.raw_fms;
 p->extd.raw[0x1].b &= 0xff00;
 p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
+
+p->extd.raw[0x8].a &= 0x00ff;
+p->extd.raw[0x8].c &= 0x0003f0ff;
 break;
 }
 }
@@ -469,6 +477,15 @@ void recalculate_cpuid_policy(struct domain *d)
special_features[FEATURESET_7b0]);
 
 cpuid_featureset_to_policy(fs, p);
+
+p->extd.maxphysaddr = min(p->extd.maxphysaddr, max->extd.maxphysaddr);
+p->extd.maxphysaddr = min_t(uint8_t, p->extd.maxphysaddr,
+d->arch.paging.gfn_bits + PAGE_SHIFT);
+p->extd.maxphysaddr = max_t(uint8_t, p->extd.maxphysaddr,
+(p->basic.pae || p->basic.pse36) ? 36 : 32);
+
+p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
+
 recalculate_xstate(p);
 recalculate_misc(p);
 }
@@ -682,11 +699,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x8008:
-res->a = paddr_bits | (vaddr_bits << 8);
-res->b = p->extd.e8b;
-break;
-
 case 0x0005: /* MONITOR/MWAIT */
 case 0x000b: /* Extended Topology Enumeration */
 case 0x800a: /* SVM revision and features */
@@ -700,7 +712,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8007:
+case 0x8000 ... 0x8008:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -716,8 +728,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 
 switch ( leaf )
 {
-unsigned int tmp;
-
 case 0x1:
 /* Fix up VLAPIC details. */
 res->b &= 0x00FFu;
@@ -780,21 +790,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x8008:
-res->a &= 0xff;
-tmp = d->arch.paging.gfn_bits + PAGE_SHIFT;
-if ( res->a > tmp )
-res->a = tmp;
-
-tmp = (p->basic.pae || p->basic.pse36) ? 36 : 32;
-if ( res->a < tmp )
-res->a = tmp;
-
-res->a |= (p->extd.lm ? vaddr_bits : 32) << 8;
-
-res->b = p->extd.e8b;
-break;
-
 case 0x801c:
 if ( !cpu_has_svm )
 {
@@ -813,7 +808,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8007:
+case 0x8000 ... 0x8008:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -896,7 +891,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x8007:
+case 0x8000 ... 0x8008:
 *res = 

[Xen-devel] [PATCH v2 05/14] x86/cpuid: Handle leaf 0x80000001 in guest_cpuid()

[Andrew Cooper]

Intel reserve eax and ebx, while AMD duplicates eax from the low
family/model/stepping leaf.  For AMD, ebx contains further brand/package
information which is left as the toolstack chooses (other than bits 27:16
which are reserved).

While moving the dynamic adjustments from the legacy path, simplify the shadow
PSE36 adjustment.  PAE paging is a prerequisite for enabling long mode, making
the long mode check redundant; the case where it doesn't get short circuited
is the case where it is architecturally 0.  Make the same adjustment to the
leaf 1 legacy path.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c| 107 ++--
 xen/include/asm-x86/cpuid.h |   2 +-
 2 files changed, 55 insertions(+), 54 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 7af5900..c06b5a6 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -177,6 +177,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.vendor_ebx = 0;
 p->extd.vendor_ecx = 0;
 p->extd.vendor_edx = 0;
+
+p->extd.raw[0x1].a = p->extd.raw[0x1].b = 0;
 break;
 
 case X86_VENDOR_AMD:
@@ -187,6 +189,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.vendor_ecx = p->basic.vendor_ecx;
 p->extd.vendor_edx = p->basic.vendor_edx;
 
+p->extd.raw_fms = p->basic.raw_fms;
+p->extd.raw[0x1].b &= 0xff00;
 p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
 break;
 }
@@ -672,24 +676,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x8001:
-res->c = p->extd.e1c;
-res->d = p->extd.e1d;
-
-/*
- * MTRR used to unconditionally leak into PV guests.  They cannot MTRR
- * infrastructure at all, and shouldn't be able to see the feature.
- *
- * Modern PVOPS Linux self-clobbers the MTRR feature, to avoid trying
- * to use the associated MSRs.  Xenolinux-based PV dom0's however use
- * the MTRR feature as an indication of the presence of the
- * XENPF_{add,del,read}_memtype hypercalls.
- */
-if ( is_hardware_domain(currd) && cpu_has_mtrr &&
- guest_kernel_mode(curr, guest_cpu_user_regs()) )
-res->d |= cpufeat_mask(X86_FEATURE_MTRR);
-break;
-
 case 0x8007:
 res->d = p->extd.e7d;
 break;
@@ -712,7 +698,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000:
+case 0x8000 ... 0x8001:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -760,7 +746,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
  * a 32bit guest doesn't get the impression that it could try to use
  * PSE36 paging.
  */
-if ( !hap_enabled(d) && !(hvm_pae_enabled(v) || 
hvm_long_mode_enabled(v)) )
+if ( !hap_enabled(d) && !hvm_pae_enabled(v) )
 res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
 
 if ( vpmu_enabled(v) &&
@@ -792,37 +778,6 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->a = (res->a & ~0xff) | 3;
 break;
 
-case 0x8001:
-res->c = p->extd.e1c;
-res->d = p->extd.e1d;
-
-/* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered. 
*/
-if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
-res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
-
-/*
- * PSE36 is not supported in shadow mode.  This bit should be
- * unilaterally cleared.
- *
- * However, an unspecified version of Hyper-V from 2011 refuses
- * to start as the "cpu does not provide required hw features" if
- * it can't see PSE36.
- *
- * As a workaround, leak the toolstack-provided PSE36 value into a
- * shadow guest if the guest is already using PAE paging (and won't
- * care about reverting back to PSE paging).  Otherwise, knoble it, so
- * a 32bit guest doesn't get the impression that it could try to use
- * PSE36 paging.
- */
-if ( !hap_enabled(d) && !(hvm_pae_enabled(v) || 
hvm_long_mode_enabled(v)) )
-res->d &= ~cpufeat_mask(X86_FEATURE_PSE36);
-
-/* SYSCALL is hidden outside of long mode on Intel. */
-if ( p->x86_vendor == X86_VENDOR_INTEL && !hvm_long_mode_enabled(v) )
-res->d &= ~cpufeat_mask(X86_FEATURE_SYSCALL);
-
-break;
-
 case 0x8007:
 res->d = p->extd.e7d;
 break;
@@ -860,7 +815,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 

[Xen-devel] [PATCH v2 03/14] x86/cpuid: Only recalculate the shared feature bits once

[Andrew Cooper]

With accurate vendor information available, the shared bits can be sorted out
during recalculation, rather than at query time in the legacy cpuid path.

This means that:
 * Duplication can be dropped from the automatically generated cpuid data.
 * The toolstack need not worry about setting them appropriately.
 * They can be dropped from the system maximum featuresets.

While editing gen-cpuid.py, reflow some comments which exceeded the expected
line length.

Signed-off-by: Andrew Cooper 
Reviewed-by: Doug Goldstein 
Acked-by: Wei Liu 
Reviewed-by: Jan Beulich 
---
 tools/libxc/xc_cpuid_x86.c | 19 ---
 xen/arch/x86/cpuid.c   | 25 +
 xen/tools/gen-cpuid.py | 29 ++---
 3 files changed, 15 insertions(+), 58 deletions(-)

diff --git a/tools/libxc/xc_cpuid_x86.c b/tools/libxc/xc_cpuid_x86.c
index 96d6025..918590f 100644
--- a/tools/libxc/xc_cpuid_x86.c
+++ b/tools/libxc/xc_cpuid_x86.c
@@ -41,7 +41,6 @@ enum {
 #define DEF_MAX_BASE 0x000du
 #define DEF_MAX_INTELEXT  0x8008u
 #define DEF_MAX_AMDEXT0x801cu
-#define COMMON_1D CPUID_COMMON_1D_FEATURES
 
 int xc_get_cpu_levelling_caps(xc_interface *xch, uint32_t *caps)
 {
@@ -712,24 +711,6 @@ static void sanitise_featureset(struct cpuid_domain_info 
*info)
 disabled_features[i] &= ~dfs[i];
 }
 }
-
-switch ( info->vendor )
-{
-case VENDOR_INTEL:
-/* Intel clears the common bits in e1d. */
-info->featureset[featureword_of(X86_FEATURE_SYSCALL)] &= ~COMMON_1D;
-break;
-
-case VENDOR_AMD:
-/* AMD duplicates the common bits between 1d and e1d. */
-info->featureset[featureword_of(X86_FEATURE_SYSCALL)] =
-((info->featureset[featureword_of(X86_FEATURE_FPU)] & COMMON_1D) |
- (info->featureset[featureword_of(X86_FEATURE_SYSCALL)] & 
~COMMON_1D));
-break;
-
-default:
-break;
-}
 }
 
 int xc_cpuid_apply_policy(xc_interface *xch, domid_t domid,
diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 3f398b5..87ec02f 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -67,18 +67,6 @@ static void sanitise_featureset(uint32_t *fs)
 disabled_features[j] &= ~dfs[j];
 }
 }
-
-/*
- * Sort out shared bits.  We are constructing a featureset which needs to
- * be applicable to a cross-vendor case.  Intel strictly clears the common
- * bits in e1d, while AMD strictly duplicates them.
- *
- * We duplicate them here to be compatible with AMD while on Intel, and
- * rely on logic closer to the guest to make the featureset stricter if
- * emulating Intel.
- */
-fs[FEATURESET_e1d] = ((fs[FEATURESET_1d]  &  CPUID_COMMON_1D_FEATURES) |
-  (fs[FEATURESET_e1d] & ~CPUID_COMMON_1D_FEATURES));
 }
 
 static void recalculate_xstate(struct cpuid_policy *p)
@@ -169,6 +157,8 @@ static void recalculate_xstate(struct cpuid_policy *p)
  */
 static void recalculate_misc(struct cpuid_policy *p)
 {
+p->extd.e1d &= ~CPUID_COMMON_1D_FEATURES;
+
 switch ( p->x86_vendor )
 {
 case X86_VENDOR_INTEL:
@@ -181,6 +171,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 p->extd.vendor_ebx = p->basic.vendor_ebx;
 p->extd.vendor_ecx = p->basic.vendor_ecx;
 p->extd.vendor_edx = p->basic.vendor_edx;
+
+p->extd.e1d |= p->basic._1d & CPUID_COMMON_1D_FEATURES;
 break;
 }
 }
@@ -669,10 +661,6 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->c = p->extd.e1c;
 res->d = p->extd.e1d;
 
-/* If not emulating AMD, clear the duplicated features in e1d. */
-if ( p->x86_vendor != X86_VENDOR_AMD )
-res->d &= ~CPUID_COMMON_1D_FEATURES;
-
 /*
  * MTRR used to unconditionally leak into PV guests.  They cannot MTRR
  * infrastructure at all, and shouldn't be able to see the feature.
@@ -792,11 +780,8 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 res->c = p->extd.e1c;
 res->d = p->extd.e1d;
 
-/* If not emulating AMD, clear the duplicated features in e1d. */
-if ( p->x86_vendor != X86_VENDOR_AMD )
-res->d &= ~CPUID_COMMON_1D_FEATURES;
 /* fast-forward MSR_APIC_BASE.EN if it hasn't already been clobbered. 
*/
-else if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
+if ( vlapic_hw_disabled(vcpu_vlapic(v)) )
 res->d &= ~cpufeat_bit(X86_FEATURE_APIC);
 
 /*
diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
index 6212e4f..5cab6db 100755
--- a/xen/tools/gen-cpuid.py
+++ b/xen/tools/gen-cpuid.py
@@ -129,16 +129,7 @@ def crunch_numbers(state):
 common_1d = (FPU, VME, DE, PSE, TSC, MSR, PAE, MCE, CX8, APIC,
  MTRR, PGE, MCA, CMOV, PAT, 

[Xen-devel] [PATCH v2 09/14] x86/cpuid: Handle leaf 0x80000009 in guest_cpuid()

[Andrew Cooper]

Leaf 0x8009 is reserved.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 

v2:
 * New
---
 xen/arch/x86/cpuid.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpuid.c b/xen/arch/x86/cpuid.c
index 4d48552..a8dce40 100644
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -206,6 +206,8 @@ static void recalculate_misc(struct cpuid_policy *p)
 
 p->extd.raw[0x8].a &= 0x00ff;
 p->extd.raw[0x8].c &= 0x0003f0ff;
+
+p->extd.raw[0x9] = EMPTY_LEAF;
 break;
 }
 }
@@ -712,7 +714,7 @@ static void pv_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8008:
+case 0x8000 ... 0x8009:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -808,7 +810,7 @@ static void hvm_cpuid(uint32_t leaf, uint32_t subleaf, 
struct cpuid_leaf *res)
 case 0x2 ... 0x3:
 case 0x7 ... 0x9:
 case 0xc ... XSTATE_CPUID:
-case 0x8000 ... 0x8008:
+case 0x8000 ... 0x8009:
 ASSERT_UNREACHABLE();
 /* Now handled in guest_cpuid(). */
 }
@@ -891,7 +893,7 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
 default:
 goto legacy;
 
-case 0x8000 ... 0x8008:
+case 0x8000 ... 0x8009:
 *res = p->extd.raw[leaf & 0x];
 break;
 }
-- 
2.1.4


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

Re: [Xen-devel] [linux-linus test] 104237: regressions - FAIL

[Boris Ostrovsky]

On 01/23/2017 07:16 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [linux-linus test] 104237: regressions - 
> FAIL"):
>> I'm inclined to increasing the timeout, although this slowness does
>> mean that our tests may be blocked more than we would like.
> I have set the host property which I think will cause the timeout to
> be increased.  This should take effect for the next run of
> linux-linus.


Thanks.

And it looks like x86 tests passed this morning so presumably the SCSI
patch indeed fixed the problems.

-boris

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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Konrad Rzeszutek Wilk]

On Mon, Jan 23, 2017 at 02:08:58PM +0100, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> > On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > > > Hi,
> > > >
> > > > I am sending twelfth version of multiboot2 protocol support for
> > > > legacy BIOS and EFI platforms. This patch series release contains
> > > > fixes for all known/confirmed issues.
> > >
> > > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> > > get the following on some of the systems I have access to:


Both me and Daniel seem to have test machines with EFI that are not soo .. 
defective.

Could you mention which boxes have these kinds of trouble so we can
get to the bottom of this?

[Is it by any chance a T420 or x230 laptop - I am using legacy BIOS on them
as I couldn't even get them to suspend properly]

And would it be possible to get serial/power access to this box (Intel NUC?)
to figure out what is going on?

Thanks!
.. snip..
> Once you told me that you applied some patches on top of my patch series to 
> get
> it working. Is it still true? If you still use some extra patches could you 
> send
> me them? What about ExitBootServices() call? Did you disabled it? If yes on 
> which
> machines it have to be disabled?
> 
> Daniel

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

Re: [Xen-devel] PVH CPU hotplug design document

[Boris Ostrovsky]

On 01/23/2017 05:35 AM, Jan Beulich wrote:
 On 22.01.17 at 19:39,  wrote:
>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>> On 18.01.17 at 12:54,  wrote:
 So, would it be fine to start a PVH Dom0 with as many vCPUs as what's 
 returned
 from dom0_max_vcpus, and mark them as enabled in the MADT. That's 
 basically all
 we need in order to match current PV Dom0 functionality?
>>> Yes, I think so.
>>
>> Have we then decided that we are not supporting ACPI hotplug for both 
>> dom0 and domU?
> I don't think anything has been decided yet, it's just that the road to
> (consistent) ACPI hotplug support still seems somewhat cloudy, so
> getting there (if we're convinced this is a worthwhile goal) may still
> take some time.


I am mostly interested in domU support at this point. This is the only
feature that I can think of right now that blocks domU support in Linux.

As I said in an earlier message I don't think dom0 needs ACPI hotplug
(or hotplug at all) while domU would benefit from it. But perhaps by
"consistent" you meant that you prefer both to behave in the same manner.

From Linux perspective one option could be to have domU with PV-style
vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
it becomes available. This, however, will need an indication from the
hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
discussed earlier.

-boris



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

Re: [Xen-devel] [PATCH v5 4/9] xen/x86: populate PVHv2 Dom0 physical memory map

[Boris Ostrovsky]

>  
> +static int __init modify_identity_mmio(struct domain *d, unsigned long pfn,
> +   unsigned long nr_pages, bool map)
> +{
> +int rc;
> +
> +for ( ; ; )
> +{
> +rc = (map ? map_mmio_regions : unmap_mmio_regions)

This can be taken outside the loop.

-boris

> + (d, _gfn(pfn), nr_pages, _mfn(pfn));
> +if ( rc == 0 )
> +break;
> +if ( rc < 0 )
> +{
> +printk(XENLOG_WARNING
> +   "Failed to identity %smap [%#lx,%#lx) for d%d: %d\n",
> +   map ? "" : "un", pfn, pfn + nr_pages, d->domain_id, rc);
> +break;
> +}
> +nr_pages -= rc;
> +pfn += rc;
> +process_pending_softirqs();
> +}
> +
> +return rc;
> +}
> +



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

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

[osstest service owner]

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

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

Last test of basis   103758  2016-12-19 18:49:12 Z   34 days
Testing same since   104606  2017-01-23 11:46:13 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH v7 2/8] dm_op: convert HVMOP_*ioreq_server*

[Paul Durrant]

The definitions of HVM_IOREQSRV_BUFIOREQ_* have to persist as they are
already in use by callers of the libxc interface.

Suggested-by: Jan Beulich 
Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Acked-by: Wei Liu 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 
--
Cc: Ian Jackson 

v6:
- Modify const_op as appropriate.

v4:
- #define uint64_aligned_t if necessary to handle compat code generation.

v3:
- Fix pad check.

v2:
- Addressed several comments from Jan.
---
 tools/libxc/xc_domain.c  | 212 -
 xen/arch/x86/hvm/dm.c|  93 +
 xen/arch/x86/hvm/hvm.c   | 219 ---
 xen/arch/x86/hvm/ioreq.c |  36 +++
 xen/include/asm-x86/hvm/domain.h |   3 +-
 xen/include/public/hvm/dm_op.h   | 158 
 xen/include/public/hvm/hvm_op.h  | 132 +--
 xen/include/xsm/dummy.h  |   6 --
 xen/include/xsm/xsm.h|   6 --
 xen/xsm/dummy.c  |   1 -
 xen/xsm/flask/hooks.c|   6 --
 11 files changed, 365 insertions(+), 507 deletions(-)

diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 296b852..419a897 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1417,24 +1417,24 @@ int xc_hvm_create_ioreq_server(xc_interface *xch,
int handle_bufioreq,
ioservid_t *id)
 {
-DECLARE_HYPERCALL_BUFFER(xen_hvm_create_ioreq_server_t, arg);
+struct xen_dm_op op;
+struct xen_dm_op_create_ioreq_server *data;
 int rc;
 
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(, 0, sizeof(op));
 
-arg->domid = domid;
-arg->handle_bufioreq = handle_bufioreq;
+op.op = XEN_DMOP_create_ioreq_server;
+data = _ioreq_server;
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_create_ioreq_server,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+data->handle_bufioreq = handle_bufioreq;
+
+rc = do_dm_op(xch, domid, 1, , sizeof(op));
+if ( rc )
+return rc;
 
-*id = arg->id;
+*id = data->id;
 
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return 0;
 }
 
 int xc_hvm_get_ioreq_server_info(xc_interface *xch,
@@ -1444,84 +1444,71 @@ int xc_hvm_get_ioreq_server_info(xc_interface *xch,
  xen_pfn_t *bufioreq_pfn,
  evtchn_port_t *bufioreq_port)
 {
-DECLARE_HYPERCALL_BUFFER(xen_hvm_get_ioreq_server_info_t, arg);
+struct xen_dm_op op;
+struct xen_dm_op_get_ioreq_server_info *data;
 int rc;
 
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(, 0, sizeof(op));
 
-arg->domid = domid;
-arg->id = id;
+op.op = XEN_DMOP_get_ioreq_server_info;
+data = _ioreq_server_info;
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_get_ioreq_server_info,
-  HYPERCALL_BUFFER_AS_ARG(arg));
-if ( rc != 0 )
-goto done;
+data->id = id;
+
+rc = do_dm_op(xch, domid, 1, , sizeof(op));
+if ( rc )
+return rc;
 
 if ( ioreq_pfn )
-*ioreq_pfn = arg->ioreq_pfn;
+*ioreq_pfn = data->ioreq_pfn;
 
 if ( bufioreq_pfn )
-*bufioreq_pfn = arg->bufioreq_pfn;
+*bufioreq_pfn = data->bufioreq_pfn;
 
 if ( bufioreq_port )
-*bufioreq_port = arg->bufioreq_port;
+*bufioreq_port = data->bufioreq_port;
 
-done:
-xc_hypercall_buffer_free(xch, arg);
-return rc;
+return 0;
 }
 
 int xc_hvm_map_io_range_to_ioreq_server(xc_interface *xch, domid_t domid,
 ioservid_t id, int is_mmio,
 uint64_t start, uint64_t end)
 {
-DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
-int rc;
+struct xen_dm_op op;
+struct xen_dm_op_ioreq_server_range *data;
 
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-return -1;
+memset(, 0, sizeof(op));
 
-arg->domid = domid;
-arg->id = id;
-arg->type = is_mmio ? HVMOP_IO_RANGE_MEMORY : HVMOP_IO_RANGE_PORT;
-arg->start = start;
-arg->end = end;
+op.op = XEN_DMOP_map_io_range_to_ioreq_server;
+data = _io_range_to_ioreq_server;
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_map_io_range_to_ioreq_server,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+data->id = id;
+data->type = is_mmio ? XEN_DMOP_IO_RANGE_MEMORY : XEN_DMOP_IO_RANGE_PORT;
+data->start = start;
+data->end = end;
 
-xc_hypercall_buffer_free(xch, arg);
-return 

[Xen-devel] [PATCH v7 3/8] dm_op: convert HVMOP_track_dirty_vram

[Paul Durrant]

The handle type passed to the underlying shadow and hap functions is
changed for compatibility with the new hypercall buffer.

NOTE: This patch also modifies the type of the 'nr' parameter of
  xc_hvm_track_dirty_vram() from uint64_t to uint32_t. In practice
  the value passed was always truncated to 32 bits.

Suggested-by: Jan Beulich 
Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
Acked-by: George Dunlap 
Acked-by: Tim Deegan 
Acked-by: Daniel De Graaf 
Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
Cc: Ian Jackson 

v4:
- Knock-on changes from compat code in dm.c. Not adding Jan's R-b since
  the patch has fundamentally changed.

v3:
- Check d->max_vcpus rather than d->vcpu, as requested by Jan.
- The handle type changes (from uint8 to void) are still necessary, hence
  omitting Jan's R-b until this is confirmed to be acceptable.

v2:
- Addressed several comments from Jan.
---
 tools/flask/policy/modules/xen.if   |  4 ++--
 tools/libxc/include/xenctrl.h   |  2 +-
 tools/libxc/xc_misc.c   | 32 +
 xen/arch/x86/hvm/dm.c   | 40 +++-
 xen/arch/x86/hvm/hvm.c  | 41 -
 xen/arch/x86/mm/hap/hap.c   |  2 +-
 xen/arch/x86/mm/shadow/common.c |  2 +-
 xen/include/asm-x86/hap.h   |  2 +-
 xen/include/asm-x86/shadow.h|  2 +-
 xen/include/public/hvm/dm_op.h  | 18 
 xen/include/public/hvm/hvm_op.h | 16 ---
 xen/xsm/flask/hooks.c   |  3 ---
 xen/xsm/flask/policy/access_vectors |  2 --
 13 files changed, 74 insertions(+), 92 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index f9254c2..45e5b5f 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -58,7 +58,7 @@ define(`create_domain_common', `
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
allow $1 $2:grant setup;
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
-   setparam pcilevel trackdirtyvram nested altp2mhvm 
altp2mhvm_op send_irq };
+   setparam pcilevel nested altp2mhvm altp2mhvm_op 
send_irq };
 ')
 
 # create_domain(priv, target)
@@ -151,7 +151,7 @@ define(`device_model', `
 
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-   allow $1 $2_target:hvm { getparam setparam trackdirtyvram hvmctl 
irqlevel pciroute pcilevel cacheattr send_irq dm };
+   allow $1 $2_target:hvm { getparam setparam hvmctl irqlevel pciroute 
pcilevel cacheattr send_irq dm };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index cf36521..0cf1b48 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1620,7 +1620,7 @@ int xc_hvm_inject_msi(
  */
 int xc_hvm_track_dirty_vram(
 xc_interface *xch, domid_t dom,
-uint64_t first_pfn, uint64_t nr,
+uint64_t first_pfn, uint32_t nr,
 unsigned long *bitmap);
 
 /*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 06e90de..4c41d41 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -581,34 +581,22 @@ int xc_hvm_inject_msi(
 
 int xc_hvm_track_dirty_vram(
 xc_interface *xch, domid_t dom,
-uint64_t first_pfn, uint64_t nr,
+uint64_t first_pfn, uint32_t nr,
 unsigned long *dirty_bitmap)
 {
-DECLARE_HYPERCALL_BOUNCE(dirty_bitmap, (nr+7) / 8, 
XC_HYPERCALL_BUFFER_BOUNCE_OUT);
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_track_dirty_vram, arg);
-int rc;
+struct xen_dm_op op;
+struct xen_dm_op_track_dirty_vram *data;
 
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL || xc_hypercall_bounce_pre(xch, dirty_bitmap) )
-{
-PERROR("Could not bounce memory for xc_hvm_track_dirty_vram 
hypercall");
-rc = -1;
-goto out;
-}
+memset(, 0, sizeof(op));
 
-arg->domid = dom;
-arg->first_pfn = first_pfn;
-arg->nr= nr;
-set_xen_guest_handle(arg->dirty_bitmap, dirty_bitmap);
+op.op = XEN_DMOP_track_dirty_vram;
+data = _dirty_vram;
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_track_dirty_vram,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+data->first_pfn = first_pfn;
+data->nr = nr;
 
-out:
-xc_hypercall_buffer_free(xch, arg);
-xc_hypercall_bounce_post(xch, dirty_bitmap);
-return rc;
+return do_dm_op(xch, dom, 2, , sizeof(op),
+dirty_bitmap, (nr + 7) / 8);
 }
 
 int 

[Xen-devel] [PATCH v7 6/8] dm_op: convert HVMOP_set_mem_type

[Paul Durrant]

This patch removes the need for handling HVMOP restarts, so that
infrastructure is removed.

NOTE: This patch also modifies the type of the 'nr' argument of
  xc_hvm_set_mem_type() from uint64_t to uint32_t. In practice the
  value passed was always truncated to 32 bits.

Suggested-by: Jan Beulich 
Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Acked-by: Wei Liu 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 
---
Cc: Ian Jackson 

v6:
- Pass by reference as requested by Andy.
- Modify const_op appropriately.

v4:
- Added initializers as requested by Jan.

v3:
- Addressed more comments from Jan.

v2:
- Addressed several comments from Jan.
---
 tools/libxc/include/xenctrl.h   |   2 +-
 tools/libxc/xc_misc.c   |  29 +++-
 xen/arch/x86/hvm/dm.c   |  91 
 xen/arch/x86/hvm/hvm.c  | 136 +---
 xen/include/public/hvm/dm_op.h  |  22 ++
 xen/include/public/hvm/hvm_op.h |  20 --
 xen/xsm/flask/policy/access_vectors |   2 +-
 7 files changed, 126 insertions(+), 176 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 5ff53ed..6648679 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1634,7 +1634,7 @@ int xc_hvm_modified_memory(
  * Allowed types are HVMMEM_ram_rw, HVMMEM_ram_ro, HVMMEM_mmio_dm
  */
 int xc_hvm_set_mem_type(
-xc_interface *xch, domid_t dom, hvmmem_type_t memtype, uint64_t first_pfn, 
uint64_t nr);
+xc_interface *xch, domid_t dom, hvmmem_type_t memtype, uint64_t first_pfn, 
uint32_t nr);
 
 /*
  * Injects a hardware/software CPU trap, to take effect the next time the HVM 
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 597df99..5b06d6b 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -590,30 +590,21 @@ int xc_hvm_modified_memory(
 }
 
 int xc_hvm_set_mem_type(
-xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t 
first_pfn, uint64_t nr)
+xc_interface *xch, domid_t dom, hvmmem_type_t mem_type, uint64_t 
first_pfn, uint32_t nr)
 {
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_mem_type, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_set_mem_type hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_set_mem_type *data;
 
-arg->domid= dom;
-arg->hvmmem_type  = mem_type;
-arg->first_pfn= first_pfn;
-arg->nr   = nr;
+memset(, 0, sizeof(op));
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_set_mem_type,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_set_mem_type;
+data = _mem_type;
 
-xc_hypercall_buffer_free(xch, arg);
+data->mem_type = mem_type;
+data->first_pfn = first_pfn;
+data->nr = nr;
 
-return rc;
+return do_dm_op(xch, dom, 1, , sizeof(op));
 }
 
 int xc_hvm_inject_trap(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index e28bda4..cc68ba9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -161,6 +161,82 @@ static int modified_memory(struct domain *d,
 return rc;
 }
 
+static bool allow_p2m_type_change(p2m_type_t old, p2m_type_t new)
+{
+return p2m_is_ram(old) ||
+   (p2m_is_hole(old) && new == p2m_mmio_dm) ||
+   (old == p2m_ioreq_server && new == p2m_ram_rw);
+}
+
+static int set_mem_type(struct domain *d,
+struct xen_dm_op_set_mem_type *data)
+{
+xen_pfn_t last_pfn = data->first_pfn + data->nr - 1;
+unsigned int iter = 0;
+int rc = 0;
+
+/* Interface types to internal p2m types */
+static const p2m_type_t memtype[] = {
+[HVMMEM_ram_rw]  = p2m_ram_rw,
+[HVMMEM_ram_ro]  = p2m_ram_ro,
+[HVMMEM_mmio_dm] = p2m_mmio_dm,
+[HVMMEM_unused] = p2m_invalid,
+[HVMMEM_ioreq_server] = p2m_ioreq_server,
+};
+
+if ( (data->first_pfn > last_pfn) ||
+ (last_pfn > domain_get_maximum_gpfn(d)) )
+return -EINVAL;
+
+if ( data->mem_type >= ARRAY_SIZE(memtype) ||
+ unlikely(data->mem_type == HVMMEM_unused) )
+return -EINVAL;
+
+while ( iter < data->nr )
+{
+unsigned long pfn = data->first_pfn + iter;
+p2m_type_t t;
+
+get_gfn_unshare(d, pfn, );
+if ( p2m_is_paging(t) )
+{
+put_gfn(d, pfn);
+p2m_mem_paging_populate(d, pfn);
+return -EAGAIN;
+}
+
+if ( p2m_is_shared(t) )
+rc = -EAGAIN;
+else if ( !allow_p2m_type_change(t, memtype[data->mem_type]) )
+rc = -EINVAL;
+else
+rc = 

[Xen-devel] [PATCH v7 1/8] public / x86: Introduce __HYPERCALL_dm_op...

[Paul Durrant]

...as a set of hypercalls to be used by a device model.

As stated in the new docs/designs/dm_op.markdown:

"The aim of DMOP is to prevent a compromised device model from
compromising domains other then the one it is associated with. (And is
therefore likely already compromised)."

See that file for further information.

This patch simply adds the boilerplate for the hypercall.

Signed-off-by: Paul Durrant 
Suggested-by: Ian Jackson 
Suggested-by: Jennifer Herbert 
Acked-by: Daniel De Graaf 
Acked-by: Wei Liu 
Reviewed-by: Andrew Cooper 
---
Cc: Ian Jackson 
Cc: Jennifer Herbert 
Cc: Jan Beulich 

v7:
- Move the hypercall and xen_dm_op_buf definition outside __XEN_TOOLS__

v6:
- Add bool to control copy-back of op structure as requested by Andy

v5:
- Copy functions now use exact sizes.
- Addressed other comments from Jan, Wei and Andrew. However I have
  left the code that unconditionally copies back the op structure as
  I think it will needlessly complicate the code to make this selective.

v4:
- Change XEN_GUEST_HANDLE_64 to XEN_GUEST_HANDLE in struct xen_dm_op_buf
  and add the necessary compat code. Drop Jan's R-b since the patch has
  been fundamentally modified.

v3:
- Re-written large portions of dmop.markdown to remove references to
  previous proposals and make it a standalone design doc.

v2:
- Addressed several comments from Jan.
- Removed modification of __XEN_LATEST_INTERFACE_VERSION__ as it is not
  needed in this patch.
---
 docs/designs/dmop.markdown| 165 ++
 tools/flask/policy/modules/xen.if |   2 +-
 tools/libxc/include/xenctrl.h |   1 +
 tools/libxc/xc_private.c  |  70 
 tools/libxc/xc_private.h  |   2 +
 xen/arch/x86/hvm/Makefile |   1 +
 xen/arch/x86/hvm/dm.c | 142 
 xen/arch/x86/hvm/hvm.c|   1 +
 xen/arch/x86/hypercall.c  |   2 +
 xen/include/Makefile  |   1 +
 xen/include/public/hvm/dm_op.h|  69 
 xen/include/public/xen.h  |   1 +
 xen/include/xen/hypercall.h   |  15 
 xen/include/xlat.lst  |   1 +
 xen/include/xsm/dummy.h   |   6 ++
 xen/include/xsm/xsm.h |   6 ++
 xen/xsm/flask/hooks.c |   7 ++
 17 files changed, 491 insertions(+), 1 deletion(-)
 create mode 100644 docs/designs/dmop.markdown
 create mode 100644 xen/arch/x86/hvm/dm.c
 create mode 100644 xen/include/public/hvm/dm_op.h

diff --git a/docs/designs/dmop.markdown b/docs/designs/dmop.markdown
new file mode 100644
index 000..3c3f3a6
--- /dev/null
+++ b/docs/designs/dmop.markdown
@@ -0,0 +1,165 @@
+DMOP
+
+
+Introduction
+
+
+The aim of DMOP is to prevent a compromised device model from compromising
+domains other than the one it is providing emulation for (which is therefore
+likely already compromised).
+
+The problem occurs when you a device model issues an hypercall that
+includes references to user memory other than the operation structure
+itself, such as with Track dirty VRAM (as used in VGA emulation).
+Is this case, the address of this other user memory needs to be vetted,
+to ensure it is not within restricted address ranges, such as kernel
+memory. The real problem comes down to how you would vet this address -
+the idea place to do this is within the privcmd driver, without privcmd
+having to have specific knowledge of the hypercall's semantics.
+
+The Design
+--
+
+The privcmd driver implements a new restriction ioctl, which takes a domid
+parameter.  After that restriction ioctl is issued, all unaudited operations
+on the privcmd driver will cease to function, including regular hypercalls.
+DMOP hypercalls will continue to function as they can be audited.
+
+A DMOP hypercall consists of a domid (which is audited to verify that it
+matches any restriction in place) and an array of buffers and lengths,
+with the first one containing the specific DMOP parameters. These can
+then reference further buffers from within in the array. Since the only
+user buffers passed are that found with that array, they can all can be
+audited by privcmd.
+
+The following code illustrates this idea:
+
+struct xen_dm_op {
+uint32_t op;
+};
+
+struct xen_dm_op_buf {
+XEN_GUEST_HANDLE(void) h;
+unsigned long size;
+};
+typedef struct xen_dm_op_buf xen_dm_op_buf_t;
+
+enum neg_errnoval
+HYPERVISOR_dm_op(domid_t domid,
+ xen_dm_op_buf_t bufs[],
+ unsigned int nr_bufs)
+
+@domid is the domain the hypercall operates on.
+@bufs points to an array of buffers where @bufs[0] contains a struct
+dm_op, describing the specific device model operation and its parameters.
+@bufs[1..] may be referenced in the parameters 

[Xen-devel] [PATCH v7 5/8] dm_op: convert HVMOP_modified_memory

[Paul Durrant]

This patch introduces code to handle DMOP continuations.

NOTE: This patch also modifies the type of the 'nr' argument of
  xc_hvm_modified_memory() from uint64_t to uint32_t. In practice the
  value passed was always truncated to 32 bits.

Suggested-by: Jan Beulich 
Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
Acked-by: Daniel De Graaf 
Reviewed-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
---
Cc: Ian Jackson 

v6:
- Pass by pointer as requested by Andy.
- Modify const_op appropriately.

v4:
- Continuation code in dm.c modified as knock-on from compat code. Not
  adding Jan's R-b since patch has fundamentally changed.

v3:
- Addressed more comments from Jan.

v2:
- Addressed several comments from Jan, including...
- Added explanatory note on continuation handling
---
 tools/libxc/include/xenctrl.h   |  2 +-
 tools/libxc/xc_misc.c   | 27 ---
 xen/arch/x86/hvm/dm.c   | 89 +++--
 xen/arch/x86/hvm/hvm.c  | 60 -
 xen/include/public/hvm/dm_op.h  | 19 
 xen/include/public/hvm/hvm_op.h | 13 --
 xen/xsm/flask/policy/access_vectors |  2 +-
 7 files changed, 116 insertions(+), 96 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 6ab7e20..5ff53ed 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1627,7 +1627,7 @@ int xc_hvm_track_dirty_vram(
  * Notify that some pages got modified by the Device Model
  */
 int xc_hvm_modified_memory(
-xc_interface *xch, domid_t dom, uint64_t first_pfn, uint64_t nr);
+xc_interface *xch, domid_t dom, uint64_t first_pfn, uint32_t nr);
 
 /*
  * Set a range of memory to a specific type.
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index ddea2bb..597df99 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -573,29 +573,20 @@ int xc_hvm_track_dirty_vram(
 }
 
 int xc_hvm_modified_memory(
-xc_interface *xch, domid_t dom, uint64_t first_pfn, uint64_t nr)
+xc_interface *xch, domid_t dom, uint64_t first_pfn, uint32_t nr)
 {
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_modified_memory, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_modified_memory 
hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_modified_memory *data;
 
-arg->domid = dom;
-arg->first_pfn = first_pfn;
-arg->nr= nr;
+memset(, 0, sizeof(op));
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_modified_memory,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_modified_memory;
+data = _memory;
 
-xc_hypercall_buffer_free(xch, arg);
+data->first_pfn = first_pfn;
+data->nr = nr;
 
-return rc;
+return do_dm_op(xch, dom, 1, , sizeof(op));
 }
 
 int xc_hvm_set_mem_type(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index d847892..e28bda4 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -14,6 +14,7 @@
  * this program; If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -107,6 +108,59 @@ static int set_isa_irq_level(struct domain *d, uint8_t 
isa_irq,
 return 0;
 }
 
+static int modified_memory(struct domain *d,
+   struct xen_dm_op_modified_memory *data)
+{
+xen_pfn_t last_pfn = data->first_pfn + data->nr - 1;
+unsigned int iter = 0;
+int rc = 0;
+
+if ( (data->first_pfn > last_pfn) ||
+ (last_pfn > domain_get_maximum_gpfn(d)) )
+return -EINVAL;
+
+if ( !paging_mode_log_dirty(d) )
+return 0;
+
+while ( iter < data->nr )
+{
+unsigned long pfn = data->first_pfn + iter;
+struct page_info *page;
+
+page = get_page_from_gfn(d, pfn, NULL, P2M_UNSHARE);
+if ( page )
+{
+mfn_t gmfn = _mfn(page_to_mfn(page));
+
+paging_mark_dirty(d, gmfn);
+/*
+ * These are most probably not page tables any more
+ * don't take a long time and don't die either.
+ */
+sh_remove_shadows(d, gmfn, 1, 0);
+put_page(page);
+}
+
+iter++;
+
+/*
+ * Check for continuation every 256th iteration and if the
+ * iteration is not the last.
+ */
+if ( (iter < data->nr) && ((iter & 0xff) == 0) &&
+ hypercall_preempt_check() )
+{
+data->first_pfn += iter;
+data->nr -= iter;
+
+rc = -ERESTART;
+break;
+}
+}
+
+return rc;
+}
+
 static int dm_op(domid_t domid,
  unsigned int 

[Xen-devel] [PATCH v7 7/8] dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi

[Paul Durrant]

NOTE: This patch also modifies the types of the 'vector', 'type' and
  'insn_len' arguments of xc_hvm_inject_trap() from uint32_t to
  uint8_t. In practice the values passed were always truncated to
  8 bits.

Suggested-by: Jan Beulich 
Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Acked-by: Wei Liu 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 
---
Cc: Ian Jackson 

v7:
- Fix libxc code broken in v6.

v6:
- s/trap/event as requested by Andy (and adjust struct hvm_vcpu
  accordingly).

v3:
- Fixed prefixing and padding.

v2:
- Addressed several comments from Jan.
---
 tools/flask/policy/modules/xen.if   |  2 +-
 tools/libxc/include/xenctrl.h   |  4 +-
 tools/libxc/xc_misc.c   | 64 ++--
 xen/arch/x86/hvm/dm.c   | 45 
 xen/arch/x86/hvm/hvm.c  | 84 ++---
 xen/include/asm-x86/hvm/vcpu.h  |  2 +-
 xen/include/public/hvm/dm_op.h  | 48 +
 xen/include/public/hvm/hvm_op.h | 45 
 xen/include/xsm/dummy.h |  6 ---
 xen/include/xsm/xsm.h   |  6 ---
 xen/xsm/dummy.c |  1 -
 xen/xsm/flask/hooks.c   |  6 ---
 xen/xsm/flask/policy/access_vectors |  5 +--
 13 files changed, 125 insertions(+), 193 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 092a6c5..45e5cea 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -151,7 +151,7 @@ define(`device_model', `
 
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-   allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr send_irq dm 
};
+   allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr dm };
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 6648679..aba69c4 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1641,8 +1641,8 @@ int xc_hvm_set_mem_type(
  * resumes. 
  */
 int xc_hvm_inject_trap(
-xc_interface *xch, domid_t dom, int vcpu, uint32_t vector,
-uint32_t type, uint32_t error_code, uint32_t insn_len,
+xc_interface *xch, domid_t dom, int vcpu, uint8_t vector,
+uint8_t type, uint32_t error_code, uint8_t insn_len,
 uint64_t cr2);
 
 /*
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 5b06d6b..0fc6c22 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -527,29 +527,20 @@ int xc_hvm_set_pci_link_route(
 }
 
 int xc_hvm_inject_msi(
-xc_interface *xch, domid_t dom, uint64_t addr, uint32_t data)
+xc_interface *xch, domid_t dom, uint64_t msi_addr, uint32_t msi_data)
 {
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_inject_msi, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_inject_msi hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_inject_msi *data;
 
-arg->domid = dom;
-arg->addr  = addr;
-arg->data  = data;
+memset(, 0, sizeof(op));
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_inject_msi,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_inject_msi;
+data = _msi;
 
-xc_hypercall_buffer_free(xch, arg);
+data->addr = msi_addr;
+data->data = msi_data;
 
-return rc;
+return do_dm_op(xch, dom, 1, , sizeof(op));
 }
 
 int xc_hvm_track_dirty_vram(
@@ -608,35 +599,26 @@ int xc_hvm_set_mem_type(
 }
 
 int xc_hvm_inject_trap(
-xc_interface *xch, domid_t dom, int vcpu, uint32_t vector,
-uint32_t type, uint32_t error_code, uint32_t insn_len,
+xc_interface *xch, domid_t dom, int vcpu, uint8_t vector,
+uint8_t type, uint32_t error_code, uint8_t insn_len,
 uint64_t cr2)
 {
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_inject_trap, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_inject_trap hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_inject_event *data;
 
-arg->domid   = dom;
-arg->vcpuid  = vcpu;
-arg->vector  = vector;
-arg->type= type;
-arg->error_code  = error_code;
-arg->insn_len= insn_len;
-arg->cr2 = cr2;
+memset(, 0, sizeof(op));
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  HVMOP_inject_trap,
-  HYPERCALL_BUFFER_AS_ARG(arg));
+op.op = XEN_DMOP_inject_event;
+data 

[Xen-devel] [PATCH v7 0/8] New hypercall for device models

[Paul Durrant]

Following on from the design submitted by Jennifer Herbert to the list [1]
this series provides an implementation of __HYPERCALL_dm_op followed by
patches based on Jan Beulich's previous HVMCTL series [2] to convert
tools-only HVMOPs used by device models to DMOPs.

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01052.html
[2] https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg02433.html

Paul Durrant (8):
  public / x86: Introduce __HYPERCALL_dm_op...
  dm_op: convert HVMOP_*ioreq_server*
  dm_op: convert HVMOP_track_dirty_vram
  dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level,
and...
  dm_op: convert HVMOP_modified_memory
  dm_op: convert HVMOP_set_mem_type
  dm_op: convert HVMOP_inject_trap and HVMOP_inject_msi
  x86/hvm: serialize trap injecting producer and consumer

 docs/designs/dmop.markdown  | 163 +
 tools/flask/policy/modules/xen.if   |   8 +-
 tools/libxc/include/xenctrl.h   |  13 +-
 tools/libxc/xc_domain.c | 212 +--
 tools/libxc/xc_misc.c   | 235 +
 tools/libxc/xc_private.c|  70 
 tools/libxc/xc_private.h|   2 +
 xen/arch/x86/hvm/Makefile   |   1 +
 xen/arch/x86/hvm/dm.c   | 567 ++
 xen/arch/x86/hvm/hvm.c  | 681 +---
 xen/arch/x86/hvm/ioreq.c|  36 +-
 xen/arch/x86/hvm/irq.c  |   7 +-
 xen/arch/x86/hypercall.c|   2 +
 xen/arch/x86/mm/hap/hap.c   |   2 +-
 xen/arch/x86/mm/shadow/common.c |   2 +-
 xen/include/Makefile|   1 +
 xen/include/asm-x86/hap.h   |   2 +-
 xen/include/asm-x86/hvm/domain.h|   3 +-
 xen/include/asm-x86/hvm/hvm.h   |   3 +
 xen/include/asm-x86/hvm/vcpu.h  |   2 +-
 xen/include/asm-x86/shadow.h|   2 +-
 xen/include/public/hvm/dm_op.h  | 375 
 xen/include/public/hvm/hvm_op.h | 230 +---
 xen/include/public/xen-compat.h |   2 +-
 xen/include/public/xen.h|   1 +
 xen/include/xen/hvm/irq.h   |   2 +-
 xen/include/xen/hypercall.h |  15 +
 xen/include/xlat.lst|   1 +
 xen/include/xsm/dummy.h |  36 +-
 xen/include/xsm/xsm.h   |  36 +-
 xen/xsm/dummy.c |   5 -
 xen/xsm/flask/hooks.c   |  37 +-
 xen/xsm/flask/policy/access_vectors |  15 +-
 33 files changed, 1452 insertions(+), 1317 deletions(-)
 create mode 100644 docs/designs/dmop.markdown
 create mode 100644 xen/arch/x86/hvm/dm.c
 create mode 100644 xen/include/public/hvm/dm_op.h

-- 
2.1.4


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

[Xen-devel] [PATCH v7 8/8] x86/hvm: serialize trap injecting producer and consumer

[Paul Durrant]

Since injection works on a remote vCPU, and since there's no
enforcement of the subject vCPU being paused, there's a potential race
between the producing and consuming sides. Fix this by leveraging the
vector field as synchronization variable.

Signed-off-by: Jan Beulich 
[re-based]
Signed-off-by: Paul Durrant 
Reviewed-by: Andrew Cooper 
---

v6:
- Adjust naming as required by previous patch.

v3:
- Re-re-re-based after more changes.

v2:
- Re-re-based after Andrew's recent changes.
---
 xen/arch/x86/hvm/dm.c |  5 -
 xen/arch/x86/hvm/hvm.c| 10 ++
 xen/include/asm-x86/hvm/hvm.h |  3 +++
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index ba88766..60cd602 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -245,13 +245,16 @@ static int inject_event(struct domain *d,
 if ( data->vcpuid >= d->max_vcpus || !(v = d->vcpu[data->vcpuid]) )
 return -EINVAL;
 
-if ( v->arch.hvm_vcpu.inject_event.vector != -1 )
+if ( cmpxchg(>arch.hvm_vcpu.inject_event.vector,
+ HVM_EVENT_VECTOR_UNSET, HVM_EVENT_VECTOR_UPDATING) !=
+ HVM_EVENT_VECTOR_UNSET )
 return -EBUSY;
 
 v->arch.hvm_vcpu.inject_event.type = data->type;
 v->arch.hvm_vcpu.inject_event.insn_len = data->insn_len;
 v->arch.hvm_vcpu.inject_event.error_code = data->error_code;
 v->arch.hvm_vcpu.inject_event.cr2 = data->cr2;
+smp_wmb();
 v->arch.hvm_vcpu.inject_event.vector = data->vector;
 
 return 0;
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index dc8af05..0ff81d7 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -538,13 +538,15 @@ void hvm_do_resume(struct vcpu *v)
 }
 }
 
-/* Inject pending hw/sw trap */
-if ( v->arch.hvm_vcpu.inject_event.vector != -1 )
+/* Inject pending hw/sw event */
+if ( v->arch.hvm_vcpu.inject_event.vector >= 0 )
 {
+smp_rmb();
+
 if ( !hvm_event_pending(v) )
 hvm_inject_event(>arch.hvm_vcpu.inject_event);
 
-v->arch.hvm_vcpu.inject_event.vector = -1;
+v->arch.hvm_vcpu.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
 }
 
 if ( unlikely(v->arch.vm_event) && v->arch.monitor.next_interrupt_enabled )
@@ -1515,7 +1517,7 @@ int hvm_vcpu_initialise(struct vcpu *v)
 (void(*)(unsigned long))hvm_assert_evtchn_irq,
 (unsigned long)v);
 
-v->arch.hvm_vcpu.inject_event.vector = -1;
+v->arch.hvm_vcpu.inject_event.vector = HVM_EVENT_VECTOR_UNSET;
 
 if ( is_pvh_domain(d) )
 {
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 04e67fe..f88ff2e 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -77,6 +77,9 @@ enum hvm_intblk {
 #define HVM_HAP_SUPERPAGE_2MB   0x0001
 #define HVM_HAP_SUPERPAGE_1GB   0x0002
 
+#define HVM_EVENT_VECTOR_UNSET(-1)
+#define HVM_EVENT_VECTOR_UPDATING (-2)
+
 /*
  * The hardware virtual machine (HVM) interface abstracts away from the
  * x86/x86_64 CPU virtualization assist specifics. Currently this interface
-- 
2.1.4


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

[Xen-devel] [PATCH v7 4/8] dm_op: convert HVMOP_set_pci_intx_level, HVMOP_set_isa_irq_level, and...

[Paul Durrant]

... HVMOP_set_pci_link_route

These HVMOPs were exposed to guests so their definitions need to be
preserved for compatibility. This patch therefore updates
__XEN_LATEST_INTERFACE_VERSION__ to 0x00040900 and makes the HVMOP
defintions conditional on __XEN_INTERFACE_VERSION__ less than that value.

NOTE: This patch also widens the 'domain' parameter of
  xc_hvm_set_pci_intx_level() from a uint8_t to a uint16_t.

Suggested-by: Jan Beulich 
Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 
Acked-by: Wei Liu 
Acked-by: Daniel De Graaf 
Reviewed-by: Andrew Cooper 
---
Cc: Ian Jackson 

v3:
- Remove unnecessary padding.

v2:
- Interface version modification moved to this patch, where it is needed.
- Addressed several comments from Jan.
---
 tools/flask/policy/modules/xen.if   |   8 +--
 tools/libxc/include/xenctrl.h   |   2 +-
 tools/libxc/xc_misc.c   |  83 --
 xen/arch/x86/hvm/dm.c   |  72 +++
 xen/arch/x86/hvm/hvm.c  | 136 
 xen/arch/x86/hvm/irq.c  |   7 +-
 xen/include/public/hvm/dm_op.h  |  42 +++
 xen/include/public/hvm/hvm_op.h |   4 ++
 xen/include/public/xen-compat.h |   2 +-
 xen/include/xen/hvm/irq.h   |   2 +-
 xen/include/xsm/dummy.h |  18 -
 xen/include/xsm/xsm.h   |  18 -
 xen/xsm/dummy.c |   3 -
 xen/xsm/flask/hooks.c   |  15 
 xen/xsm/flask/policy/access_vectors |   6 --
 15 files changed, 158 insertions(+), 260 deletions(-)

diff --git a/tools/flask/policy/modules/xen.if 
b/tools/flask/policy/modules/xen.if
index 45e5b5f..092a6c5 100644
--- a/tools/flask/policy/modules/xen.if
+++ b/tools/flask/policy/modules/xen.if
@@ -57,8 +57,8 @@ define(`create_domain_common', `
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage 
mmuext_op updatemp };
allow $1 $2:grant setup;
-   allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
-   setparam pcilevel nested altp2mhvm altp2mhvm_op 
send_irq };
+   allow $1 $2:hvm { cacheattr getparam hvmctl sethvmc
+   setparam nested altp2mhvm altp2mhvm_op send_irq };
 ')
 
 # create_domain(priv, target)
@@ -93,7 +93,7 @@ define(`manage_domain', `
 #   (inbound migration is the same as domain creation)
 define(`migrate_domain_out', `
allow $1 domxen_t:mmu map_read;
-   allow $1 $2:hvm { gethvmc getparam irqlevel };
+   allow $1 $2:hvm { gethvmc getparam };
allow $1 $2:mmu { stat pageinfo map_read };
allow $1 $2:domain { getaddrsize getvcpucontext pause destroy };
allow $1 $2:domain2 gettsc;
@@ -151,7 +151,7 @@ define(`device_model', `
 
allow $1 $2_target:domain { getdomaininfo shutdown };
allow $1 $2_target:mmu { map_read map_write adjust physmap target_hack 
};
-   allow $1 $2_target:hvm { getparam setparam hvmctl irqlevel pciroute 
pcilevel cacheattr send_irq dm };
+   allow $1 $2_target:hvm { getparam setparam hvmctl cacheattr send_irq dm 
};
 ')
 
 # make_device_model(priv, dm_dom, hvm_dom)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 0cf1b48..6ab7e20 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1594,7 +1594,7 @@ int xc_physdev_unmap_pirq(xc_interface *xch,
 
 int xc_hvm_set_pci_intx_level(
 xc_interface *xch, domid_t dom,
-uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
+uint16_t domain, uint8_t bus, uint8_t device, uint8_t intx,
 unsigned int level);
 int xc_hvm_set_isa_irq_level(
 xc_interface *xch, domid_t dom,
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 4c41d41..ddea2bb 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -470,33 +470,24 @@ int xc_getcpuinfo(xc_interface *xch, int max_cpus,
 
 int xc_hvm_set_pci_intx_level(
 xc_interface *xch, domid_t dom,
-uint8_t domain, uint8_t bus, uint8_t device, uint8_t intx,
+uint16_t domain, uint8_t bus, uint8_t device, uint8_t intx,
 unsigned int level)
 {
-DECLARE_HYPERCALL_BUFFER(struct xen_hvm_set_pci_intx_level, arg);
-int rc;
-
-arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
-if ( arg == NULL )
-{
-PERROR("Could not allocate memory for xc_hvm_set_pci_intx_level 
hypercall");
-return -1;
-}
+struct xen_dm_op op;
+struct xen_dm_op_set_pci_intx_level *data;
 
-arg->domid  = dom;
-arg->domain = domain;
-arg->bus= bus;
-arg->device = device;
-arg->intx   = intx;
-arg->level  = level;
+memset(, 0, sizeof(op));
 
-rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
-  

[Xen-devel] [PATCH XTF] also test AVX exceptions

[Jan Beulich]

... as they're different from SSE and FPU ones.

Signed-off-by: Jan Beulich 

--- a/include/arch/x86/cpuid.h
+++ b/include/arch/x86/cpuid.h
@@ -75,6 +75,7 @@ static inline bool cpu_has(unsigned int
 #define cpu_has_smx cpu_has(X86_FEATURE_SMX)
 #define cpu_has_pcidcpu_has(X86_FEATURE_PCID)
 #define cpu_has_xsave   cpu_has(X86_FEATURE_XSAVE)
+#define cpu_has_avx cpu_has(X86_FEATURE_AVX)
 
 #define cpu_has_syscall cpu_has(X86_FEATURE_SYSCALL)
 #define cpu_has_nx  cpu_has(X86_FEATURE_NX)
--- a/include/arch/x86/lib.h
+++ b/include/arch/x86/lib.h
@@ -396,6 +396,33 @@ static inline unsigned int str(void)
 return sel;
 }
 
+static inline uint64_t xgetbv(uint32_t index)
+{
+uint32_t feat_lo;
+uint64_t feat_hi;
+
+asm volatile ("xgetbv" : "=a" (feat_lo), "=d" (feat_hi)
+   :  "c" (index) );
+
+return feat_lo | (feat_hi << 32);
+}
+
+static inline void xsetbv(uint32_t index, uint64_t value)
+{
+asm volatile ("xsetbv" :: "a" ((uint32_t)value), "d" (value >> 32),
+  "c" (index) );
+}
+
+static inline uint64_t read_xcr0(void)
+{
+return xgetbv(0);
+}
+
+static inline void write_xcr0(uint64_t xcr0)
+{
+xsetbv(0, xcr0);
+}
+
 #endif /* XTF_X86_LIB_H */
 
 /*
--- a/include/arch/x86/processor.h
+++ b/include/arch/x86/processor.h
@@ -72,6 +72,30 @@
 #define X86_DR6_BT  (1u << 15)  /* Task switch */
 
 /*
+ * CPU features in XCR0.
+ */
+#define _XSTATE_FP0
+#define XSTATE_FP (1ULL << _XSTATE_FP)
+#define _XSTATE_SSE   1
+#define XSTATE_SSE(1ULL << _XSTATE_SSE)
+#define _XSTATE_YMM   2
+#define XSTATE_YMM(1ULL << _XSTATE_YMM)
+#define _XSTATE_BNDREGS   3
+#define XSTATE_BNDREGS(1ULL << _XSTATE_BNDREGS)
+#define _XSTATE_BNDCSR4
+#define XSTATE_BNDCSR (1ULL << _XSTATE_BNDCSR)
+#define _XSTATE_OPMASK5
+#define XSTATE_OPMASK (1ULL << _XSTATE_OPMASK)
+#define _XSTATE_ZMM   6
+#define XSTATE_ZMM(1ULL << _XSTATE_ZMM)
+#define _XSTATE_HI_ZMM7
+#define XSTATE_HI_ZMM (1ULL << _XSTATE_HI_ZMM)
+#define _XSTATE_PKRU  9
+#define XSTATE_PKRU   (1ULL << _XSTATE_PKRU)
+#define _XSTATE_LWP   62
+#define XSTATE_LWP(1ULL << _XSTATE_LWP)
+
+/*
  * Exception mnemonics.
  */
 #define X86_EXC_DE 0 /* Divide Error. */
--- a/tests/fpu-exception-emulation/main.c
+++ b/tests/fpu-exception-emulation/main.c
@@ -163,6 +163,37 @@ exinfo_t probe_sse(bool force)
 return fault;
 }
 
+/**
+ * AVX instructions.  The emulation flag is meaningless,
+ * but @#NM should be raised if the task has been switched.
+ */
+static const struct test_cfg avx[] =
+{
+{ CR0_SYM(  ), 0 },
+{ CR0_SYM(TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM(MP), 0 },
+{ CR0_SYM(MP, TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM), 0 },
+{ CR0_SYM(EM, TS), EXINFO_SYM(NM, 0) },
+{ CR0_SYM(EM, MP), 0 },
+{ CR0_SYM(EM, MP, TS), EXINFO_SYM(NM, 0) },
+};
+
+static exinfo_t probe_avx(bool force)
+{
+exinfo_t fault = 0;
+
+asm volatile ("test %[fep], %[fep];"
+  "jz 1f;"
+  _ASM_XEN_FEP
+  "1: vmovups %%xmm0, %%xmm0; 2:"
+  _ASM_EXTABLE_HANDLER(1b, 2b, ex_record_fault_eax)
+  : "+a" (fault)
+  : [fep] "q" (force));
+
+return fault;
+}
+
 void run_sequence(const struct test_cfg *seq, unsigned int nr,
   unsigned int (*fn)(bool), bool force, exinfo_t override)
 {
@@ -226,6 +257,31 @@ void run_tests(bool force)
 
 write_cr4(cr4);
 }
+
+if ( cpu_has_avx )
+{
+unsigned long cr4 = read_cr4();
+unsigned long xcr0;
+
+printk("Testing%s AVX\n", force ? " emulated" : "");
+write_cr4(cr4 & ~X86_CR4_OSXSAVE);
+run_sequence(avx, ARRAY_SIZE(avx), probe_avx, force,
+ EXINFO_SYM(UD, 0));
+
+printk("Testing%s AVX (CR4.OSXSAVE)\n", force ? " emulated" : "");
+write_cr4(cr4 | X86_CR4_OSXSAVE);
+xcr0 = read_xcr0();
+write_xcr0(xcr0 & ~XSTATE_YMM);
+run_sequence(avx, ARRAY_SIZE(avx), probe_avx, force,
+ EXINFO_SYM(UD, 0));
+
+printk("Testing%s AVX (CR4.OSXSAVE+XCR0.YMM)\n", force ? " emulated" : 
"");
+write_xcr0(xcr0 | XSTATE_SSE | XSTATE_YMM);
+run_sequence(avx, ARRAY_SIZE(avx), probe_avx, force, 0);
+
+write_xcr0(xcr0);
+write_cr4(cr4);
+}
 }
 
 void test_main(void)


also test AVX exceptions

... as they're different from SSE and FPU ones.

Signed-off-by: Jan Beulich 

--- a/include/arch/x86/cpuid.h
+++ b/include/arch/x86/cpuid.h
@@ -75,6 +75,7 @@ static inline bool 

Re: [Xen-devel] [PATCH v5 5/9] x86/hvm: add vcpu parameter to guest memory copy function

[Roger Pau Monne]

On Fri, Jan 20, 2017 at 07:45:35PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > @@ -3172,9 +3173,9 @@ static enum hvm_copy_result __hvm_copy(
> >  {
> >  static unsigned long lastpage;
> >  if ( xchg(, gfn) != gfn )
> > -gdprintk(XENLOG_DEBUG, "guest attempted write to 
> > read-only"
> > +printk(XENLOG_DEBUG, "%pv guest attempted write to 
> > read-only"
> >   " memory page. gfn=%#lx, mfn=%#lx\n",
> > - gfn, page_to_mfn(page));
> > + vcpu->domain, gfn, page_to_mfn(page));
> 
> Just vcpu here, or hitting this printk() will try to follow
> d->shared_info as if it were v->domain.
>
> With this fixed, Reviewed-by: Andrew Cooper 

Thanks, not sure why I've used domain here instead of vcpu.

Roger.

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

Re: [Xen-devel] [PATCH v12 00/10] x86: multiboot2 protocol support

[Daniel Kiper]

On Fri, Jan 20, 2017 at 10:54:12PM +0100, Daniel Kiper wrote:
> On Fri, Jan 20, 2017 at 02:42:30PM -0500, Doug Goldstein wrote:
> > On 1/19/17 8:34 PM, Daniel Kiper wrote:
> > > Hi,
> > >
> > > I am sending twelfth version of multiboot2 protocol support for
> > > legacy BIOS and EFI platforms. This patch series release contains
> > > fixes for all known/confirmed issues.
> >
> > With my fix to efi_multiboot2() in 5/10 and the entire series applied, I
> > get the following on some of the systems I have access to:
> >
> > (XEN) [2.000533] HVM: HAP page sizes: 4kB, 2MB, 1GB
> > (XEN) [7.012109] Stuck ??
> > (XEN) [7.012129] Failed to bring up CPU 1 (error -5)
> > (XEN) [   12.023606] Stuck ??
> > (XEN) [   12.023622] Failed to bring up CPU 2 (error -5)
> > (XEN) [   17.035099] Stuck ??
> > (XEN) [   17.035115] Failed to bring up CPU 3 (error -5)
> > (XEN) [   17.035116] Brought up 1 CPUs
> >
> > On other machines they reset when setting PAGING into cr0 (actually the
> > jmp following it) on line 124 of trampoline.S
>
> Thanks! I will take a look.
>
> > If I drop the series to just 2-5 against staging (since patch 1 has
> > already gone in) and apply the fix to efi_multiboot2() then all the
> > machines I presently have access to boot.
>
> Great!
>
> > Effectively the fix to efi_multiboot2() gets us back to the same level
> > of hardware support that v11 + my v5 was at for 1-5. So I will extend my:
> >
> > Reviewed-by: Doug Goldstein 
> > Tested-by: Doug Goldstein 
>
> Thanks!
>
> > on the condition that the fix is applied to 5/10 prior to commit.
>
> Will do.
>
> By the way, I have asked my team colleagues to do more tests of this series.
> I will come back to you if I have something in hand.

Once you told me that you applied some patches on top of my patch series to get
it working. Is it still true? If you still use some extra patches could you send
me them? What about ExitBootServices() call? Did you disabled it? If yes on 
which
machines it have to be disabled?

Daniel

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

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

[Andrew Cooper]

On 23/01/17 12:58, Roger Pau Monne wrote:
> On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote:
>> On 19/01/17 17:29, Roger Pau Monne wrote:
>>> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
>>> index 0ccef1d..f52f269 100644
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1545,6 +1545,15 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>>>  if ( opt_dom0pvh )
>>>  domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
>>>  
>>> +if ( dom0_pvh )
>>> +{
>>> +panic("Building a PVHv2 Dom0 is not yet supported.");
>> This would be cleaner immediately before the return 0 of
>> construct_dom0_pvh(), would it not?
>>
>> Otherwise, Reviewed-by: Andrew Cooper 
> I've moved the panic to the end of construct_dom0_pvh, and marked dom0_shadow
> as deprecated in the document, would you like me to keep the R-B?

Yeah - sounds fine.

~Andrew

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

Re: [Xen-devel] [PATCH v5 3/9] xen/x86: split Dom0 build into PV and PVHv2

[Roger Pau Monne]

On Fri, Jan 20, 2017 at 07:03:10PM +, Andrew Cooper wrote:
> On 19/01/17 17:29, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> > index 0ccef1d..f52f269 100644
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1545,6 +1545,15 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  if ( opt_dom0pvh )
> >  domcr_flags |= DOMCRF_pvh | DOMCRF_hap;
> >  
> > +if ( dom0_pvh )
> > +{
> > +panic("Building a PVHv2 Dom0 is not yet supported.");
> 
> This would be cleaner immediately before the return 0 of
> construct_dom0_pvh(), would it not?
> 
> Otherwise, Reviewed-by: Andrew Cooper 

I've moved the panic to the end of construct_dom0_pvh, and marked dom0_shadow
as deprecated in the document, would you like me to keep the R-B?

Roger.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7cf59c854f35c9680965fe83e9cfd863079ddd73
baseline version:
 ovmf f3fa35a00233b6f2e7653b3b8c3e2b28b8ecbe7f

Last test of basis   104600  2017-01-23 02:45:18 Z0 days
Testing same since   104603  2017-01-23 07:45:18 Z0 days1 attempts


People who touched revisions under test:
  Zhang Lubo 
  Zhang, Lubo 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support

[Wei Liu]

On Mon, Jan 23, 2017 at 01:34:21PM +0100, Juergen Gross wrote:
> On 23/01/17 13:14, Wei Liu wrote:
> > On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote:
> >> XS_RESTRICT and the xenstore library function xs_restrict() have never
> >> been usable in all configurations and there are no known users.
> >>
> >> This functionality was thought to limit access rights of device models
> >> to xenstore in order to avoid affecting other domains in case of a
> >> security breech. Unfortunately XS_RESTRICT won't help as current
> >> qemu is requiring access to dom0 only accessible xenstore paths to
> >> work correctly. So this command is useless and should be removed.
> >>
> >> In order to avoid problems in the future remove all support for
> >> XS_RESTRICT from xenstore.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >> I'm rather sure I didn't delete anything from oxenstored not related
> >> to XS_RESTRICT, but I could have missed something. I'd appreciate a
> >> thorough review of the ocaml changes I did as my knowledge is rather
> >> limited here.
> > [...]
> >>in
> >>if domid = Define.domid_self || Domains.exist domains domid then 
> >> "T\000" else "F\000"
> >>  
> >> -(* [restrict] is in the patch queue since xen3.2 *)
> >> -let do_restrict con t domains cons data =
> >> -  if not (Connection.is_dom0 con)
> >> -  then raise Define.Permission_denied;
> >> -  let domid =
> >> -  match (split None '\000' data) with
> >> -  | [ domid; "" ] -> c_int_of_string domid
> >> -  | _  -> raise Invalid_Cmd_Args
> >> -  in
> >> -  Connection.restrict con domid
> > 
> > You haven't removed the restrict function in connection.ml and perms.ml.
> 
> I wasn't sure whether they are needed for "normal" permission checks.
> 
> Will remove them in V3.
> 

Yeah, try to remove them and see if oxenstored still compiles. ;-)

> 
> Juergen
> 

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

Re: [Xen-devel] [PATCH v2] xenstore: remove XS_RESTRICT support

[Juergen Gross]

On 23/01/17 13:14, Wei Liu wrote:
> On Mon, Jan 23, 2017 at 12:32:55PM +0100, Juergen Gross wrote:
>> XS_RESTRICT and the xenstore library function xs_restrict() have never
>> been usable in all configurations and there are no known users.
>>
>> This functionality was thought to limit access rights of device models
>> to xenstore in order to avoid affecting other domains in case of a
>> security breech. Unfortunately XS_RESTRICT won't help as current
>> qemu is requiring access to dom0 only accessible xenstore paths to
>> work correctly. So this command is useless and should be removed.
>>
>> In order to avoid problems in the future remove all support for
>> XS_RESTRICT from xenstore.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>> I'm rather sure I didn't delete anything from oxenstored not related
>> to XS_RESTRICT, but I could have missed something. I'd appreciate a
>> thorough review of the ocaml changes I did as my knowledge is rather
>> limited here.
> [...]
>>  in
>>  if domid = Define.domid_self || Domains.exist domains domid then 
>> "T\000" else "F\000"
>>  
>> -(* [restrict] is in the patch queue since xen3.2 *)
>> -let do_restrict con t domains cons data =
>> -if not (Connection.is_dom0 con)
>> -then raise Define.Permission_denied;
>> -let domid =
>> -match (split None '\000' data) with
>> -| [ domid; "" ] -> c_int_of_string domid
>> -| _  -> raise Invalid_Cmd_Args
>> -in
>> -Connection.restrict con domid
> 
> You haven't removed the restrict function in connection.ml and perms.ml.

I wasn't sure whether they are needed for "normal" permission checks.

Will remove them in V3.


Juergen


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