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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  1538388f283a3cba96c08177413eb415db78921a
baseline version:
 xtf  88454e5ece8fc9caa23a2fd377e7dd0fb1043499

Last test of basis   109327  2017-05-11 22:16:09 Z7 days
Testing same since   109589  2017-05-18 17:17:35 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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=1538388f283a3cba96c08177413eb415db78921a
+ . ./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 
1538388f283a3cba96c08177413eb415db78921a
+ branch=xtf
+ revision=1538388f283a3cba96c08177413eb415db78921a
+ . ./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
+ '[' x1538388f283a3cba96c08177413eb415db78921a = 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
++ : tested/linux-arm-xen
++ '[' 

[Xen-devel] [linux-linus test] 109572: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  5 xen-install  fail in 109552 pass in 109572
 test-armhf-armhf-libvirt  5 xen-install  fail in 109552 pass in 109572
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-saverestore.2 
fail in 109552 pass in 109572
 test-amd64-i386-rumprun-i386 16 rumprun-demo-xenstorels/xenstorels.repeat fail 
in 109552 pass in 109572
 test-amd64-amd64-i386-pvgrub 18 guest-start/debian.repeat fail in 109552 pass 
in 109572
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 109552 pass 
in 109572
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail pass in 109552
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat  fail pass in 109552

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail blocked in 109505
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop  fail blocked in 109505
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 109552 
like 109505
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109505
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109505
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 109505
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 109505
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109505
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 109505
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 109505
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   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-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-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-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-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
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-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-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  

Re: [Xen-devel] [PATCH 03/18] xen/pvcalls: initialize the module and register the xenbus backend

[Stefano Stabellini]

On Wed, 17 May 2017, Juergen Gross wrote:
> On 16/05/17 21:58, Stefano Stabellini wrote:
> > On Tue, 16 May 2017, Juergen Gross wrote:
> >> On 15/05/17 22:35, Stefano Stabellini wrote:
> >>> The pvcalls backend has one ioworker per cpu: the ioworkers are
> >>> implemented as a cpu bound workqueue, and will deal with the actual
> >>> socket and data ring reads/writes.
> >>>
> >>> ioworkers are global: we only have one set for all the frontends. They
> >>> process requests on their wqs list in order, once they are done with a
> >>> request, they'll remove it from the list. A spinlock is used for
> >>> protecting the list. Each ioworker is bound to a different cpu to
> >>> maximize throughput.
> >>>
> >>> Signed-off-by: Stefano Stabellini 
> >>> CC: boris.ostrov...@oracle.com
> >>> CC: jgr...@suse.com
> >>> ---
> >>>  drivers/xen/pvcalls-back.c | 64 
> >>> ++
> >>>  1 file changed, 64 insertions(+)
> >>>
> >>> diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
> >>> index 2dbf7d8..46a889a 100644
> >>> --- a/drivers/xen/pvcalls-back.c
> >>> +++ b/drivers/xen/pvcalls-back.c
> >>> @@ -25,6 +25,26 @@
> >>>  #include 
> >>>  #include 
> >>>  
> >>> +struct pvcalls_ioworker {
> >>> + struct work_struct register_work;
> >>> + atomic_t io;
> >>> + struct list_head wqs;
> >>> + spinlock_t lock;
> >>> + int num;
> >>> +};
> >>> +
> >>> +struct pvcalls_back_global {
> >>> + struct pvcalls_ioworker *ioworkers;
> >>> + int nr_ioworkers;
> >>> + struct workqueue_struct *wq;
> >>> + struct list_head privs;
> >>> + struct rw_semaphore privs_lock;
> >>> +} pvcalls_back_global;
> >>> +
> >>> +static void pvcalls_back_ioworker(struct work_struct *work)
> >>> +{
> >>> +}
> >>> +
> >>>  static int pvcalls_back_probe(struct xenbus_device *dev,
> >>> const struct xenbus_device_id *id)
> >>>  {
> >>> @@ -59,3 +79,47 @@ static int pvcalls_back_uevent(struct xenbus_device 
> >>> *xdev,
> >>>   .uevent = pvcalls_back_uevent,
> >>>   .otherend_changed = pvcalls_back_changed,
> >>>  };
> >>> +
> >>> +static int __init pvcalls_back_init(void)
> >>> +{
> >>> + int ret, i, cpu;
> >>> +
> >>> + if (!xen_domain())
> >>> + return -ENODEV;
> >>> +
> >>> + ret = xenbus_register_backend(_back_driver);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + init_rwsem(_back_global.privs_lock);
> >>> + INIT_LIST_HEAD(_back_global.privs);
> >>> + pvcalls_back_global.wq = alloc_workqueue("pvcalls_io", 0, 0);
> >>> + if (!pvcalls_back_global.wq)
> >>> + goto error;
> >>> + pvcalls_back_global.nr_ioworkers = num_online_cpus();
> >>
> >> Really? Recently I cam across a system with 640 dom0 cpus. I don't think
> >> we want 640 workers initialized when loading the backend module. I'd
> >> prefer one or a few workers per connected frontend.
> > 
> > I think we want to keep the ioworker allocation to be based on the
> > number of vcpus: we do not want more ioworkers than vcpus because it is
> > a waste of resources and leads to worse performance.  Also, given that
> > they do memcpy's, I also think it is a good idea to bind them to vcpus
> > (and pin vcpus to pcpus) to get best performance.
> 
> This will cause a lot of pain for the cpu offline case. Please don't try
> to work against the hypervisor scheduler by designing a backend based on
> a vcpu pin policy. This might result in best performance for your
> special workload, but generally it is a bad idea!

You are right. Of course, vcpu pinning is not a fundamental requirement
for this backend. I wrote about vcpu pinning only to help with the
explanation.

However, pvcalls is a memcpy based protocol and to perform memcpys
efficiently is very important to keep caches hot. The target is to hit
the same cacheline when reading and writing, which makes a huge
difference; it depends on processor and architecture but it is easily
20%. To get caching benefits, we need to do memcpys for the same socket
on the same vcpu (and on the same pcpu as well, that's why I mentioned
vcpu pinning, but we'll trust the Xen scheduler to do the right thing
when there is no contention).

This is why in this backend, regardless of the workqueue
design/allocation we use, I think we have to stick to two basic
principles:

- each socket is bound to one vcpu
- sockets are distributed evenly across vcpus


> > However, you have a point there: we need to handle systems with an
> > extremely large number of Dom0 vcpus. I suggest we introduce an
> > upper limit for the number of ioworkers. Something like:
> > 
> > #define MAX_IOWORKERS 64
> > nr_ioworkers = min(MAX_IOWORKERS, num_online_cpus())
> > 
> > MAX_IOWORKERS could be configurable via a command line option.
> 
> Later you are assigning each active socket to exactly one ioworker.
> Wouldn't it make more sense to allocate the ioworker when doing
> the connect? This would avoid the problem of having only a statistical
> distribution, possibly with all 

Re: [Xen-devel] [PATCH v8 0/3] arm64, xen: add xen_boot support into grub-mkconfig

[Daniel Kiper]

On Mon, May 15, 2017 at 03:46:55PM +0200, Daniel Kiper wrote:
> Hi Julien,
>
> On Mon, May 15, 2017 at 02:43:28PM +0100, Julien Grall wrote:
> > Hi Daniel,
> >
> > On 15/05/17 14:38, Daniel Kiper wrote:
> > >On Sun, May 14, 2017 at 03:43:44PM +0800, fu@linaro.org wrote:
> > >>From: Fu Wei 
> > >>
> > >>This patchset add xen_boot support into grub-mkconfig for
> > >>generating xen boot entrances automatically
> > >>
> > >>Also update the docs/grub.texi for new xen_boot commands.
> > >
> > >LGTM, if there are no objections I will commit it at the end
> > >of this week or the beginning of next one.
> >
> > Thank you!
> >
> > Can you also please commit patch [1] which has been sitting on the grub
> > ML for more than a year? This is preventing to boot Xen ARM with GRUB.
> >
> > Cheers,
> >
> > [1] https://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html
>
> Will do with this patch series.

Committed...

Daniel

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

Re: [Xen-devel] [PATCH 08/18] xen/pvcalls: implement connect command

[Boris Ostrovsky]

On 05/18/2017 03:10 PM, Stefano Stabellini wrote:
> On Tue, 16 May 2017, Boris Ostrovsky wrote:
> + ret = xenbus_map_ring_valloc(dev, >u.connect.ref, 1, );
> + if (ret < 0) {
> + sock_release(map->sock);
> + kfree(map);
> + goto out;
> + }
> + map->ring = page;
> + map->ring_order = map->ring->ring_order;
> + /* first read the order, then map the data ring */
> + virt_rmb();
 Not sure I understand what the barrier is for here. I don't think compiler
 will reorder ring_order access with the call.
>>> It's to avoid using the live version of ring_order to map the data ring
>>> pages (the other end could be changing that value at any time). We want
>>> to be sure that the compiler doesn't optimize out map->ring_order and
>>> use map->ring->ring_order instead.
>> Wouldn't WRITE_ONCE(map->ring_order, map->ring->ring_order) be the right
>> primitive then?
> It doesn't have to be atomic, because right after the assignment we
> check if map->ring_order is an appropriate value (see below).

WRITE_ONCE() is not about atomicity, it's about not allowing compilers
get too aggressive.

>
>
>> And also: if the other side changes ring size, what are we mapping then?
>> It's obsolete by now.
> If the grants are wrong, the mapping hypercalls will fail, the same way
> they do with any of the other PV frontends/backends today. That is not
> the problem we are trying to address with the barrier.
>
> The issue is here is that by runtime changes to map->ring->ring_order,
> the frontend could issue a denial of service by getting the backend into
> a busyloop. You can imagine that:
>
>   for (i = 0; i < map->ring->ring_order; i++) {
>
> might not work as the backend expects if map->ring->ring_order can
> change at any time.
>
> One could say that the code is already written this way:
>
>   for (i = 0; i < map->ring_order; i++) {
>
> So what's the problem? We have seen instances in the past of the
> compiler "optimizing" things in a way that actually the assembly did:
>
>   for (i = 0; i < map->ring->ring_order; i++) {
>
> This is why I put a barrier there, to avoid such compiler
> "optimizations". Does it make sense?

Right, I understand all this. I thought you meant that changing
ring_order was part of normal operation (i.e. somewhat expected) and I
couldn't see how that would work.

Thanks for taking time to write this down.

-boris

>
>
> + if (map->ring_order > MAX_RING_ORDER) {
> + ret = -EFAULT;
> + goto out;
> + }
 If the barrier is indeed needed this check belongs before it.
>>> I don't think so, see above.
>>>
>>>
> + ret = xenbus_map_ring_valloc(dev, map->ring->ref,
> +  (1 << map->ring_order), );
> + if (ret < 0) {
> + sock_release(map->sock);
> + xenbus_unmap_ring_vfree(dev, map->ring);
> + kfree(map);
> + goto out;
> + }
> + map->bytes = page;
>


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

Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Julien Grall]

On 18/05/2017 21:02, Manish Jaggi wrote:

In the IORT table using the  PCI-RC node, SMMU node and ITS node,
RID->StreamID->Device-ID  mapping can be generated.
As per IORT spec toady, same RID can be mapped to different StreamIDs
using two ID Array elements with same RID range but different output
reference.
There exists no use case for such a scenario hence a clarification is
required in IORT spec which states that RID range cannot overlap in the
ID array.


I understand that.



with this clarification in place, it is straight-forward to map RID to a
device-ID by replacing output of SMMU to output of RCI-RC


I am not sure to follow your suggestion here. But I will wait a patch 
before commenting.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Manish Jaggi]

Hi Julien,

On 5/18/2017 8:27 PM, Julien Grall wrote:

Hello,

On 18/05/17 12:59, Manish Jaggi wrote:

On 2/27/2017 11:42 PM, Julien Grall wrote:

On 02/27/2017 04:58 PM, Shanker Donthineni wrote:

Hi Julien,


Hi Shanker,

Please don't drop people in CC. In my case, any e-mail I am not CCed
are skipping my inbox and I may not read them for a while.



On 02/27/2017 08:12 AM, Julien Grall wrote:



On 27/02/17 13:23, Vijay Kilari wrote:

Hi Julien,


Hello Vijay,


On Wed, Feb 22, 2017 at 7:40 PM, Julien Grall 
wrote:

Hello,

There was few discussions recently about hiding SMMUs from DOM0 
when

using
ACPI. I thought it would be good to have a separate thread for 
this.


When using ACPI, the SMMUs will be described in the IO Remapping
Table
(IORT). The specification can be found on the ARM website [1].

For a brief summary, the IORT can be used to discover the SMMUs
present on
the platform and find for a given device the ID to configure
components such
as ITS (DeviceID) and SMMU (StreamID).

The appendix A in the specification gives an example how 
DeviceID and

StreamID can be found. For instance, when a PCI device is both
protected by
an SMMU and MSI-capable the following translation will happen:
RID -> StreamID -> DeviceID

Currently, SMMUs are hidden from DOM0 because they are been used by
Xen and
we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0
will try
to initialize SMMU and crash.

I first thought about using a Xen specific way (STAO) or 
extending a

flag in
IORT. But that is not ideal.

So we would have to rewrite the IORT for DOM0. Given that a 
range of

RID can
mapped to multiple ranges of DeviceID,
Do you envisage a scenario where same RID can map to multiple StreamIDs 
belonging to different SMMUs ?

we would have to translate
RID one by
one to find the associated DeviceID. I think this may end up to
complex code
and have a big IORT table.


Why can't we replace Output base of IORT of PCI node with SMMU 
output

base?.
I mean similar to PCI node without SMMU, why can't replace output 
base

of PCI node with
SMMU's output base?.


Because I don't see anything in the spec preventing one RC ID mapping
to produce multiple SMMU ID mapping. So which output base would you
use?



Basically, remove SMMU nodes, and replaces output of the PCIe and 
named

nodes ID mappings with ITS nodes.

RID --> StreamID  --> dviceID  --> ITS device id = RID --> dviceID  
-->

ITS device id


Can you detail it? You seem to assume that one RC ID mapping range
will only produce ID mapping range. AFAICT, this is not mandated by
the spec.


You are correct that it is not mandated by the spec, but AFAIK there
seems to be no valid use case for that.


Xen has to be compliant with the spec, if the spec says something then 
we should do it unless there is a strong reason not to.


In this case, it is not too difficult to implement the suggestion I 
wrote a couple of months ago. So why would we try to put us in a corner?



See below


RID range should not overlap between ID Array entries.


I believe you misunderstood my point here. So let me give an example. 
My understanding of the spec is it is possible to have:


RC A
 // doesn't use SMMU 0 so just outputs DeviceIDs to ITS GROUP 0
 // Input ID --> Output reference: Output ID
0x-0x --> ITS GROUP 0 : 0x->0x

SMMU 0
// Note that range of StreamIDs that map to DeviceIDs excludes
// the NIC 0 DeviceID as it does not generate MSIs
 // Input ID --> Output reference: Output ID
0x-0x01ff --> ITS GROUP 0 : 0x1->0x101ff
0x0200-0x --> ITS GROUP 0 : 0x2->0x207ff

// SMMU 0 Control interrupt is MSI based
 // Input ID --> Output reference: Output ID
N/A --> ITS GROUP 0 : 0x21

I could have misunderstood so I am stating my understanding so far .. 
please feel free to correct me :)


In the IORT table using the  PCI-RC node, SMMU node and ITS node, 
RID->StreamID->Device-ID  mapping can be generated.
As per IORT spec toady, same RID can be mapped to different StreamIDs 
using two ID Array elements with same RID range but different output 
reference.
There exists no use case for such a scenario hence a clarification is 
required in IORT spec which states that RID range cannot overlap in the 
ID array.


with this clarification in place, it is straight-forward to map RID to a 
device-ID by replacing output of SMMU to output of RCI-RC



I believe this would be updated in the next IORT spec revision.


Well, Xen should still support current revision of IORT even if the 
next version add more restriction.


Cheers,



-Manish


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

Re: [Xen-devel] [PATCH v2 6/9] ts-xen-build: Build the livepatch test-cases

[Konrad Rzeszutek Wilk]

On Thu, May 18, 2017 at 05:47:08PM +0100, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [PATCH v2 6/9] ts-xen-build: Build the 
> livepatch test-cases"):
> > > or something ?
> > 
> > I ended up doing two patches - one to create an enable_livepatch
> > (in mfi-common) to seed the jobs.
> > 
> > And then another to piggyback on that.
> > 
> > I am attaching them here (as attachment), and I think it makes
> > it simpler?
> 
> Why wouldn't you simply always build the live patch if it is
> available ?
> 
> I don't think this runvar-based system, where the xen version is
> tested, is a very good idea.

Oh. See below please why I choose that route.
> 
> > @@ -95,6 +96,12 @@ sub checkout () {
> > echo >>.config LIBLEAFDIR_x86_64=lib
> > echo >>.config KERNELS=''
> >  END
> > +   (${enable_livepatch} ? < > +   if test -f xen/Kconfig; then
> > +   echo >>xen/.config CONFIG_LIVEPATCH=y
> > +   echo >>xen/.config CONFIG_FAST_SYMBOL_LOOKUP=y
> > +fi
> > +END
> 
> I see you copied this from the xsm build, but I think there is no
> reason for osstest to ever build without livepatching support ?  So
> this could be unconditional.  You could put it nexst to CONFIG_EXPERT
> and _FEP and _VERBOSE_DEBUG.

OK.
> 
> > +if ($enable_livepatch) {
> > +buildcmd_stamped_logged(600, 'xen', 'xenlpt', < > +export XEN_ROOT=$builddir/xen
> > +export DESTDIR=$builddir/xen/dist/xenlpt
> > +export BASEDIR=$builddir/xen/xen
> > +mkdir -p \${DESTDIR}/usr/lib/debug
> > +END
> > +$make_prefix make -C xen/test -f $builddir/xen/xen/Rules.mk 
> > install
> 
> So here this would need to be conditional.  But it should be
> conditional on whether the build can produce it, so use
> target_file_exists.

OK. Now here comes the more difficult problem. The patch to make 'make
-C xen/test install' work is not yet in Xen 4.9. So earlier versions
would fail :-(

I could do a check in xen/test/Makefile for an install stanze or just
have an check for a version of Xen?

Or do what I had done in the previous patch (which you didn't like)
which was to just a combination of 'find' and copy them by hand.

Thoughts:
 a) Depend on Xen version (and my patch to add install stanze in
xen/test/Makefile making it in Xen 4.9).
 b) USe the old approach of 'find' and 'cp' the *.livepatch files
(works with Xen 4.8, 4.9).
 c) Base it on Xen version and only allow Xen 4.9 and later to be
tested.

?
> 
> Ian.

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

Re: [Xen-devel] [PATCH 08/18] xen/pvcalls: implement connect command

[Stefano Stabellini]

On Tue, 16 May 2017, Boris Ostrovsky wrote:
> >>> + ret = xenbus_map_ring_valloc(dev, >u.connect.ref, 1, );
> >>> + if (ret < 0) {
> >>> + sock_release(map->sock);
> >>> + kfree(map);
> >>> + goto out;
> >>> + }
> >>> + map->ring = page;
> >>> + map->ring_order = map->ring->ring_order;
> >>> + /* first read the order, then map the data ring */
> >>> + virt_rmb();
> >>
> >> Not sure I understand what the barrier is for here. I don't think compiler
> >> will reorder ring_order access with the call.
> > It's to avoid using the live version of ring_order to map the data ring
> > pages (the other end could be changing that value at any time). We want
> > to be sure that the compiler doesn't optimize out map->ring_order and
> > use map->ring->ring_order instead.
> 
> Wouldn't WRITE_ONCE(map->ring_order, map->ring->ring_order) be the right
> primitive then?

It doesn't have to be atomic, because right after the assignment we
check if map->ring_order is an appropriate value (see below).


> And also: if the other side changes ring size, what are we mapping then?
> It's obsolete by now.

If the grants are wrong, the mapping hypercalls will fail, the same way
they do with any of the other PV frontends/backends today. That is not
the problem we are trying to address with the barrier.

The issue is here is that by runtime changes to map->ring->ring_order,
the frontend could issue a denial of service by getting the backend into
a busyloop. You can imagine that:

  for (i = 0; i < map->ring->ring_order; i++) {

might not work as the backend expects if map->ring->ring_order can
change at any time.

One could say that the code is already written this way:

  for (i = 0; i < map->ring_order; i++) {

So what's the problem? We have seen instances in the past of the
compiler "optimizing" things in a way that actually the assembly did:

  for (i = 0; i < map->ring->ring_order; i++) {

This is why I put a barrier there, to avoid such compiler
"optimizations". Does it make sense?


> >>> + if (map->ring_order > MAX_RING_ORDER) {
> >>> + ret = -EFAULT;
> >>> + goto out;
> >>> + }
> >> If the barrier is indeed needed this check belongs before it.
> > I don't think so, see above.
> >
> >
> >>
> >>> + ret = xenbus_map_ring_valloc(dev, map->ring->ref,
> >>> +  (1 << map->ring_order), );
> >>> + if (ret < 0) {
> >>> + sock_release(map->sock);
> >>> + xenbus_unmap_ring_vfree(dev, map->ring);
> >>> + kfree(map);
> >>> + goto out;
> >>> + }
> >>> + map->bytes = page;
> >>>
> 

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

Re: [Xen-devel] Livepatching and Xen Security

[Andrew Cooper]

On 18/05/17 17:40, George Dunlap wrote:
> There are four general areas I think there may be bugs.
>
> ## Unprivileged access to Livepatching hypercalls
>
> ## Bugs in the patch creation tools which create patches with vulnerabilities
>
> ## Bugs in the patch-application code such that vulnerabilities exist
> after application
>
> ## Bugs which allow a guest to prevent the application of a livepatch
>
> # Testing status and requirements
>
> I'm told we already test that unprivileged guests cannot access the
> Livepatch hypercalls in osstest; if so, that aspect should should be
> covered.

Specifically, http://xenbits.xen.org/docs/xtf/test-livepatch-priv-check.html

(There is a docs bug I have noticed while grabbing that link, which I
have just pushed a fix for.  The live docs will be updated whenever cron
next runs.)

(I'd also like to take this opportunity to highlight an issue which
became apparent while writing that test; unstable hypercall ABIs,
wherever they reside, make this kind of testing prone to false negatives.)

> All that's needed would be for vendors to describe what kinds of
> testing they have done for Livepatching.  I think there are two
> factors which come into play:
>
> 1. Having tested live-patching thoroughly for at least some version of
> the codebase
>
> 2. Having tested live-patching for one of the Xen 4.9 RCs.
>
> Thoughts?

As a statement of what XenServer is doing:

XenServer 7.1 is based on Xen 4.7 and we are providing livepatches
(where applicable) with hypervisor hotfixes.  Thus far, XSAs 204, 207,
212-215 have been included in livepatch form, as well as a number of
other general bugfixes which were save to livepatch.

For both these hotfixes, we had to bugfix the livepatch creation tools
to generate a livepatch.  We also had to modify the XSA 213 patch to
create a livepatch.  The (pre 4.8) Xen code was buggy and used the
.fixup section when it should have used .text.unlikley, which caused the
livepatch tools to fail a cross-check of the exception frame references
when building the patch.

Thus, we are 0 for 2 on the tools being able to DTRT when given a set of
real-world fixes.

Independent of this, the nature of what qualifies as "a correct patch"
is subjective and very context dependent.  Consider a scenario with two
users, the same version of the livepatch tools, an identical source
patch, and an identical source version of Xen.  There is a very real
possibility that these two users could get one valid and one invalid
patch based solely on something like the compiler settings used to build
the hypervisor they are patching.

From an XSA point of view, we do not want to be issuing advisories
saying "If you are on OS $A, with livepatch tools $B, Hypervisor $C
compiled with these specific build options, then trying to create a
livepatch for patch $D will appear to work properly but leave a timebomb
in your hypervisor".  ISTR an issue which hit during development was
where CentOS releasing an minor update to GCC and caused chaos by
altering how the string literals got sorted.

What if a user creates a livepatch for a change which isn't remotely
safe to livepatch, uploads it, and their hypervisor goes bang?  This
would qualify under the definition of "correct" in so far as the patch
was correctly doing what it was told, and thus, fall within the security
criteria presented here.

There is already a very high user requirement in the first place to
evaluate whether patches are safe to livepatch.  This includes
interaction with other livepatches, interactions with patches in the
vendors patch queue, interaction with customer hardware, and there is no
way this can be decided automatically.

Therefore, I think it would be a mistake for us to include anything
pertaining to "creating a livepatch, correct or otherwise" within a
support statement.  There are many variables which we as upstream can't
control.

As for the 4th point, about what a guest can do to prevent application
of a livepatch.

The default timeout is insufficient to quiesce Xen if a VM with a few
VCPUs is migrating.  In this scenario, I believe p2m_lock contention is
the underlying reason, but the point stands that there are plenty of
things a guest can do to prevent Xen being able to suitably quiesce.

As a host administrator attempting to apply the livepatch, you get
informed that Xen failed to quiesce and the livepatch application
failed.  Options range from upping the timeout on the next patching
attempt, to possibly even manually pausing the troublesome VM for a second.

I also think it unwise to consider any scenarios like this within the
security statement, otherwise we will have to issue an XSA stating
"Guests doing normal unprivileged things can cause Xen to be
insufficient quiescent to apply livepatches with the deliberately
conservative defaults".  What remediation would we suggest for this?


On the points of unexpected access to the hypercalls, and Xen doing the
wrong thing when presented with a legitimate 

[Xen-devel] Notes on stubdoms and latency on ARM

[Stefano Stabellini]

Hi all,

Julien, Dario, George and I had a quick meeting to discuss stubdom
scheduling. These are my notes.


Description of the problem: need for a place to run emulators and
mediators outside of Xen, with low latency.

Explanation of what EL0 apps are. What should be their interface with
Xen? Could the interface be the regular hypercall interface? In that
case, what's the benefit compared to stubdoms?

The problem with stubdoms is latency and scheduling. It is not
deterministic. We could easily improve the null scheduler to introduce
some sort of non-preemptive scheduling of stubdoms on the same pcpus of
the guest vcpus. It would still require manually pinning vcpus to pcpus.

Then, we could add a sched_op hypercall to let the schedulers know that
a stubdom is tied to a specific guest domain. At that point, the
scheduling of stubdoms would become deterministic and automatic with the
null scheduler. It could be done to other schedulers too, but it will be
more work.

The other issue with stubdoms is context switch times. Volodymyr showed
that minios has much higher context switch times compared to EL0 apps.
It is probably due to GIC context switch, that is skipped for EL0 apps.
Maybe we could skip GIC context switch for stubdoms too, if we knew that
they are not going to use the VGIC. At that point, context switch times
should be very similar to EL0 apps.


ACTIONS:
Improve the null scheduler to enable decent stubdoms scheduling on
latency sensitive systems.
Investigate ways to improve context switch times on ARM.


Cheers,

Stefano

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2   6 xen-boot fail REGR. vs. 107358
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail in 109475 REGR. 
vs. 107358
 test-amd64-i386-xl-qemut-winxpsp3 16 guest-stop fail in 109475 REGR. vs. 107358

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  3 host-install(3)  broken pass in 109545
 test-amd64-amd64-i386-pvgrub 9 debian-di-install fail in 109475 pass in 109565
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 109545 
pass in 109565
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-stop fail in 109545 pass 
in 109565
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 109475
 test-amd64-i386-xl   19 guest-start/debian.repeat  fail pass in 109545
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start.2fail pass in 109545
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail pass in 
109545

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-start/win.repeat fail in 109475 
like 107358
 test-armhf-armhf-xl-rtds  6 xen-bootfail in 109545 like 107358
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail in 109545 like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail 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-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never 

Re: [Xen-devel] [PATCH 3/3] arm: fix build with gcc 7

[Stefano Stabellini]

On Thu, 18 May 2017, Julien Grall wrote:
> Hi,
> 
> On 18/05/17 09:41, Jan Beulich wrote:
> > The compiler dislikes duplicat "const", and the ones it complains about
> 
> s/duplicat/duplicate/
> 
> > look like they we in fact meant to be placed differently.
> > 
> > Also fix array_access_okay() (just like on x86), despite the construct
> > being unused on ARM: -Wint-in-bool-context, enabled by default in
> > gcc 7, doesn't like multiplication in conditional operators. "Hide" it,
> > at the risk of the next compiler version becoming smarter and
> > recognizing even that. (The hope is that added smartness then would
> > also better deal with legitimate cases like the one here.) The change
> > could have been done in access_ok(), but I think we better keep it at
> > the place the compiler is actually unhappy about.
> 
> I am wondering if we should drop array_access_ok and access_ok as they are not
> used.
> 
> Anyway, I am happy with both way:
> 
> Reviewed-by: Julien Grall 

Is this series for 4.9?

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

Re: [Xen-devel] [PATCH v3 for-4.9 0/3] libxl/devd: bugfixes

[Ian Jackson]

Julien Grall writes ("Re: [PATCH v3 for-4.9 0/3] libxl/devd: bugfixes"):
> On 17/05/17 15:02, Julien Grall wrote:
> > For the last patch, at this stage of the release I would prefer to defer
> > it for Xen 4.10.

After reviewing these, I'd like to make a case for the third patch for
4.9:

I haven't quite managed to prove to myself that the 3rd patch is a
no-op.  But this is because I haven't quite proved to myself that the
code _before_ the 3rd patch is correct.

The code _after_ the 3rd patch seems more obviously correct to me.  Ie
I think the risk of bugs is lower with the 3rd patch than without
(even after the first two patches).

Ian.

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

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

[Stefano Stabellini]

On Mon, 15 May 2017, Wei Liu wrote:
> On Sat, May 13, 2017 at 10:28:27AM +0800, Zhongze Liu wrote:
> > 2017-05-13 1:51 GMT+08:00 Wei Liu :
> > > Hi Zhongze
> > >
> > > This is a nice write-up. Some comments below. Feel free to disagree with
> > > what I say below, this is more a discussion than picking on your design
> > > or plan.
> > >
> > 
> > HI, Wei Liu
> > 
> > Thanks for your time reading through my proposal.
> > 
> > >
> > > On Sat, May 13, 2017 at 01:01:39AM +0800, Zhongze Liu wrote:
> > >> Hi, Xen developers,
> > >>
> > >> I'm Zhongze Liu, a GSoC student of this year. Glad to meet you in the
> > >> Xen Project.  As an initial step to implementing my GSoC proposal, which
> > >> is still a draft,  I'm posting it here. And hope to hear from you your
> > >> suggestions.
> > >>
> > >> 
> > >> 1. Motivation and Description
> > >> 
> > >> Virtual machines use grant table hypercalls to setup a share page for
> > >> inter-VMs communications. These hypercalls are used by all PV
> > >> protocols today. However, very simple guests, such as baremetal
> > >> applications, might not have the infrastructure to handle the grant 
> > >> table.
> > >> This project is about setting up several shared memory areas for 
> > >> inter-VMs
> > >> communications directly from the VM config file.
> > >> So that the guest kernel doesn't have to have grant table support to be
> > >> able to communicate with other guests.
> > >>
> > >> 
> > >> 2. Implementation Plan:
> > >> 
> > >>
> > >> ==
> > >> 2.1 Introduce a new VM config option in xl:
> > >> ==
> > >> The shared areas should be shareable among several VMs,
> > >> every shared physical memory area is assigned to a set of VMs.
> > >> Therefore, a “token” or “identifier” should be used here to uniquely
> > >> identify a backing memory area.
> > >>
> > >>
> > >> I would suggest using an unsigned integer to serve as the identifier.
> > >> For example:
> > >>
> > >> In xl config file of vm1:
> > >>
> > >> static_shared_mem = [“addr_range1= ID1”, “addr_range2 = ID2”]
> > >>
> > >> In xl config file of vm2:
> > >>
> > >> static_shared_mem = [“addr_range3 = ID1”]
> > >>
> > >> In xl config file of vm3:
> > >>
> > >> static_shared_mem = [“addr_range4 = ID2”]
> > >
> > > I can envisage you need some more attributes: what about the attributes
> > > like RW / RO / WO (or even X)?
> > >
> > > Also, I assume the granularity of the mapping is a page, but as far as I
> > > can tell there are two page granularity on ARM, you do need to consider
> > > both and what should happen if you mix and match them. What about
> > > mapping several pages and different VM use overlapping ranges?
> > >
> > > Can you give some concrete examples? What does addr_rangeX look like in
> > > practice?
> > >
> > >
> > 
> > Yes, those attributes are necessary and should be explicitly specified in 
> > the
> > config file. I'll add them in the next version of this proposal. And taking 
> > the
> > granularity into consideration, what do you say if we change the entries 
> > into
> > something like:
> > 'start=0xcafebabe, end=0xdeedbeef, granularity=4K, prot=RWX'.
> 
> I realised I may have gone too far after reading your reply.
> 
> What is the end purpose of this project? If you only want to insert a
> mfn into guest address space and don't care how the guest is going to
> map it, you can omit the prot= part. If you want stricter control, you
> will need them -- and that would also have implications on the
> hypervisor code you need.
> 
> I suggest you write the manual for the new mechanism you propose first.
> That way you describe the feature in a sysadmin-friendly way.  Describe
> the syntax, the effect of the new mechanism and how people are supposed
> to use it under what circumstances.

The memory sharing mechanism should enable guests to communicate with
each other using a shared ring. That implies that the memory needs to be
read-write, but I can imagine there are use cases for it to be read-only
too. I think it is a good idea to specify it.

However, I do not think we should ask Zhongze to write a protocol
specification for how these guests should communicate. That is out of
scope.


> > >> In the example above. A memory area A1 will be shared between
> > >> vm1 and vm2 -- vm1 can access this area using addr_range1
> > >> and vm2 using addr_range3. Likewise, a memory area A2 will be
> > >> shared between vm1 and vm3 -- vm1 can access A2 using addr_range2
> > >> and vm3 using addr_range4.
> > >>
> > >> The shared memory area denoted by an identifier IDx will be
> > >> allocated when it first appear, and the memory pages will be taken from
> > >> the first VM whose static_shared_mem list 

Re: [Xen-devel] [PATCH v3 for-4.9 3/3] libxl/devd: move the device allocation/removal code

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v3 for-4.9 3/3] libxl/devd: move the device 
allocation/removal code"):
> Move the device addition/removal code to the {add/remove}_device functions.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v1 08/10] iommu: Split iommu_hwdom_init() into arch specific parts

[Oleksandr Tyshchenko]

Hi, all.

On Thu, May 18, 2017 at 11:53 AM, Jan Beulich  wrote:
 On 17.05.17 at 22:30,  wrote:
>> On 05/17/2017 07:51 PM, Oleksandr Tyshchenko wrote:
>>> On Wed, May 17, 2017 at 7:01 PM, Jan Beulich  wrote:
 Well, if the ARM maintainers insist on baking their own thing every
 time we'd use the M2P if it was there, I think I can't reasonably
 block this patch. Otoh I'd prefer to not see the non-x86-specific
 code move to x86/, so perhaps the whole patch wants
 re-structuring using either a manifest definition in the ARM headers
 or e.g. CONFIG_M2P (which x86 would select, but ARM wouldn't).
>>> Jan, I am afraid but I didn't get what you meant here:
>>> "manifest definition in the ARM headers"
>>
>> I think he meant to have either a define in the header mentioning the
>> absence/presence of M2P.
>
> Yes, at least in a way.
>
>> But my preference would be using the Kconfig here.
>
> Depends on the symbol used: If such a symbol solely _indicates_
> the presence, Kconfig would be better indeed. If, however, the
> symbol is e.g. a macro resolving to a per-arch implementation,
> with common code providing a default definition when the arch
> doesn't provide any, then the non-Kconfig variant may be
> preferable.
>
> Jan
>

Thank you for your comments.
I have already posted a common comment regarding several patches in
the current series
as they are interrelated (please see patch #6), but I duplicate here
only related to this patch part.

...
patch #8: As we always allocate the page table for hardware domain,
this patch should be reworked.
The use_iommu flag should be set for both archs in case of hardware
domain. Having d->need_iommu set at the early stage we won't skip
IOMMU mapping updates anymore. And as the result the existing in
iommu_hwdom_init() code that goes through the list of page and tries
to retrieve mapping could be just dropped
instead of moving it to the arch-specific part.
...

Does the described above make sense?

-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH v3 for-4.9 1/3] libxl/devd: fix a race with concurrent device addition/removal

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v3 for-4.9 1/3] libxl/devd: fix a race with 
concurrent device addition/removal"):
> Current code can free the libxl__device inside of the libxl__ddomain_device
> before the addition has finished if a removal happens while an addition is
> still in process:

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v3 for-4.9 2/3] libxl/devd: correctly manipulate the dguest list

[Ian Jackson]

Roger Pau Monne writes ("[PATCH v3 for-4.9 2/3] libxl/devd: correctly 
manipulate the dguest list"):
> Current code in backend_watch_callback has two issues when manipulating the
> dguest list:

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH v1 06/10] iommu: Add extra use_iommu argument to iommu_domain_init()

[Oleksandr Tyshchenko]

Hi, all.

On Thu, May 18, 2017 at 11:38 AM, Jan Beulich  wrote:
 On 17.05.17 at 21:52,  wrote:
>> On 05/12/2017 03:31 PM, Jan Beulich wrote:
>> On 10.05.17 at 16:03,  wrote:
 From: Oleksandr Tyshchenko 

 The presence of this flag lets us know that the guest
 has devices which will most likely be used for passthrough
 and as the result the use of IOMMU is expected for this domain.
 In that case we have to call iommu_construct(), actually
 what the real assign_device call usually does.

 As iommu_domain_init() is called with use_iommu flag being forced
 to false for now, no functional change is intended for both ARM and x86.

 Basically, this patch is needed for non-shared IOMMUs on ARM only
 since the non-shared IOMMUs on x86 are ok if iommu_construct() is called
 later. But, in order to be more generic and for possible future 
 optimization
 make this change appliable for both platforms.
>>>
>>> I continue to be unconvinced that this is wanted / needed, as I
>>> continue to not see why shared vs unshared really matters here.
>>> After all we have both modes working on x86 without this flag.
>>
>> Well on x86 you allocate the page table on the fly in the unsharing
>> case. This is only useful if you don't know whether a domain will have
>> device assigned (e.g hotplug case).
>>
>> When you know that the domain will have device pass-throughed, you can
>> populate the IOMMU page tables before hand avoiding to have to go
>> through the list of page at the first assigned device.
>>
>> In embedded platform hotplug is likely to be inexistent. For servers, I
>> don't know but likely page tables are going to be shared (or as I
>> mentioned earlier partially shared).
>>
>> So I don't see any benefit of the current code over populating the IOMMU
>> page tables from the beginning.
>
> Interesting. To me, the primary benefit is that we wouldn't need to
> introduce new code to handle yet another case specially. Anyway,
> the changes in this patch are simple enough, so I don't mean to
> block it despite being unconvinced of the basic idea.

Thank you for your comments.
I would like to say that I share Julien's opinion, but understand
Jan's points too.
I think some mutually agreeable solution should be worked out.

It is not completely clear to me what I have to do with patches #6-#8.
So, I will try to summarize thoughts regarding them. Please, correct
me if I am wrong.

patch #6: As for the current patch, likely the "init" platform
callback should be extended with
extra "use_iommu" argument as well as the "iommu_domain_init" API. In
that case we
would just pass thought incoming flag to the IOMMU drivers followed by
updating "need_iommu" domain flag.

Something like this:
...
int iommu_domain_init(struct domain *d, bool use_iommu)
{
struct domain_iommu *hd = dom_iommu(d);
int ret = 0;

ret = arch_iommu_domain_init(d);
if ( ret )
return ret;

if ( !iommu_enabled )
return 0;

hd->platform_ops = iommu_get_ops();
ret = hd->platform_ops->init(d, use_iommu);
if ( ret )
return ret;

d->need_iommu = !!use_iommu;

return 0;
}
...

patch #7: This patch should be just dropped.

patch #8: As we always allocate the page table for hardware domain,
this patch should be reworked.
The use_iommu flag should be set for both archs in case of hardware
domain. Having d->need_iommu set at the early stage we won't skip
IOMMU
mapping updates anymore. And as the result the existing in
iommu_hwdom_init() code that goes through the list of page and tries
to retrieve mapping could be just dropped
instead of moving it to the arch-specific part.

So, what we would have as the final result:
1. In case of hardware domain "use_iommu" flag is always set for both
ARM and x86.
2. For other domains the "use_iommu" flag is always unset for x86
only, but the real value is passed for ARM
according to the libxl expectation about IOMMU usage.
This would allow us to allocate the page table in advance on ARM and
retain the current behavior for x86 (allocating the page table
on-demand).

What do you think?

>
> Jan
>

-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH] Use non-debug build for Xen 4.9

[Ian Jackson]

Julien Grall writes ("[PATCH] Use non-debug build for Xen 4.9"):
> Modify Config.mk and Kconfig.debug to disable debug by default in
> preparation for late RCs and eventual release.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [xen-unstable-smoke test] 109547: tolerable trouble: broken/pass - PUSHED

[Ian Jackson]

Ian Jackson writes ("Re: [Xen-devel] [xen-unstable-smoke test] 109547: 
tolerable trouble: broken/pass - PUSHED"):
> However, currently, with only two arm64 boxes, I don't think we have
> enough bandwidth to add this to the smoke tests.  I have put a note in
> my backlog to revisit this when we have more arm64 hardware.

FTR, for now I am considering this:

16:04  A better plan might be to simply reduce the proportion of cells 
   in the test matrix that get tested for arm64
16:05  Eg drop non -multivcpu and -rtds and maybe -libvirt-qcow2 and 
   -libvirt (leaving -libvirt-xsm)
16:18  Diziet: I would be ok with that.

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

Re: [Xen-devel] [PATCH] xen: make xen_flush_tlb_all() static

[Boris Ostrovsky]

On 05/18/2017 11:46 AM, Juergen Gross wrote:
> xen_flush_tlb_all() is used in arch/x86/xen/mmu.c only. Make it static.
>
> 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 for-next v3 01/22] x86/traps: move privilege instruction emulation code

[Wei Liu]

I forgot to move gpr_switch.S. Here is an updated version.

---8<---
From 58df816b937dc7a3598de01f053a6030e631057e Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Thu, 18 May 2017 16:18:56 +0100
Subject: [PATCH] x86/traps: move privilege instruction emulation code

Move relevant code to pv/emulate.c. Export emulate_privileged_op in
pv/traps.h.

Note that read_descriptor is duplicated in emulate.c. The duplication
will be gone once all emulation code is moved.

Also move gpr_switch.S to pv/ because the code in that file is only
used by privilege instruction emulation.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile |2 +
 xen/arch/x86/pv/emulate.c| 1470 ++
 xen/arch/x86/{x86_64 => pv}/gpr_switch.S |0
 xen/arch/x86/traps.c | 1358 +--
 xen/arch/x86/x86_64/Makefile |1 -
 xen/include/asm-x86/pv/traps.h   |   48 +
 6 files changed, 1522 insertions(+), 1357 deletions(-)
 create mode 100644 xen/arch/x86/pv/emulate.c
 rename xen/arch/x86/{x86_64 => pv}/gpr_switch.S (100%)
 create mode 100644 xen/include/asm-x86/pv/traps.h

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 489a9f59cb..f272f607d4 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -3,3 +3,5 @@ obj-y += traps.o
 
 obj-bin-y += dom0_build.init.o
 obj-y += domain.o
+obj-y += emulate.o
+obj-bin-y += gpr_switch.o
diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
new file mode 100644
index 00..fb0d066a3b
--- /dev/null
+++ b/xen/arch/x86/pv/emulate.c
@@ -0,0 +1,1470 @@
+/**
+ * arch/x86/pv/emulate.c
+ *
+ * PV emulation code
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../x86_64/mmconfig.h"
+
+/**
+ * Helper functions
+ */
+
+static int read_descriptor(unsigned int sel,
+   const struct vcpu *v,
+   unsigned long *base,
+   unsigned long *limit,
+   unsigned int *ar,
+   bool_t insn_fetch)
+{
+struct desc_struct desc;
+
+if ( sel < 4)
+desc.b = desc.a = 0;
+else if ( __get_user(desc,
+ (const struct desc_struct *)(!(sel & 4)
+  ? GDT_VIRT_START(v)
+  : LDT_VIRT_START(v))
+ + (sel >> 3)) )
+return 0;
+if ( !insn_fetch )
+desc.b &= ~_SEGMENT_L;
+
+*ar = desc.b & 0x00f0ff00;
+if ( !(desc.b & _SEGMENT_L) )
+{
+*base = ((desc.a >> 16) + ((desc.b & 0xff) << 16) +
+ (desc.b & 0xff00));
+*limit = (desc.a & 0x) | (desc.b & 0x000f);
+if ( desc.b & _SEGMENT_G )
+*limit = ((*limit + 1) << 12) - 1;
+#ifndef NDEBUG
+if ( sel > 3 )
+{
+unsigned int a, l;
+unsigned char valid;
+
+asm volatile (
+"larl %2,%0 ; setz %1"
+: "=r" (a), "=qm" (valid) : "rm" (sel));
+BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
+asm volatile (
+"lsll %2,%0 ; setz %1"
+: "=r" (l), "=qm" (valid) : "rm" (sel));
+BUG_ON(valid && (l != *limit));
+}
+#endif
+}
+else
+{
+*base = 0UL;
+*limit = ~0UL;
+}
+
+return 1;
+}
+
+/***
+ * I/O emulation support
+ */
+
+struct priv_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+char *io_emul_stub;
+unsigned int bpmatch;
+unsigned int tsc;
+#define TSC_BASE 1
+#define TSC_AUX 2
+};
+
+/* I/O emulation support. Helper routines for, and type of, the stack stub.*/
+void host_to_guest_gpr_switch(struct cpu_user_regs *);
+unsigned long 

Re: [Xen-devel] [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

[Tamas K Lengyel]

On Thu, May 18, 2017 at 9:07 AM, Adrian Pop  wrote:
> Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
> domain to change the value of the #VE suppress bit for a page.
>
> Signed-off-by: Adrian Pop 
> ---
>  xen/arch/x86/hvm/hvm.c  | 14 
>  xen/arch/x86/mm/mem_access.c| 48 
> +
>  xen/include/public/hvm/hvm_op.h | 15 +
>  xen/include/xen/mem_access.h|  3 +++
>  4 files changed, 80 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 2e76c2345b..eb01527c5b 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4356,6 +4356,7 @@ static int do_altp2m_op(
>  case HVMOP_altp2m_destroy_p2m:
>  case HVMOP_altp2m_switch_p2m:
>  case HVMOP_altp2m_set_mem_access:
> +case HVMOP_altp2m_set_suppress_ve:
>  case HVMOP_altp2m_change_gfn:
>  break;
>  default:
> @@ -4472,6 +4473,19 @@ static int do_altp2m_op(
>  a.u.set_mem_access.view);
>  break;
>
> +case HVMOP_altp2m_set_suppress_ve:
> +if ( a.u.set_suppress_ve.pad1 || a.u.set_suppress_ve.pad2 )
> +rc = -EINVAL;
> +else
> +{
> +gfn_t gfn = _gfn(a.u.set_mem_access.gfn);
> +unsigned int altp2m_idx = a.u.set_mem_access.view;
> +uint8_t suppress_ve = a.u.set_suppress_ve.suppress_ve;
> +
> +rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);
> +}
> +break;
> +
>  case HVMOP_altp2m_change_gfn:
>  if ( a.u.change_gfn.pad1 || a.u.change_gfn.pad2 )
>  rc = -EINVAL;
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index d0b0767855..b9e611d3db 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -466,6 +466,54 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn, 
> xenmem_access_t *access)
>  }
>
>  /*
> + * Set/clear the #VE suppress bit for a page.  Only available on VMX.
> + */
> +int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, uint8_t suppress_ve,
> +unsigned int altp2m_idx)
> +{
> +struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
> +struct p2m_domain *ap2m = NULL;
> +struct p2m_domain *p2m = NULL;
> +mfn_t mfn;
> +p2m_access_t a;
> +p2m_type_t t;
> +unsigned long gfn_l;
> +int rc = 0;
> +
> +if ( !cpu_has_vmx )
> +return -EOPNOTSUPP;
> +
> +if ( altp2m_idx > 0 )
> +{
> +if ( altp2m_idx >= MAX_ALTP2M ||
> +d->arch.altp2m_eptp[altp2m_idx] == mfn_x(INVALID_MFN) )
> +return -EINVAL;
> +
> +p2m = ap2m = d->arch.altp2m_p2m[altp2m_idx];
> +}
> +else
> +{
> +p2m = host_p2m;
> +}


IMHO there should be some further checks here to verify that the
domain has issued HVMOP_altp2m_vcpu_enable_notify before and that it
was allowed (ie. this hypercall should not be able to enable the
suppress_bit if there is no veinfo_gfn). That said, is there anything
that would prevent a malicious application issuing rouge altp2m HVMOPs
from messing with this if it is activated (which I guess stands for
the rest of the altp2m ops too)?

> +
> +p2m_lock(host_p2m);
> +if ( ap2m )
> +p2m_lock(ap2m);
> +
> +gfn_l = gfn_x(gfn);
> +mfn = p2m->get_entry(p2m, gfn_l, , , 0, NULL, NULL);
> +if ( !mfn_valid(mfn) )
> +return -ESRCH;
> +rc = p2m->set_entry(p2m, gfn_l, mfn, PAGE_ORDER_4K, t, a,
> +suppress_ve);
> +if ( ap2m )
> +p2m_unlock(ap2m);
> +p2m_unlock(host_p2m);
> +
> +return rc;
> +}
> +
> +/*
>   * Local variables:
>   * mode: C
>   * c-file-style: "BSD"
> diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
> index bc00ef0e65..9736092f58 100644
> --- a/xen/include/public/hvm/hvm_op.h
> +++ b/xen/include/public/hvm/hvm_op.h
> @@ -231,6 +231,18 @@ struct xen_hvm_altp2m_set_mem_access {
>  typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
>
> +struct xen_hvm_altp2m_set_suppress_ve {
> +/* view */
> +uint16_t view;
> +uint8_t suppress_ve;
> +uint8_t pad1;
> +uint32_t pad2;
> +/* gfn */
> +uint64_t gfn;
> +};
> +typedef struct xen_hvm_altp2m_set_suppress_ve 
> xen_hvm_altp2m_set_suppress_ve_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_suppress_ve_t);
> +
>  struct xen_hvm_altp2m_change_gfn {
>  /* view */
>  uint16_t view;
> @@ -262,6 +274,8 @@ struct xen_hvm_altp2m_op {
>  #define HVMOP_altp2m_set_mem_access   7
>  /* Change a p2m entry to have a different gfn->mfn mapping */
>  #define HVMOP_altp2m_change_gfn   8
> +/* Set the "Suppress #VE" bit on a page */
> +#define HVMOP_altp2m_set_suppress_ve  9
>  domid_t domain;
>  uint16_t pad1;
> 

Re: [Xen-devel] Livepatching and Xen Security

[Lars Kurth]

On 18/05/2017 17:53, "Ian Jackson"  wrote:

>George Dunlap writes ("Livepatching and Xen Security"):
>> # Executive summary
>
>I am completely in agreement with your analysis and your conclusions.

Me too. I am not sure though whether we need a vote or lazy consensus.

For Credit2 (see 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg00171.html)
 we used a code patch removing Experimental from KCONFIG, which implicitly
led to active confirmation by project leadership members via Acked-by
tags. In other words, we executed the equivalent of a vote.

From a process perspective
https://xenproject.org/governance.html#lazyconsensus should be sufficient
because we are applying a process, not changing one. In addition lazy
consensus decisions can only be overturned if the project leadership
agrees collectively to do so, because the decision is too important for
lazy consensus. As every leadership member is on the list, there would be
ample opportunity to raise objections.

My gut feeling though is that Leadership Team members and Security Team
members should probably actively agree/disagree to proposals related to
whether a feature is supported and thus security supported to avoid any
future issues. George already expressed an implicit +1 (by making the
proposal) and Ian an explicit +1.

Regards
Lars

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

[Xen-devel] [PATCH for-next v3 16/22] x86/traps: move callback_op code

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 148 +++
 xen/arch/x86/x86_64/traps.c | 149 
 2 files changed, 148 insertions(+), 149 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index cb9b3b1425..7cdec77618 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -31,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 void do_entry_int82(struct cpu_user_regs *regs)
 {
 if ( unlikely(untrusted_msi) )
@@ -432,6 +434,152 @@ void init_int80_direct_trap(struct vcpu *v)
 tb->flags = TBF_EXCEPTION | (TI_GET_IF(ti) ? TBF_INTERRUPT : 0);
 }
 
+static long register_guest_callback(struct callback_register *reg)
+{
+long ret = 0;
+struct vcpu *v = current;
+
+if ( !is_canonical_address(reg->address) )
+return -EINVAL;
+
+switch ( reg->type )
+{
+case CALLBACKTYPE_event:
+v->arch.pv_vcpu.event_callback_eip= reg->address;
+break;
+
+case CALLBACKTYPE_failsafe:
+v->arch.pv_vcpu.failsafe_callback_eip = reg->address;
+if ( reg->flags & CALLBACKF_mask_events )
+set_bit(_VGCF_failsafe_disables_events,
+>arch.vgc_flags);
+else
+clear_bit(_VGCF_failsafe_disables_events,
+  >arch.vgc_flags);
+break;
+
+case CALLBACKTYPE_syscall:
+v->arch.pv_vcpu.syscall_callback_eip  = reg->address;
+if ( reg->flags & CALLBACKF_mask_events )
+set_bit(_VGCF_syscall_disables_events,
+>arch.vgc_flags);
+else
+clear_bit(_VGCF_syscall_disables_events,
+  >arch.vgc_flags);
+break;
+
+case CALLBACKTYPE_syscall32:
+v->arch.pv_vcpu.syscall32_callback_eip = reg->address;
+v->arch.pv_vcpu.syscall32_disables_events =
+!!(reg->flags & CALLBACKF_mask_events);
+break;
+
+case CALLBACKTYPE_sysenter:
+v->arch.pv_vcpu.sysenter_callback_eip = reg->address;
+v->arch.pv_vcpu.sysenter_disables_events =
+!!(reg->flags & CALLBACKF_mask_events);
+break;
+
+case CALLBACKTYPE_nmi:
+ret = register_guest_nmi_callback(reg->address);
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+static long unregister_guest_callback(struct callback_unregister *unreg)
+{
+long ret;
+
+switch ( unreg->type )
+{
+case CALLBACKTYPE_event:
+case CALLBACKTYPE_failsafe:
+case CALLBACKTYPE_syscall:
+case CALLBACKTYPE_syscall32:
+case CALLBACKTYPE_sysenter:
+ret = -EINVAL;
+break;
+
+case CALLBACKTYPE_nmi:
+ret = unregister_guest_nmi_callback();
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+long do_callback_op(int cmd, XEN_GUEST_HANDLE_PARAM(const_void) arg)
+{
+long ret;
+
+switch ( cmd )
+{
+case CALLBACKOP_register:
+{
+struct callback_register reg;
+
+ret = -EFAULT;
+if ( copy_from_guest(, arg, 1) )
+break;
+
+ret = register_guest_callback();
+}
+break;
+
+case CALLBACKOP_unregister:
+{
+struct callback_unregister unreg;
+
+ret = -EFAULT;
+if ( copy_from_guest(, arg, 1) )
+break;
+
+ret = unregister_guest_callback();
+}
+break;
+
+default:
+ret = -ENOSYS;
+break;
+}
+
+return ret;
+}
+
+long do_set_callbacks(unsigned long event_address,
+  unsigned long failsafe_address,
+  unsigned long syscall_address)
+{
+struct callback_register event = {
+.type = CALLBACKTYPE_event,
+.address = event_address,
+};
+struct callback_register failsafe = {
+.type = CALLBACKTYPE_failsafe,
+.address = failsafe_address,
+};
+struct callback_register syscall = {
+.type = CALLBACKTYPE_syscall,
+.address = syscall_address,
+};
+
+register_guest_callback();
+register_guest_callback();
+register_guest_callback();
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index a4ea09b1ac..db2037509e 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -23,8 +23,6 @@
 #include 
 #include 
 #include 
-#include 
-
 
 static void print_xen_info(void)
 {
@@ -336,153 +334,6 @@ void subarch_percpu_traps_init(void)
 wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
 }
 
-static long register_guest_callback(struct callback_register *reg)
-{
-long ret = 0;
-struct vcpu *v = current;
-
-if ( !is_canonical_address(reg->address) )
-return -EINVAL;
-
-switch ( reg->type )
-{
-case CALLBACKTYPE_event:
-

[Xen-devel] [PATCH for-next v3 17/22] x86/traps: move hypercall_page_initialise_ring3_kernel

[Wei Liu]

And export it via pv/domain.h.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 36 
 xen/arch/x86/x86_64/traps.c | 37 +
 xen/include/asm-x86/pv/domain.h |  5 +
 3 files changed, 42 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 7cdec77618..4f52d3e4d3 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -580,6 +580,42 @@ long do_set_callbacks(unsigned long event_address,
 return 0;
 }
 
+void hypercall_page_initialise_ring3_kernel(void *hypercall_page)
+{
+char *p;
+int i;
+
+/* Fill in all the transfer points with template machine code. */
+for ( i = 0; i < (PAGE_SIZE / 32); i++ )
+{
+if ( i == __HYPERVISOR_iret )
+continue;
+
+p = (char *)(hypercall_page + (i * 32));
+*(u8  *)(p+ 0) = 0x51;/* push %rcx */
+*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
+*(u8  *)(p+ 3) = 0xb8;/* mov  $,%eax */
+*(u32 *)(p+ 4) = i;
+*(u16 *)(p+ 8) = 0x050f;  /* syscall */
+*(u16 *)(p+10) = 0x5b41;  /* pop  %r11 */
+*(u8  *)(p+12) = 0x59;/* pop  %rcx */
+*(u8  *)(p+13) = 0xc3;/* ret */
+}
+
+/*
+ * HYPERVISOR_iret is special because it doesn't return and expects a
+ * special stack frame. Guests jump at this transfer point instead of
+ * calling it.
+ */
+p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
+*(u8  *)(p+ 0) = 0x51;/* push %rcx */
+*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
+*(u8  *)(p+ 3) = 0x50;/* push %rax */
+*(u8  *)(p+ 4) = 0xb8;/* mov  $__HYPERVISOR_iret,%eax */
+*(u32 *)(p+ 5) = __HYPERVISOR_iret;
+*(u16 *)(p+ 9) = 0x050f;  /* syscall */
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index db2037509e..7a4dd4458e 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void print_xen_info(void)
 {
@@ -334,42 +335,6 @@ void subarch_percpu_traps_init(void)
 wrmsrl(MSR_SYSCALL_MASK, XEN_SYSCALL_MASK);
 }
 
-static void hypercall_page_initialise_ring3_kernel(void *hypercall_page)
-{
-char *p;
-int i;
-
-/* Fill in all the transfer points with template machine code. */
-for ( i = 0; i < (PAGE_SIZE / 32); i++ )
-{
-if ( i == __HYPERVISOR_iret )
-continue;
-
-p = (char *)(hypercall_page + (i * 32));
-*(u8  *)(p+ 0) = 0x51;/* push %rcx */
-*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
-*(u8  *)(p+ 3) = 0xb8;/* mov  $,%eax */
-*(u32 *)(p+ 4) = i;
-*(u16 *)(p+ 8) = 0x050f;  /* syscall */
-*(u16 *)(p+10) = 0x5b41;  /* pop  %r11 */
-*(u8  *)(p+12) = 0x59;/* pop  %rcx */
-*(u8  *)(p+13) = 0xc3;/* ret */
-}
-
-/*
- * HYPERVISOR_iret is special because it doesn't return and expects a
- * special stack frame. Guests jump at this transfer point instead of
- * calling it.
- */
-p = (char *)(hypercall_page + (__HYPERVISOR_iret * 32));
-*(u8  *)(p+ 0) = 0x51;/* push %rcx */
-*(u16 *)(p+ 1) = 0x5341;  /* push %r11 */
-*(u8  *)(p+ 3) = 0x50;/* push %rax */
-*(u8  *)(p+ 4) = 0xb8;/* mov  $__HYPERVISOR_iret,%eax */
-*(u32 *)(p+ 5) = __HYPERVISOR_iret;
-*(u16 *)(p+ 9) = 0x050f;  /* syscall */
-}
-
 #include "compat/traps.c"
 
 void hypercall_page_initialise(struct domain *d, void *hypercall_page)
diff --git a/xen/include/asm-x86/pv/domain.h b/xen/include/asm-x86/pv/domain.h
index acdf140fbd..dfa60b080c 100644
--- a/xen/include/asm-x86/pv/domain.h
+++ b/xen/include/asm-x86/pv/domain.h
@@ -29,6 +29,8 @@ void pv_domain_destroy(struct domain *d);
 int pv_domain_initialise(struct domain *d, unsigned int domcr_flags,
  struct xen_arch_domainconfig *config);
 
+void hypercall_page_initialise_ring3_kernel(void *hypercall_page);
+
 #else  /* !CONFIG_PV */
 
 #include 
@@ -42,6 +44,9 @@ static inline int pv_domain_initialise(struct domain *d,
 {
 return -EOPNOTSUPP;
 }
+
+void hypercall_page_initialise_ring3_kernel(void *hypercall_page) {}
+
 #endif /* CONFIG_PV */
 
 void paravirt_ctxt_switch_from(struct vcpu *v);
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 11/22] x86/traps: move guest_has_trap_callback to pv/traps.c

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 18 ++
 xen/arch/x86/traps.c| 18 --
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index ff7dd1905f..6876150969 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -264,6 +264,24 @@ long unregister_guest_nmi_callback(void)
 return 0;
 }
 
+int guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
+unsigned int trap_nr)
+{
+struct vcpu *v;
+struct trap_info *t;
+
+BUG_ON(d == NULL);
+BUG_ON(vcpuid >= d->max_vcpus);
+
+/* Sanity check - XXX should be more fine grained. */
+BUG_ON(trap_nr >= NR_VECTORS);
+
+v = d->vcpu[vcpuid];
+t = >arch.pv_vcpu.trap_ctxt[trap_nr];
+
+return (t->address != 0);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index a26b002173..2a4dc159cf 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1910,24 +1910,6 @@ void __init trap_init(void)
 open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
-int guest_has_trap_callback(struct domain *d, uint16_t vcpuid, unsigned int 
trap_nr)
-{
-struct vcpu *v;
-struct trap_info *t;
-
-BUG_ON(d == NULL);
-BUG_ON(vcpuid >= d->max_vcpus);
-
-/* Sanity check - XXX should be more fine grained. */
-BUG_ON(trap_nr >= NR_VECTORS);
-
-v = d->vcpu[vcpuid];
-t = >arch.pv_vcpu.trap_ctxt[trap_nr];
-
-return (t->address != 0);
-}
-
-
 int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
 {
 struct vcpu *v;
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 18/22] x86/traps: merge x86_64/compat/traps.c into pv/traps.c

[Wei Liu]

Export hypercall_page_initialise_ring1_kernel as the code is moved.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c| 405 
 xen/arch/x86/x86_64/compat/traps.c | 416 -
 xen/arch/x86/x86_64/traps.c|   2 -
 xen/include/asm-x86/pv/domain.h|   2 +
 4 files changed, 407 insertions(+), 418 deletions(-)
 delete mode 100644 xen/arch/x86/x86_64/compat/traps.c

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 4f52d3e4d3..db92f6d520 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -31,6 +31,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 #include 
 
 void do_entry_int82(struct cpu_user_regs *regs)
@@ -616,6 +619,408 @@ void hypercall_page_initialise_ring3_kernel(void 
*hypercall_page)
 *(u16 *)(p+ 9) = 0x050f;  /* syscall */
 }
 
+/* Compat guest interfaces */
+
+void compat_show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs,
+ int debug_stack_lines)
+{
+unsigned int i, *stack, addr, mask = STACK_SIZE;
+
+stack = (unsigned int *)(unsigned long)regs->esp;
+printk("Guest stack trace from esp=%08lx:\n ", (unsigned long)stack);
+
+if ( !__compat_access_ok(v->domain, stack, sizeof(*stack)) )
+{
+printk("Guest-inaccessible memory.\n");
+return;
+}
+
+if ( v != current )
+{
+struct vcpu *vcpu;
+unsigned long mfn;
+
+ASSERT(guest_kernel_mode(v, regs));
+mfn = read_cr3() >> PAGE_SHIFT;
+for_each_vcpu( v->domain, vcpu )
+if ( pagetable_get_pfn(vcpu->arch.guest_table) == mfn )
+break;
+if ( !vcpu )
+{
+stack = do_page_walk(v, (unsigned long)stack);
+if ( (unsigned long)stack < PAGE_SIZE )
+{
+printk("Inaccessible guest memory.\n");
+return;
+}
+mask = PAGE_SIZE;
+}
+}
+
+for ( i = 0; i < debug_stack_lines * 8; i++ )
+{
+if ( (((long)stack - 1) ^ ((long)(stack + 1) - 1)) & mask )
+break;
+if ( __get_user(addr, stack) )
+{
+if ( i != 0 )
+printk("\n");
+printk("Fault while accessing guest memory.");
+i = 1;
+break;
+}
+if ( (i != 0) && ((i % 8) == 0) )
+printk("\n ");
+printk(" %08x", addr);
+stack++;
+}
+if ( mask == PAGE_SIZE )
+{
+BUILD_BUG_ON(PAGE_SIZE == STACK_SIZE);
+unmap_domain_page(stack);
+}
+if ( i == 0 )
+printk("Stack empty.");
+printk("\n");
+}
+
+unsigned int compat_iret(void)
+{
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct vcpu *v = current;
+u32 eflags;
+
+/* Trim stack pointer to 32 bits. */
+regs->rsp = (u32)regs->rsp;
+
+/* Restore EAX (clobbered by hypercall). */
+if ( unlikely(__get_user(regs->eax, (u32 *)regs->rsp)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+/* Restore CS and EIP. */
+if ( unlikely(__get_user(regs->eip, (u32 *)regs->rsp + 1)) ||
+unlikely(__get_user(regs->cs, (u32 *)regs->rsp + 2)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+/*
+ * Fix up and restore EFLAGS. We fix up in a local staging area
+ * to avoid firing the BUG_ON(IOPL) check in arch_get_info_guest.
+ */
+if ( unlikely(__get_user(eflags, (u32 *)regs->rsp + 3)) )
+{
+domain_crash(v->domain);
+return 0;
+}
+
+if ( VM_ASSIST(v->domain, architectural_iopl) )
+v->arch.pv_vcpu.iopl = eflags & X86_EFLAGS_IOPL;
+
+regs->eflags = (eflags & ~X86_EFLAGS_IOPL) | X86_EFLAGS_IF;
+
+if ( unlikely(eflags & X86_EFLAGS_VM) )
+{
+/*
+ * Cannot return to VM86 mode: inject a GP fault instead. Note that
+ * the GP fault is reported on the first VM86 mode instruction, not on
+ * the IRET (which is why we can simply leave the stack frame as-is
+ * (except for perhaps having to copy it), which in turn seems better
+ * than teaching create_bounce_frame() to needlessly deal with vm86
+ * mode frames).
+ */
+const struct trap_info *ti;
+u32 x, ksp = v->arch.pv_vcpu.kernel_sp - 40;
+unsigned int i;
+int rc = 0;
+
+gdprintk(XENLOG_ERR, "VM86 mode unavailable (ksp:%08X->%08X)\n",
+ regs->esp, ksp);
+if ( ksp < regs->esp )
+{
+for (i = 1; i < 10; ++i)
+{
+rc |= __get_user(x, (u32 *)regs->rsp + i);
+rc |= __put_user(x, (u32 *)(unsigned long)ksp + i);
+}
+}
+else if ( ksp > regs->esp )
+{
+for ( i = 9; i > 0; --i )
+{
+rc |= __get_user(x, (u32 *)regs->rsp 

[Xen-devel] [PATCH for-next v3 12/22] x86/traps: move send_guest_trap to pv/traps.c

[Wei Liu]

Fixed some coding style issues while moving.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 50 +
 xen/arch/x86/traps.c| 47 --
 2 files changed, 50 insertions(+), 47 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 6876150969..7c841e04cc 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -282,6 +282,56 @@ int guest_has_trap_callback(struct domain *d, uint16_t 
vcpuid,
 return (t->address != 0);
 }
 
+int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
+{
+struct vcpu *v;
+struct softirq_trap *st = _cpu(softirq_trap, smp_processor_id());
+
+BUG_ON(d == NULL);
+BUG_ON(vcpuid >= d->max_vcpus);
+v = d->vcpu[vcpuid];
+
+switch (trap_nr)
+{
+case TRAP_nmi:
+if ( cmpxchgptr(>vcpu, NULL, v) )
+return -EBUSY;
+if ( !test_and_set_bool(v->nmi_pending) )
+{
+   st->domain = d;
+   st->processor = v->processor;
+
+   /* not safe to wake up a vcpu here */
+   raise_softirq(NMI_MCE_SOFTIRQ);
+   return 0;
+}
+st->vcpu = NULL;
+break;
+
+case TRAP_machine_check:
+if ( cmpxchgptr(>vcpu, NULL, v) )
+return -EBUSY;
+
+/* We are called by the machine check (exception or polling) handlers
+ * on the physical CPU that reported a machine check error. */
+
+if ( !test_and_set_bool(v->mce_pending) )
+{
+st->domain = d;
+st->processor = v->processor;
+
+/* not safe to wake up a vcpu here */
+raise_softirq(NMI_MCE_SOFTIRQ);
+return 0;
+}
+st->vcpu = NULL;
+break;
+}
+
+/* delivery failed */
+return -EIO;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 2a4dc159cf..3cc4b5b78b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1910,53 +1910,6 @@ void __init trap_init(void)
 open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
-int send_guest_trap(struct domain *d, uint16_t vcpuid, unsigned int trap_nr)
-{
-struct vcpu *v;
-struct softirq_trap *st = _cpu(softirq_trap, smp_processor_id());
-
-BUG_ON(d == NULL);
-BUG_ON(vcpuid >= d->max_vcpus);
-v = d->vcpu[vcpuid];
-
-switch (trap_nr) {
-case TRAP_nmi:
-if ( cmpxchgptr(>vcpu, NULL, v) )
-return -EBUSY;
-if ( !test_and_set_bool(v->nmi_pending) ) {
-   st->domain = d;
-   st->processor = v->processor;
-
-   /* not safe to wake up a vcpu here */
-   raise_softirq(NMI_MCE_SOFTIRQ);
-   return 0;
-}
-st->vcpu = NULL;
-break;
-
-case TRAP_machine_check:
-if ( cmpxchgptr(>vcpu, NULL, v) )
-return -EBUSY;
-
-/* We are called by the machine check (exception or polling) handlers
- * on the physical CPU that reported a machine check error. */
-
-if ( !test_and_set_bool(v->mce_pending) ) {
-st->domain = d;
-st->processor = v->processor;
-
-/* not safe to wake up a vcpu here */
-raise_softirq(NMI_MCE_SOFTIRQ);
-return 0;
-}
-st->vcpu = NULL;
-break;
-}
-
-/* delivery failed */
-return -EIO;
-}
-
 void activate_debugregs(const struct vcpu *curr)
 {
 ASSERT(curr == current);
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 14/22] x86/traps: move do_iret to pv/traps.c

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 56 +
 xen/arch/x86/x86_64/traps.c | 56 -
 2 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 5b84a617e6..b69990c6b7 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -362,6 +362,62 @@ void toggle_guest_mode(struct vcpu *v)
 v->arch.pv_vcpu.pending_system_time.version = 0;
 }
 
+unsigned long do_iret(void)
+{
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct iret_context iret_saved;
+struct vcpu *v = current;
+
+if ( unlikely(copy_from_user(_saved, (void *)regs->rsp,
+ sizeof(iret_saved))) )
+{
+gprintk(XENLOG_ERR,
+"Fault while reading IRET context from guest stack\n");
+goto exit_and_crash;
+}
+
+/* Returning to user mode? */
+if ( (iret_saved.cs & 3) == 3 )
+{
+if ( unlikely(pagetable_is_null(v->arch.guest_table_user)) )
+{
+gprintk(XENLOG_ERR,
+"Guest switching to user mode with no user page tables\n");
+goto exit_and_crash;
+}
+toggle_guest_mode(v);
+}
+
+if ( VM_ASSIST(v->domain, architectural_iopl) )
+v->arch.pv_vcpu.iopl = iret_saved.rflags & X86_EFLAGS_IOPL;
+
+regs->rip= iret_saved.rip;
+regs->cs = iret_saved.cs | 3; /* force guest privilege */
+regs->rflags = ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM))
+| X86_EFLAGS_IF);
+regs->rsp= iret_saved.rsp;
+regs->ss = iret_saved.ss | 3; /* force guest privilege */
+
+if ( !(iret_saved.flags & VGCF_in_syscall) )
+{
+regs->entry_vector &= ~TRAP_syscall;
+regs->r11 = iret_saved.r11;
+regs->rcx = iret_saved.rcx;
+}
+
+/* Restore upcall mask from supplied EFLAGS.IF. */
+vcpu_info(v, evtchn_upcall_mask) = !(iret_saved.rflags & X86_EFLAGS_IF);
+
+async_exception_cleanup(v);
+
+/* Saved %rax gets written back to regs->rax in entry.S. */
+return iret_saved.rax;
+
+ exit_and_crash:
+domain_crash(v->domain);
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 36b694c605..4641bc6d06 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -254,62 +254,6 @@ void do_double_fault(struct cpu_user_regs *regs)
 panic("DOUBLE FAULT -- system shutdown");
 }
 
-unsigned long do_iret(void)
-{
-struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct iret_context iret_saved;
-struct vcpu *v = current;
-
-if ( unlikely(copy_from_user(_saved, (void *)regs->rsp,
- sizeof(iret_saved))) )
-{
-gprintk(XENLOG_ERR,
-"Fault while reading IRET context from guest stack\n");
-goto exit_and_crash;
-}
-
-/* Returning to user mode? */
-if ( (iret_saved.cs & 3) == 3 )
-{
-if ( unlikely(pagetable_is_null(v->arch.guest_table_user)) )
-{
-gprintk(XENLOG_ERR,
-"Guest switching to user mode with no user page tables\n");
-goto exit_and_crash;
-}
-toggle_guest_mode(v);
-}
-
-if ( VM_ASSIST(v->domain, architectural_iopl) )
-v->arch.pv_vcpu.iopl = iret_saved.rflags & X86_EFLAGS_IOPL;
-
-regs->rip= iret_saved.rip;
-regs->cs = iret_saved.cs | 3; /* force guest privilege */
-regs->rflags = ((iret_saved.rflags & ~(X86_EFLAGS_IOPL|X86_EFLAGS_VM))
-| X86_EFLAGS_IF);
-regs->rsp= iret_saved.rsp;
-regs->ss = iret_saved.ss | 3; /* force guest privilege */
-
-if ( !(iret_saved.flags & VGCF_in_syscall) )
-{
-regs->entry_vector &= ~TRAP_syscall;
-regs->r11 = iret_saved.r11;
-regs->rcx = iret_saved.rcx;
-}
-
-/* Restore upcall mask from supplied EFLAGS.IF. */
-vcpu_info(v, evtchn_upcall_mask) = !(iret_saved.rflags & X86_EFLAGS_IF);
-
-async_exception_cleanup(v);
-
-/* Saved %rax gets written back to regs->rax in entry.S. */
-return iret_saved.rax;
-
- exit_and_crash:
-domain_crash(v->domain);
-return 0;
-}
-
 static unsigned int write_stub_trampoline(
 unsigned char *stub, unsigned long stub_va,
 unsigned long stack_bottom, unsigned long target_va)
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 21/22] x86: fix coding style issues in asm-x86/traps.h

[Wei Liu]

And provide an Emacs block.

Signed-off-by: Wei Liu 
---
 xen/include/asm-x86/traps.h | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index 7f36f6c1a7..0676e81d1a 100644
--- a/xen/include/asm-x86/traps.h
+++ b/xen/include/asm-x86/traps.h
@@ -20,16 +20,16 @@
 #define ASM_TRAP_H
 
 struct softirq_trap {
-   struct domain *domain;  /* domain to inject trap */
-   struct vcpu *vcpu;  /* vcpu to inject trap */
-   int processor;  /* physical cpu to inject trap */
+struct domain *domain;  /* domain to inject trap */
+struct vcpu *vcpu;  /* vcpu to inject trap */
+int processor;  /* physical cpu to inject trap */
 };
 DECLARE_PER_CPU(struct softirq_trap, softirq_trap);
 
 struct cpu_user_regs;
 
 void async_exception_cleanup(struct vcpu *);
- 
+
 /**
  * guest_has_trap_callback
  *
@@ -45,7 +45,7 @@ extern bool guest_has_trap_callback(struct domain *d, 
uint16_t vcpuid,
  * return 0 on successful delivery
  */
 extern int send_guest_trap(struct domain *d, uint16_t vcpuid,
-   unsigned int trap_nr);
+   unsigned int trap_nr);
 
 uint32_t guest_io_read(unsigned int port, unsigned int bytes,
struct domain *);
@@ -55,3 +55,13 @@ void guest_io_write(unsigned int port, unsigned int bytes, 
uint32_t data,
 const char *trapstr(unsigned int trapnr);
 
 #endif /* ASM_TRAP_H */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 20/22] x86: guest_has_trap_callback should return bool

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 4 ++--
 xen/include/asm-x86/traps.h | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index ea5b543247..c36b650f5f 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -274,8 +274,8 @@ long unregister_guest_nmi_callback(void)
 return 0;
 }
 
-int guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
-unsigned int trap_nr)
+bool guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
+ unsigned int trap_nr)
 {
 struct vcpu *v;
 struct trap_info *t;
diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index 4e8760482f..7f36f6c1a7 100644
--- a/xen/include/asm-x86/traps.h
+++ b/xen/include/asm-x86/traps.h
@@ -33,10 +33,10 @@ void async_exception_cleanup(struct vcpu *);
 /**
  * guest_has_trap_callback
  *
- * returns true (non-zero) if guest registered a trap handler
+ * returns true if guest registered a trap handler
  */
-extern int guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
-   unsigned int trap_nr);
+extern bool guest_has_trap_callback(struct domain *d, uint16_t vcpuid,
+unsigned int trap_nr);
 
 /**
  * send_guest_trap
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 19/22] x86: clean up pv/traps.c

[Wei Liu]

Fix coding style issues. No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 62 ++---
 1 file changed, 43 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index db92f6d520..ea5b543247 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -148,6 +148,7 @@ void pv_inject_event(const struct x86_event *event)
 bool use_error_code;
 
 ASSERT(vector == event->vector); /* Confirm no truncation. */
+
 if ( event->type == X86_EVENTTYPE_HW_EXCEPTION )
 {
 ASSERT(vector < 32);
@@ -158,6 +159,7 @@ void pv_inject_event(const struct x86_event *event)
 ASSERT(event->type == X86_EVENTTYPE_SW_INTERRUPT);
 use_error_code = false;
 }
+
 if ( use_error_code )
 ASSERT(error_code != X86_EVENT_NO_EC);
 else
@@ -217,6 +219,7 @@ int set_guest_machinecheck_trapbounce(void)
 
 pv_inject_hw_exception(TRAP_machine_check, X86_EVENT_NO_EC);
 tb->flags &= ~TBF_EXCEPTION; /* not needed for MCE delivery path */
+
 return !null_trap_bounce(v, tb);
 }
 
@@ -228,8 +231,10 @@ int set_guest_nmi_trapbounce(void)
 {
 struct vcpu *v = current;
 struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
+
 pv_inject_hw_exception(TRAP_nmi, X86_EVENT_NO_EC);
 tb->flags &= ~TBF_EXCEPTION; /* not needed for NMI delivery path */
+
 return !null_trap_bounce(v, tb);
 }
 
@@ -301,15 +306,17 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, 
unsigned int trap_nr)
 case TRAP_nmi:
 if ( cmpxchgptr(>vcpu, NULL, v) )
 return -EBUSY;
+
 if ( !test_and_set_bool(v->nmi_pending) )
 {
-   st->domain = d;
-   st->processor = v->processor;
+st->domain = d;
+st->processor = v->processor;
 
-   /* not safe to wake up a vcpu here */
-   raise_softirq(NMI_MCE_SOFTIRQ);
-   return 0;
+/* not safe to wake up a vcpu here */
+raise_softirq(NMI_MCE_SOFTIRQ);
+return 0;
 }
+
 st->vcpu = NULL;
 break;
 
@@ -318,17 +325,19 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, 
unsigned int trap_nr)
 return -EBUSY;
 
 /* We are called by the machine check (exception or polling) handlers
- * on the physical CPU that reported a machine check error. */
+ * on the physical CPU that reported a machine check error.
+ */
 
 if ( !test_and_set_bool(v->mce_pending) )
 {
-st->domain = d;
-st->processor = v->processor;
+st->domain = d;
+st->processor = v->processor;
 
-/* not safe to wake up a vcpu here */
-raise_softirq(NMI_MCE_SOFTIRQ);
-return 0;
+/* not safe to wake up a vcpu here */
+raise_softirq(NMI_MCE_SOFTIRQ);
+return 0;
 }
+
 st->vcpu = NULL;
 break;
 }
@@ -341,6 +350,7 @@ void toggle_guest_mode(struct vcpu *v)
 {
 if ( is_pv_32bit_vcpu(v) )
 return;
+
 if ( cpu_has_fsgsbase )
 {
 if ( v->arch.flags & TF_kernel_mode )
@@ -348,6 +358,7 @@ void toggle_guest_mode(struct vcpu *v)
 else
 v->arch.pv_vcpu.gs_base_user = __rdgsbase();
 }
+
 v->arch.flags ^= TF_kernel_mode;
 asm volatile ( "swapgs" );
 update_cr3(v);
@@ -362,8 +373,7 @@ void toggle_guest_mode(struct vcpu *v)
 v->arch.pv_vcpu.need_update_runstate_area = 0;
 
 if ( v->arch.pv_vcpu.pending_system_time.version &&
- update_secondary_system_time(v,
-  >arch.pv_vcpu.pending_system_time) )
+ update_secondary_system_time(v, >arch.pv_vcpu.pending_system_time) 
)
 v->arch.pv_vcpu.pending_system_time.version = 0;
 }
 
@@ -428,8 +438,8 @@ void init_int80_direct_trap(struct vcpu *v)
 struct trap_info *ti = >arch.pv_vcpu.trap_ctxt[0x80];
 struct trap_bounce *tb = >arch.pv_vcpu.int80_bounce;
 
-tb->cs= ti->cs;
-tb->eip   = ti->address;
+tb->cs  = ti->cs;
+tb->eip = ti->address;
 
 if ( null_trap_bounce(v, tb) )
 tb->flags = 0;
@@ -448,27 +458,31 @@ static long register_guest_callback(struct 
callback_register *reg)
 switch ( reg->type )
 {
 case CALLBACKTYPE_event:
-v->arch.pv_vcpu.event_callback_eip= reg->address;
+v->arch.pv_vcpu.event_callback_eip = reg->address;
 break;
 
 case CALLBACKTYPE_failsafe:
 v->arch.pv_vcpu.failsafe_callback_eip = reg->address;
+
 if ( reg->flags & CALLBACKF_mask_events )
 set_bit(_VGCF_failsafe_disables_events,
 >arch.vgc_flags);
 else
 clear_bit(_VGCF_failsafe_disables_events,
   >arch.vgc_flags);
+
 break;
 
 case CALLBACKTYPE_syscall:
  

[Xen-devel] [PATCH for-next v3 13/22] x86/traps: move toggle_guest_mode

[Wei Liu]

Move from x86_64/traps.c to pv/traps.c.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 30 ++
 xen/arch/x86/x86_64/traps.c | 30 --
 2 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 7c841e04cc..5b84a617e6 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -332,6 +332,36 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, 
unsigned int trap_nr)
 return -EIO;
 }
 
+void toggle_guest_mode(struct vcpu *v)
+{
+if ( is_pv_32bit_vcpu(v) )
+return;
+if ( cpu_has_fsgsbase )
+{
+if ( v->arch.flags & TF_kernel_mode )
+v->arch.pv_vcpu.gs_base_kernel = __rdgsbase();
+else
+v->arch.pv_vcpu.gs_base_user = __rdgsbase();
+}
+v->arch.flags ^= TF_kernel_mode;
+asm volatile ( "swapgs" );
+update_cr3(v);
+/* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
+asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
+
+if ( !(v->arch.flags & TF_kernel_mode) )
+return;
+
+if ( v->arch.pv_vcpu.need_update_runstate_area &&
+ update_runstate_area(v) )
+v->arch.pv_vcpu.need_update_runstate_area = 0;
+
+if ( v->arch.pv_vcpu.pending_system_time.version &&
+ update_secondary_system_time(v,
+  >arch.pv_vcpu.pending_system_time) )
+v->arch.pv_vcpu.pending_system_time.version = 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/x86_64/traps.c b/xen/arch/x86/x86_64/traps.c
index 78f410517c..36b694c605 100644
--- a/xen/arch/x86/x86_64/traps.c
+++ b/xen/arch/x86/x86_64/traps.c
@@ -254,36 +254,6 @@ void do_double_fault(struct cpu_user_regs *regs)
 panic("DOUBLE FAULT -- system shutdown");
 }
 
-void toggle_guest_mode(struct vcpu *v)
-{
-if ( is_pv_32bit_vcpu(v) )
-return;
-if ( cpu_has_fsgsbase )
-{
-if ( v->arch.flags & TF_kernel_mode )
-v->arch.pv_vcpu.gs_base_kernel = __rdgsbase();
-else
-v->arch.pv_vcpu.gs_base_user = __rdgsbase();
-}
-v->arch.flags ^= TF_kernel_mode;
-asm volatile ( "swapgs" );
-update_cr3(v);
-/* Don't flush user global mappings from the TLB. Don't tick TLB clock. */
-asm volatile ( "mov %0, %%cr3" : : "r" (v->arch.cr3) : "memory" );
-
-if ( !(v->arch.flags & TF_kernel_mode) )
-return;
-
-if ( v->arch.pv_vcpu.need_update_runstate_area &&
- update_runstate_area(v) )
-v->arch.pv_vcpu.need_update_runstate_area = 0;
-
-if ( v->arch.pv_vcpu.pending_system_time.version &&
- update_secondary_system_time(v,
-  >arch.pv_vcpu.pending_system_time) )
-v->arch.pv_vcpu.pending_system_time.version = 0;
-}
-
 unsigned long do_iret(void)
 {
 struct cpu_user_regs *regs = guest_cpu_user_regs();
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 10/22] x86/traps: delcare percpu softirq_trap

[Wei Liu]

It needs to be non-static when we split PV specific code out.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/traps.c| 2 +-
 xen/include/asm-x86/traps.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e6028a4403..a26b002173 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1478,7 +1478,7 @@ void do_general_protection(struct cpu_user_regs *regs)
 panic("GENERAL PROTECTION FAULT\n[error_code=%04x]", regs->error_code);
 }
 
-static DEFINE_PER_CPU(struct softirq_trap, softirq_trap);
+DEFINE_PER_CPU(struct softirq_trap, softirq_trap);
 
 static void nmi_mce_softirq(void)
 {
diff --git a/xen/include/asm-x86/traps.h b/xen/include/asm-x86/traps.h
index f1d2513e6b..4e8760482f 100644
--- a/xen/include/asm-x86/traps.h
+++ b/xen/include/asm-x86/traps.h
@@ -24,6 +24,7 @@ struct softirq_trap {
struct vcpu *vcpu;  /* vcpu to inject trap */
int processor;  /* physical cpu to inject trap */
 };
+DECLARE_PER_CPU(struct softirq_trap, softirq_trap);
 
 struct cpu_user_regs;
 
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 22/22] x86: clean up traps.c

[Wei Liu]

Replace bool_t with bool. Delete trailing white spaces. Fix some coding
style issues.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/traps.c | 77 +++-
 1 file changed, 40 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 3cc4b5b78b..c1e28cd926 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1,18 +1,18 @@
 /**
  * arch/x86/traps.c
- * 
+ *
  * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; If not, see .
  */
@@ -113,7 +113,7 @@ void (*ioemul_handle_quirk)(
 static int debug_stack_lines = 20;
 integer_param("debug_stack_lines", debug_stack_lines);
 
-static bool_t opt_ler;
+static bool opt_ler;
 boolean_param("ler", opt_ler);
 
 #define stack_words_per_line 4
@@ -528,7 +528,7 @@ void vcpu_show_execution_state(struct vcpu *v)
 }
 
 static cpumask_t show_state_mask;
-static bool_t opt_show_all;
+static bool opt_show_all;
 boolean_param("async-show-all", opt_show_all);
 
 static int nmi_show_execution_state(const struct cpu_user_regs *regs, int cpu)
@@ -539,8 +539,8 @@ static int nmi_show_execution_state(const struct 
cpu_user_regs *regs, int cpu)
 if ( opt_show_all )
 show_execution_state(regs);
 else
-printk(XENLOG_ERR "CPU%d @ %04x:%08lx (%pS)\n", cpu, regs->cs, 
regs->rip,
-   guest_mode(regs) ? _p(regs->rip) : NULL);
+printk(XENLOG_ERR "CPU%d @ %04x:%08lx (%pS)\n", cpu, regs->cs,
+   regs->rip, guest_mode(regs) ? _p(regs->rip) : NULL);
 cpumask_clear_cpu(cpu, _state_mask);
 
 return 1;
@@ -565,7 +565,7 @@ const char *trapstr(unsigned int trapnr)
  * are disabled). In such situations we can't do much that is safe. We try to
  * print out some tracing and then we just spin.
  */
-void fatal_trap(const struct cpu_user_regs *regs, bool_t show_remote)
+void fatal_trap(const struct cpu_user_regs *regs, bool show_remote)
 {
 static DEFINE_PER_CPU(char, depth);
 unsigned int trapnr = regs->entry_vector;
@@ -1018,8 +1018,8 @@ void do_int3(struct cpu_user_regs *regs)
 pv_inject_hw_exception(TRAP_int3, X86_EVENT_NO_EC);
 }
 
-static void reserved_bit_page_fault(
-unsigned long addr, struct cpu_user_regs *regs)
+static void reserved_bit_page_fault(unsigned long addr,
+struct cpu_user_regs *regs)
 {
 printk("%pv: reserved bit in page table (ec=%04X)\n",
current, regs->error_code);
@@ -1027,8 +1027,8 @@ static void reserved_bit_page_fault(
 show_execution_state(regs);
 }
 
-static int handle_gdt_ldt_mapping_fault(
-unsigned long offset, struct cpu_user_regs *regs)
+static int handle_gdt_ldt_mapping_fault(unsigned long offset,
+struct cpu_user_regs *regs)
 {
 struct vcpu *curr = current;
 /* Which vcpu's area did we fault in, and is it in the ldt sub-area? */
@@ -1096,8 +1096,8 @@ enum pf_type {
 spurious_fault
 };
 
-static enum pf_type __page_fault_type(
-unsigned long addr, const struct cpu_user_regs *regs)
+static enum pf_type __page_fault_type(unsigned long addr,
+  const struct cpu_user_regs *regs)
 {
 unsigned long mfn, cr3 = read_cr3();
 l4_pgentry_t l4e, *l4t;
@@ -1203,8 +1203,8 @@ leaf:
 return spurious_fault;
 }
 
-static enum pf_type spurious_page_fault(
-unsigned long addr, const struct cpu_user_regs *regs)
+static enum pf_type spurious_page_fault(unsigned long addr,
+const struct cpu_user_regs *regs)
 {
 unsigned long flags;
 enum pf_type pf_type;
@@ -1313,7 +1313,8 @@ void do_page_fault(struct cpu_user_regs *regs)
 if ( (pf_type == smep_fault) || (pf_type == smap_fault) )
 {
 console_start_sync();
-printk("Xen SM%cP violation\n", (pf_type == smep_fault) ? 'E' : 
'A');
+printk("Xen SM%cP violation\n",
+   (pf_type == smep_fault) ? 'E' : 'A');
 fatal_trap(regs, 0);
 }
 
@@ -1363,9 +1364,9 @@ void do_page_fault(struct cpu_user_regs *regs)
 
 /*
  * Early #PF handler to print CR2, error code, and stack.
- * 
+ *
  * We also deal with 

[Xen-devel] [PATCH for-next v3 04/22] x86/traps: move emulate_forced_invalid_op

[Wei Liu]

And remove the now unused instruction_done in x86/traps.c.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/emulate.c  | 51 ++
 xen/arch/x86/traps.c   | 62 --
 xen/include/asm-x86/pv/traps.h |  2 ++
 3 files changed, 53 insertions(+), 62 deletions(-)

diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
index 364cd0f78c..e261aeb0f7 100644
--- a/xen/arch/x86/pv/emulate.c
+++ b/xen/arch/x86/pv/emulate.c
@@ -1882,6 +1882,57 @@ int emulate_invalid_rdtscp(struct cpu_user_regs *regs)
 return EXCRET_fault_fixed;
 }
 
+int emulate_forced_invalid_op(struct cpu_user_regs *regs)
+{
+char sig[5], instr[2];
+unsigned long eip, rc;
+struct cpuid_leaf res;
+
+eip = regs->rip;
+
+/* Check for forced emulation signature: ud2 ; .ascii "xen". */
+if ( (rc = copy_from_user(sig, (char *)eip, sizeof(sig))) != 0 )
+{
+pv_inject_page_fault(0, eip + sizeof(sig) - rc);
+return EXCRET_fault_fixed;
+}
+if ( memcmp(sig, "\xf\xbxen", sizeof(sig)) )
+return 0;
+eip += sizeof(sig);
+
+/* We only emulate CPUID. */
+if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
+{
+pv_inject_page_fault(0, eip + sizeof(instr) - rc);
+return EXCRET_fault_fixed;
+}
+if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
+return 0;
+
+/* If cpuid faulting is enabled and CPL>0 inject a #GP in place of #UD. */
+if ( current->arch.cpuid_faulting && !guest_kernel_mode(current, regs) )
+{
+regs->rip = eip;
+pv_inject_hw_exception(TRAP_gp_fault, regs->error_code);
+return EXCRET_fault_fixed;
+}
+
+eip += sizeof(instr);
+
+guest_cpuid(current, regs->eax, regs->ecx, );
+
+regs->rax = res.a;
+regs->rbx = res.b;
+regs->rcx = res.c;
+regs->rdx = res.d;
+
+instruction_done(regs, eip);
+
+trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->rip);
+
+return EXCRET_fault_fixed;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 38bc531f5b..ace346d377 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -696,17 +696,6 @@ void pv_inject_event(const struct x86_event *event)
 }
 }
 
-static void instruction_done(struct cpu_user_regs *regs, unsigned long rip)
-{
-regs->rip = rip;
-regs->eflags &= ~X86_EFLAGS_RF;
-if ( regs->eflags & X86_EFLAGS_TF )
-{
-current->arch.debugreg[6] |= DR_STEP | DR_STATUS_RESERVED_ONE;
-pv_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
-}
-}
-
 /*
  * Called from asm to set up the MCE trapbounce info.
  * Returns 0 if no callback is set up, else 1.
@@ -978,57 +967,6 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
uint32_t leaf,
 }
 }
 
-static int emulate_forced_invalid_op(struct cpu_user_regs *regs)
-{
-char sig[5], instr[2];
-unsigned long eip, rc;
-struct cpuid_leaf res;
-
-eip = regs->rip;
-
-/* Check for forced emulation signature: ud2 ; .ascii "xen". */
-if ( (rc = copy_from_user(sig, (char *)eip, sizeof(sig))) != 0 )
-{
-pv_inject_page_fault(0, eip + sizeof(sig) - rc);
-return EXCRET_fault_fixed;
-}
-if ( memcmp(sig, "\xf\xbxen", sizeof(sig)) )
-return 0;
-eip += sizeof(sig);
-
-/* We only emulate CPUID. */
-if ( ( rc = copy_from_user(instr, (char *)eip, sizeof(instr))) != 0 )
-{
-pv_inject_page_fault(0, eip + sizeof(instr) - rc);
-return EXCRET_fault_fixed;
-}
-if ( memcmp(instr, "\xf\xa2", sizeof(instr)) )
-return 0;
-
-/* If cpuid faulting is enabled and CPL>0 inject a #GP in place of #UD. */
-if ( current->arch.cpuid_faulting && !guest_kernel_mode(current, regs) )
-{
-regs->rip = eip;
-pv_inject_hw_exception(TRAP_gp_fault, regs->error_code);
-return EXCRET_fault_fixed;
-}
-
-eip += sizeof(instr);
-
-guest_cpuid(current, regs->eax, regs->ecx, );
-
-regs->rax = res.a;
-regs->rbx = res.b;
-regs->rcx = res.c;
-regs->rdx = res.d;
-
-instruction_done(regs, eip);
-
-trace_trap_one_addr(TRC_PV_FORCED_INVALID_OP, regs->rip);
-
-return EXCRET_fault_fixed;
-}
-
 void do_invalid_op(struct cpu_user_regs *regs)
 {
 const struct bug_frame *bug = NULL;
diff --git a/xen/include/asm-x86/pv/traps.h b/xen/include/asm-x86/pv/traps.h
index 88dc20928b..3f1c93a430 100644
--- a/xen/include/asm-x86/pv/traps.h
+++ b/xen/include/asm-x86/pv/traps.h
@@ -28,6 +28,7 @@
 int emulate_privileged_op(struct cpu_user_regs *regs);
 void emulate_gate_op(struct cpu_user_regs *regs);
 int emulate_invalid_rdtscp(struct cpu_user_regs *regs);
+int emulate_forced_invalid_op(struct cpu_user_regs *regs);
 
 #else  /* !CONFIG_PV */
 
@@ -36,6 +37,7 @@ int emulate_invalid_rdtscp(struct cpu_user_regs *regs);
 int emulate_privileged_op(struct 

[Xen-devel] [PATCH for-next v3 09/22] x86/traps: move {un, }register_guest_nmi_callback

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 36 
 xen/arch/x86/traps.c| 36 
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index d7e8db5820..ff7dd1905f 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -228,6 +228,42 @@ int set_guest_nmi_trapbounce(void)
 return !null_trap_bounce(v, tb);
 }
 
+long register_guest_nmi_callback(unsigned long address)
+{
+struct vcpu *v = current;
+struct domain *d = v->domain;
+struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
+
+if ( !is_canonical_address(address) )
+return -EINVAL;
+
+t->vector  = TRAP_nmi;
+t->flags   = 0;
+t->cs  = (is_pv_32bit_domain(d) ?
+  FLAT_COMPAT_KERNEL_CS : FLAT_KERNEL_CS);
+t->address = address;
+TI_SET_IF(t, 1);
+
+/*
+ * If no handler was registered we can 'lose the NMI edge'. Re-assert it
+ * now.
+ */
+if ( (v->vcpu_id == 0) && (arch_get_nmi_reason(d) != 0) )
+v->nmi_pending = 1;
+
+return 0;
+}
+
+long unregister_guest_nmi_callback(void)
+{
+struct vcpu *v = current;
+struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
+
+memset(t, 0, sizeof(*t));
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8eb7b31a6c..e6028a4403 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1910,42 +1910,6 @@ void __init trap_init(void)
 open_softirq(PCI_SERR_SOFTIRQ, pci_serr_softirq);
 }
 
-long register_guest_nmi_callback(unsigned long address)
-{
-struct vcpu *v = current;
-struct domain *d = v->domain;
-struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
-
-if ( !is_canonical_address(address) )
-return -EINVAL;
-
-t->vector  = TRAP_nmi;
-t->flags   = 0;
-t->cs  = (is_pv_32bit_domain(d) ?
-  FLAT_COMPAT_KERNEL_CS : FLAT_KERNEL_CS);
-t->address = address;
-TI_SET_IF(t, 1);
-
-/*
- * If no handler was registered we can 'lose the NMI edge'. Re-assert it
- * now.
- */
-if ( (v->vcpu_id == 0) && (arch_get_nmi_reason(d) != 0) )
-v->nmi_pending = 1;
-
-return 0;
-}
-
-long unregister_guest_nmi_callback(void)
-{
-struct vcpu *v = current;
-struct trap_info *t = >arch.pv_vcpu.trap_ctxt[TRAP_nmi];
-
-memset(t, 0, sizeof(*t));
-
-return 0;
-}
-
 int guest_has_trap_callback(struct domain *d, uint16_t vcpuid, unsigned int 
trap_nr)
 {
 struct vcpu *v;
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 01/22] x86/traps: move privilege instruction emulation code

[Wei Liu]

Move relevant code to pv/emulate.c. Export emulate_privileged_op in
pv/traps.h.

Note that read_descriptor is duplicated in emulate.c. The duplication
will be gone once all emulation code is moved.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/Makefile   |1 +
 xen/arch/x86/pv/emulate.c  | 1470 
 xen/arch/x86/traps.c   | 1358 +
 xen/include/asm-x86/pv/traps.h |   48 ++
 4 files changed, 1521 insertions(+), 1356 deletions(-)
 create mode 100644 xen/arch/x86/pv/emulate.c
 create mode 100644 xen/include/asm-x86/pv/traps.h

diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
index 489a9f59cb..564202cbb7 100644
--- a/xen/arch/x86/pv/Makefile
+++ b/xen/arch/x86/pv/Makefile
@@ -3,3 +3,4 @@ obj-y += traps.o
 
 obj-bin-y += dom0_build.init.o
 obj-y += domain.o
+obj-y += emulate.o
diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
new file mode 100644
index 00..fb0d066a3b
--- /dev/null
+++ b/xen/arch/x86/pv/emulate.c
@@ -0,0 +1,1470 @@
+/**
+ * arch/x86/pv/emulate.c
+ *
+ * PV emulation code
+ *
+ * Modifications to Linux original are copyright (c) 2002-2004, K A Fraser
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "../x86_64/mmconfig.h"
+
+/**
+ * Helper functions
+ */
+
+static int read_descriptor(unsigned int sel,
+   const struct vcpu *v,
+   unsigned long *base,
+   unsigned long *limit,
+   unsigned int *ar,
+   bool_t insn_fetch)
+{
+struct desc_struct desc;
+
+if ( sel < 4)
+desc.b = desc.a = 0;
+else if ( __get_user(desc,
+ (const struct desc_struct *)(!(sel & 4)
+  ? GDT_VIRT_START(v)
+  : LDT_VIRT_START(v))
+ + (sel >> 3)) )
+return 0;
+if ( !insn_fetch )
+desc.b &= ~_SEGMENT_L;
+
+*ar = desc.b & 0x00f0ff00;
+if ( !(desc.b & _SEGMENT_L) )
+{
+*base = ((desc.a >> 16) + ((desc.b & 0xff) << 16) +
+ (desc.b & 0xff00));
+*limit = (desc.a & 0x) | (desc.b & 0x000f);
+if ( desc.b & _SEGMENT_G )
+*limit = ((*limit + 1) << 12) - 1;
+#ifndef NDEBUG
+if ( sel > 3 )
+{
+unsigned int a, l;
+unsigned char valid;
+
+asm volatile (
+"larl %2,%0 ; setz %1"
+: "=r" (a), "=qm" (valid) : "rm" (sel));
+BUG_ON(valid && ((a & 0x00f0ff00) != *ar));
+asm volatile (
+"lsll %2,%0 ; setz %1"
+: "=r" (l), "=qm" (valid) : "rm" (sel));
+BUG_ON(valid && (l != *limit));
+}
+#endif
+}
+else
+{
+*base = 0UL;
+*limit = ~0UL;
+}
+
+return 1;
+}
+
+/***
+ * I/O emulation support
+ */
+
+struct priv_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+char *io_emul_stub;
+unsigned int bpmatch;
+unsigned int tsc;
+#define TSC_BASE 1
+#define TSC_AUX 2
+};
+
+/* I/O emulation support. Helper routines for, and type of, the stack stub.*/
+void host_to_guest_gpr_switch(struct cpu_user_regs *);
+unsigned long guest_to_host_gpr_switch(unsigned long);
+
+void (*pv_post_outb_hook)(unsigned int port, u8 value);
+
+typedef void io_emul_stub_t(struct cpu_user_regs *);
+
+static io_emul_stub_t *io_emul_stub_setup(struct priv_op_ctxt *ctxt, u8 opcode,
+  unsigned int port, unsigned int 
bytes)
+{
+if ( !ctxt->io_emul_stub )
+ctxt->io_emul_stub = map_domain_page(_mfn(this_cpu(stubs.mfn))) +
+ (this_cpu(stubs.addr) &
+  ~PAGE_MASK) +
+ STUB_BUF_SIZE 

[Xen-devel] [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c

[Wei Liu]

The following handlers are moved:
1. do_set_trap_table
2. do_set_debugreg
3. do_get_debugreg
4. do_fpu_taskswitch

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 97 +
 xen/arch/x86/traps.c| 94 ---
 2 files changed, 97 insertions(+), 94 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 51125a8d86..350e7a1da4 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -19,9 +19,13 @@
  * Copyright (c) 2017 Citrix Systems Ltd.
  */
 
+#include 
+#include 
 #include 
+#include 
 
 #include 
+#include 
 
 void do_entry_int82(struct cpu_user_regs *regs)
 {
@@ -31,6 +35,99 @@ void do_entry_int82(struct cpu_user_regs *regs)
 pv_hypercall(regs);
 }
 
+long do_fpu_taskswitch(int set)
+{
+struct vcpu *v = current;
+
+if ( set )
+{
+v->arch.pv_vcpu.ctrlreg[0] |= X86_CR0_TS;
+stts();
+}
+else
+{
+v->arch.pv_vcpu.ctrlreg[0] &= ~X86_CR0_TS;
+if ( v->fpu_dirtied )
+clts();
+}
+
+return 0;
+}
+
+long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
+{
+struct trap_info cur;
+struct vcpu *curr = current;
+struct trap_info *dst = curr->arch.pv_vcpu.trap_ctxt;
+long rc = 0;
+
+/* If no table is presented then clear the entire virtual IDT. */
+if ( guest_handle_is_null(traps) )
+{
+memset(dst, 0, NR_VECTORS * sizeof(*dst));
+init_int80_direct_trap(curr);
+return 0;
+}
+
+for ( ; ; )
+{
+if ( copy_from_guest(, traps, 1) )
+{
+rc = -EFAULT;
+break;
+}
+
+if ( cur.address == 0 )
+break;
+
+if ( !is_canonical_address(cur.address) )
+return -EINVAL;
+
+fixup_guest_code_selector(curr->domain, cur.cs);
+
+memcpy([cur.vector], , sizeof(cur));
+
+if ( cur.vector == 0x80 )
+init_int80_direct_trap(curr);
+
+guest_handle_add_offset(traps, 1);
+
+if ( hypercall_preempt_check() )
+{
+rc = hypercall_create_continuation(
+__HYPERVISOR_set_trap_table, "h", traps);
+break;
+}
+}
+
+return rc;
+}
+
+long do_set_debugreg(int reg, unsigned long value)
+{
+return set_debugreg(current, reg, value);
+}
+
+unsigned long do_get_debugreg(int reg)
+{
+struct vcpu *curr = current;
+
+switch ( reg )
+{
+case 0 ... 3:
+case 6:
+return curr->arch.debugreg[reg];
+case 7:
+return (curr->arch.debugreg[7] |
+curr->arch.debugreg[5]);
+case 4 ... 5:
+return ((curr->arch.pv_vcpu.ctrlreg[4] & X86_CR4_DE) ?
+curr->arch.debugreg[reg + 2] : 0);
+}
+
+return -EINVAL;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index ace346d377..e5a3c9ad1a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1489,25 +1489,6 @@ void __init do_early_page_fault(struct cpu_user_regs 
*regs)
 }
 }
 
-long do_fpu_taskswitch(int set)
-{
-struct vcpu *v = current;
-
-if ( set )
-{
-v->arch.pv_vcpu.ctrlreg[0] |= X86_CR0_TS;
-stts();
-}
-else
-{
-v->arch.pv_vcpu.ctrlreg[0] &= ~X86_CR0_TS;
-if ( v->fpu_dirtied )
-clts();
-}
-
-return 0;
-}
-
 void do_general_protection(struct cpu_user_regs *regs)
 {
 struct vcpu *v = current;
@@ -2126,56 +2107,6 @@ int send_guest_trap(struct domain *d, uint16_t vcpuid, 
unsigned int trap_nr)
 return -EIO;
 }
 
-
-long do_set_trap_table(XEN_GUEST_HANDLE_PARAM(const_trap_info_t) traps)
-{
-struct trap_info cur;
-struct vcpu *curr = current;
-struct trap_info *dst = curr->arch.pv_vcpu.trap_ctxt;
-long rc = 0;
-
-/* If no table is presented then clear the entire virtual IDT. */
-if ( guest_handle_is_null(traps) )
-{
-memset(dst, 0, NR_VECTORS * sizeof(*dst));
-init_int80_direct_trap(curr);
-return 0;
-}
-
-for ( ; ; )
-{
-if ( copy_from_guest(, traps, 1) )
-{
-rc = -EFAULT;
-break;
-}
-
-if ( cur.address == 0 )
-break;
-
-if ( !is_canonical_address(cur.address) )
-return -EINVAL;
-
-fixup_guest_code_selector(curr->domain, cur.cs);
-
-memcpy([cur.vector], , sizeof(cur));
-
-if ( cur.vector == 0x80 )
-init_int80_direct_trap(curr);
-
-guest_handle_add_offset(traps, 1);
-
-if ( hypercall_preempt_check() )
-{
-rc = hypercall_create_continuation(
-__HYPERVISOR_set_trap_table, "h", traps);
-break;
-}
-}
-
-return rc;
-}
-
 void activate_debugregs(const struct vcpu *curr)
 {
 ASSERT(curr == current);
@@ -2299,31 

[Xen-devel] [PATCH for-next v3 05/22] x86/pv: clean up emulate.c

[Wei Liu]

Fix coding style issues. Replace bool_t with bool. Add spaces around
binary ops. Use unsigned integer for shifting. Eliminate TOGGLE_MODE.

Signed-off-by: Wei Liu 
Signed-off-by: Andrew Cooper 
---
 xen/arch/x86/pv/emulate.c | 123 --
 1 file changed, 63 insertions(+), 60 deletions(-)

diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
index e261aeb0f7..cae6c9e350 100644
--- a/xen/arch/x86/pv/emulate.c
+++ b/xen/arch/x86/pv/emulate.c
@@ -61,7 +61,7 @@ static int read_descriptor(unsigned int sel,
unsigned long *base,
unsigned long *limit,
unsigned int *ar,
-   bool_t insn_fetch)
+   bool insn_fetch)
 {
 struct desc_struct desc;
 
@@ -126,7 +126,7 @@ struct priv_op_ctxt {
 #define TSC_AUX 2
 };
 
-/* I/O emulation support. Helper routines for, and type of, the stack stub.*/
+/* I/O emulation support. Helper routines for, and type of, the stack stub. */
 void host_to_guest_gpr_switch(struct cpu_user_regs *);
 unsigned long guest_to_host_gpr_switch(unsigned long);
 
@@ -169,7 +169,7 @@ static io_emul_stub_t *io_emul_stub_setup(struct 
priv_op_ctxt *ctxt, u8 opcode,
 
 
 /* Perform IOPL check between the vcpu's shadowed IOPL, and the assumed cpl. */
-static bool_t iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
+static bool iopl_ok(const struct vcpu *v, const struct cpu_user_regs *regs)
 {
 unsigned int cpl = guest_kernel_mode(v, regs) ?
 (VM_ASSIST(v->domain, architectural_iopl) ? 0 : 1) : 3;
@@ -180,16 +180,14 @@ static bool_t iopl_ok(const struct vcpu *v, const struct 
cpu_user_regs *regs)
 }
 
 /* Has the guest requested sufficient permission for this I/O access? */
-static int guest_io_okay(
-unsigned int port, unsigned int bytes,
-struct vcpu *v, struct cpu_user_regs *regs)
+static bool guest_io_okay(unsigned int port, unsigned int bytes,
+  struct vcpu *v, struct cpu_user_regs *regs)
 {
 /* If in user mode, switch to kernel mode just to read I/O bitmap. */
-int user_mode = !(v->arch.flags & TF_kernel_mode);
-#define TOGGLE_MODE() if ( user_mode ) toggle_guest_mode(v)
+const bool user_mode = !(v->arch.flags & TF_kernel_mode);
 
 if ( iopl_ok(v, regs) )
-return 1;
+return true;
 
 if ( v->arch.pv_vcpu.iobmp_limit > (port + bytes) )
 {
@@ -199,9 +197,11 @@ static int guest_io_okay(
  * Grab permission bytes from guest space. Inaccessible bytes are
  * read as 0xff (no access allowed).
  */
-TOGGLE_MODE();
+if ( user_mode )
+toggle_guest_mode(v);
+
 switch ( __copy_from_guest_offset(x.bytes, v->arch.pv_vcpu.iobmp,
-  port>>3, 2) )
+  port >> 3, 2) )
 {
 default: x.bytes[0] = ~0;
 /* fallthrough */
@@ -209,43 +209,45 @@ static int guest_io_okay(
 /* fallthrough */
 case 0:  break;
 }
-TOGGLE_MODE();
 
-if ( (x.mask & (((1<arch.pci_cf8) )
-return 1;
+return true;
 
 machine_bdf = CF8_BDF(currd->arch.pci_cf8);
 if ( write )
@@ -253,7 +255,7 @@ static bool_t pci_cfg_ok(struct domain *currd, unsigned int 
start,
 const unsigned long *ro_map = pci_get_ro_map(0);
 
 if ( ro_map && test_bit(machine_bdf, ro_map) )
-  

[Xen-devel] [PATCH for-next v3 03/22] x86/traps: move emulate_invalid_rdtscp

[Wei Liu]

And export it in pv/traps.h.

The stub function returns 0 because that represents "unsuccessful
emulation" in the original code.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/emulate.c  | 20 
 xen/arch/x86/traps.c   | 20 
 xen/include/asm-x86/pv/traps.h |  2 ++
 3 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
index 6d096b74b2..364cd0f78c 100644
--- a/xen/arch/x86/pv/emulate.c
+++ b/xen/arch/x86/pv/emulate.c
@@ -1862,6 +1862,26 @@ void emulate_gate_op(struct cpu_user_regs *regs)
 instruction_done(regs, off);
 }
 
+int emulate_invalid_rdtscp(struct cpu_user_regs *regs)
+{
+char opcode[3];
+unsigned long eip, rc;
+struct vcpu *v = current;
+
+eip = regs->rip;
+if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
+{
+pv_inject_page_fault(0, eip + sizeof(opcode) - rc);
+return EXCRET_fault_fixed;
+}
+if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
+return 0;
+eip += sizeof(opcode);
+pv_soft_rdtsc(v, regs, 1);
+instruction_done(regs, eip);
+return EXCRET_fault_fixed;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index b55c425071..38bc531f5b 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -978,26 +978,6 @@ void cpuid_hypervisor_leaves(const struct vcpu *v, 
uint32_t leaf,
 }
 }
 
-static int emulate_invalid_rdtscp(struct cpu_user_regs *regs)
-{
-char opcode[3];
-unsigned long eip, rc;
-struct vcpu *v = current;
-
-eip = regs->rip;
-if ( (rc = copy_from_user(opcode, (char *)eip, sizeof(opcode))) != 0 )
-{
-pv_inject_page_fault(0, eip + sizeof(opcode) - rc);
-return EXCRET_fault_fixed;
-}
-if ( memcmp(opcode, "\xf\x1\xf9", sizeof(opcode)) )
-return 0;
-eip += sizeof(opcode);
-pv_soft_rdtsc(v, regs, 1);
-instruction_done(regs, eip);
-return EXCRET_fault_fixed;
-}
-
 static int emulate_forced_invalid_op(struct cpu_user_regs *regs)
 {
 char sig[5], instr[2];
diff --git a/xen/include/asm-x86/pv/traps.h b/xen/include/asm-x86/pv/traps.h
index 2d9f23dbde..88dc20928b 100644
--- a/xen/include/asm-x86/pv/traps.h
+++ b/xen/include/asm-x86/pv/traps.h
@@ -27,6 +27,7 @@
 
 int emulate_privileged_op(struct cpu_user_regs *regs);
 void emulate_gate_op(struct cpu_user_regs *regs);
+int emulate_invalid_rdtscp(struct cpu_user_regs *regs);
 
 #else  /* !CONFIG_PV */
 
@@ -34,6 +35,7 @@ void emulate_gate_op(struct cpu_user_regs *regs);
 
 int emulate_privileged_op(struct cpu_user_regs *regs) { return -EOPNOTSUPP; }
 void emulate_gate_op(struct cpu_user_regs *regs) {}
+int emulate_invalid_rdtscp(struct cpu_user_regs *regs) { return 0; }
 
 #endif /* CONFIG_PV */
 
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 07/22] x86/traps: move pv_inject_event to pv/traps.c

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 73 +
 xen/arch/x86/traps.c| 69 --
 2 files changed, 73 insertions(+), 69 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 350e7a1da4..79304704dd 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -22,10 +22,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
+#include 
 
 void do_entry_int82(struct cpu_user_regs *regs)
 {
@@ -128,6 +132,75 @@ unsigned long do_get_debugreg(int reg)
 return -EINVAL;
 }
 
+void pv_inject_event(const struct x86_event *event)
+{
+struct vcpu *v = current;
+struct cpu_user_regs *regs = guest_cpu_user_regs();
+struct trap_bounce *tb;
+const struct trap_info *ti;
+const uint8_t vector = event->vector;
+unsigned int error_code = event->error_code;
+bool use_error_code;
+
+ASSERT(vector == event->vector); /* Confirm no truncation. */
+if ( event->type == X86_EVENTTYPE_HW_EXCEPTION )
+{
+ASSERT(vector < 32);
+use_error_code = TRAP_HAVE_EC & (1u << vector);
+}
+else
+{
+ASSERT(event->type == X86_EVENTTYPE_SW_INTERRUPT);
+use_error_code = false;
+}
+if ( use_error_code )
+ASSERT(error_code != X86_EVENT_NO_EC);
+else
+ASSERT(error_code == X86_EVENT_NO_EC);
+
+tb = >arch.pv_vcpu.trap_bounce;
+ti = >arch.pv_vcpu.trap_ctxt[vector];
+
+tb->flags = TBF_EXCEPTION;
+tb->cs= ti->cs;
+tb->eip   = ti->address;
+
+if ( event->type == X86_EVENTTYPE_HW_EXCEPTION &&
+ vector == TRAP_page_fault )
+{
+v->arch.pv_vcpu.ctrlreg[2] = event->cr2;
+arch_set_cr2(v, event->cr2);
+
+/* Re-set error_code.user flag appropriately for the guest. */
+error_code &= ~PFEC_user_mode;
+if ( !guest_kernel_mode(v, regs) )
+error_code |= PFEC_user_mode;
+
+trace_pv_page_fault(event->cr2, error_code);
+}
+else
+trace_pv_trap(vector, regs->rip, use_error_code, error_code);
+
+if ( use_error_code )
+{
+tb->flags |= TBF_EXCEPTION_ERRCODE;
+tb->error_code = error_code;
+}
+
+if ( TI_GET_IF(ti) )
+tb->flags |= TBF_INTERRUPT;
+
+if ( unlikely(null_trap_bounce(v, tb)) )
+{
+gprintk(XENLOG_WARNING,
+"Unhandled %s fault/trap [#%d, ec=%04x]\n",
+trapstr(vector), vector, error_code);
+
+if ( vector == TRAP_page_fault )
+show_page_walk(event->cr2);
+}
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index e5a3c9ad1a..96f3d6 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -627,75 +627,6 @@ void fatal_trap(const struct cpu_user_regs *regs, bool_t 
show_remote)
   (regs->eflags & X86_EFLAGS_IF) ? "" : ", IN INTERRUPT CONTEXT");
 }
 
-void pv_inject_event(const struct x86_event *event)
-{
-struct vcpu *v = current;
-struct cpu_user_regs *regs = guest_cpu_user_regs();
-struct trap_bounce *tb;
-const struct trap_info *ti;
-const uint8_t vector = event->vector;
-unsigned int error_code = event->error_code;
-bool use_error_code;
-
-ASSERT(vector == event->vector); /* Confirm no truncation. */
-if ( event->type == X86_EVENTTYPE_HW_EXCEPTION )
-{
-ASSERT(vector < 32);
-use_error_code = TRAP_HAVE_EC & (1u << vector);
-}
-else
-{
-ASSERT(event->type == X86_EVENTTYPE_SW_INTERRUPT);
-use_error_code = false;
-}
-if ( use_error_code )
-ASSERT(error_code != X86_EVENT_NO_EC);
-else
-ASSERT(error_code == X86_EVENT_NO_EC);
-
-tb = >arch.pv_vcpu.trap_bounce;
-ti = >arch.pv_vcpu.trap_ctxt[vector];
-
-tb->flags = TBF_EXCEPTION;
-tb->cs= ti->cs;
-tb->eip   = ti->address;
-
-if ( event->type == X86_EVENTTYPE_HW_EXCEPTION &&
- vector == TRAP_page_fault )
-{
-v->arch.pv_vcpu.ctrlreg[2] = event->cr2;
-arch_set_cr2(v, event->cr2);
-
-/* Re-set error_code.user flag appropriately for the guest. */
-error_code &= ~PFEC_user_mode;
-if ( !guest_kernel_mode(v, regs) )
-error_code |= PFEC_user_mode;
-
-trace_pv_page_fault(event->cr2, error_code);
-}
-else
-trace_pv_trap(vector, regs->rip, use_error_code, error_code);
-
-if ( use_error_code )
-{
-tb->flags |= TBF_EXCEPTION_ERRCODE;
-tb->error_code = error_code;
-}
-
-if ( TI_GET_IF(ti) )
-tb->flags |= TBF_INTERRUPT;
-
-if ( unlikely(null_trap_bounce(v, tb)) )
-{
-gprintk(XENLOG_WARNING,
-"Unhandled %s fault/trap [#%d, ec=%04x]\n",
-trapstr(vector), vector, error_code);
-
-if ( vector == 

[Xen-devel] [PATCH for-next v3 08/22] x86/traps: move set_guest_{machinecheck, nmi}_trapbounce

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/traps.c | 27 +++
 xen/arch/x86/traps.c| 27 ---
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/pv/traps.c b/xen/arch/x86/pv/traps.c
index 79304704dd..d7e8db5820 100644
--- a/xen/arch/x86/pv/traps.c
+++ b/xen/arch/x86/pv/traps.c
@@ -201,6 +201,33 @@ void pv_inject_event(const struct x86_event *event)
 }
 }
 
+/*
+ * Called from asm to set up the MCE trapbounce info.
+ * Returns 0 if no callback is set up, else 1.
+ */
+int set_guest_machinecheck_trapbounce(void)
+{
+struct vcpu *v = current;
+struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
+
+pv_inject_hw_exception(TRAP_machine_check, X86_EVENT_NO_EC);
+tb->flags &= ~TBF_EXCEPTION; /* not needed for MCE delivery path */
+return !null_trap_bounce(v, tb);
+}
+
+/*
+ * Called from asm to set up the NMI trapbounce info.
+ * Returns 0 if no callback is set up, else 1.
+ */
+int set_guest_nmi_trapbounce(void)
+{
+struct vcpu *v = current;
+struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
+pv_inject_hw_exception(TRAP_nmi, X86_EVENT_NO_EC);
+tb->flags &= ~TBF_EXCEPTION; /* not needed for NMI delivery path */
+return !null_trap_bounce(v, tb);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 96f3d6..8eb7b31a6c 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -627,33 +627,6 @@ void fatal_trap(const struct cpu_user_regs *regs, bool_t 
show_remote)
   (regs->eflags & X86_EFLAGS_IF) ? "" : ", IN INTERRUPT CONTEXT");
 }
 
-/*
- * Called from asm to set up the MCE trapbounce info.
- * Returns 0 if no callback is set up, else 1.
- */
-int set_guest_machinecheck_trapbounce(void)
-{
-struct vcpu *v = current;
-struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
- 
-pv_inject_hw_exception(TRAP_machine_check, X86_EVENT_NO_EC);
-tb->flags &= ~TBF_EXCEPTION; /* not needed for MCE delivery path */
-return !null_trap_bounce(v, tb);
-}
-
-/*
- * Called from asm to set up the NMI trapbounce info.
- * Returns 0 if no callback is set up, else 1.
- */
-int set_guest_nmi_trapbounce(void)
-{
-struct vcpu *v = current;
-struct trap_bounce *tb = >arch.pv_vcpu.trap_bounce;
-pv_inject_hw_exception(TRAP_nmi, X86_EVENT_NO_EC);
-tb->flags &= ~TBF_EXCEPTION; /* not needed for NMI delivery path */
-return !null_trap_bounce(v, tb);
-}
-
 void do_reserved_trap(struct cpu_user_regs *regs)
 {
 unsigned int trapnr = regs->entry_vector;
-- 
2.11.0


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

[Xen-devel] [PATCH for-next v3 02/22] x86/traps: move gate op emulation code

[Wei Liu]

The code is moved to pv/emulate.c. Export emulate_gate_op in
pv/traps.h.

Delete the now unused read_descriptor in x86/traps.c. Duplicate
instruction_done in pv/traps.c.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/emulate.c  | 403 +
 xen/arch/x86/traps.c   | 441 -
 xen/include/asm-x86/pv/traps.h |   2 +
 3 files changed, 405 insertions(+), 441 deletions(-)

diff --git a/xen/arch/x86/pv/emulate.c b/xen/arch/x86/pv/emulate.c
index fb0d066a3b..6d096b74b2 100644
--- a/xen/arch/x86/pv/emulate.c
+++ b/xen/arch/x86/pv/emulate.c
@@ -45,6 +45,17 @@
  * Helper functions
  */
 
+static void instruction_done(struct cpu_user_regs *regs, unsigned long rip)
+{
+regs->rip = rip;
+regs->eflags &= ~X86_EFLAGS_RF;
+if ( regs->eflags & X86_EFLAGS_TF )
+{
+current->arch.debugreg[6] |= DR_STEP | DR_STATUS_RESERVED_ONE;
+pv_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+}
+}
+
 static int read_descriptor(unsigned int sel,
const struct vcpu *v,
unsigned long *base,
@@ -1459,6 +1470,398 @@ int emulate_privileged_op(struct cpu_user_regs *regs)
 return 0;
 }
 
+/***
+ * Gate OP emulation
+ */
+
+
+static int read_gate_descriptor(unsigned int gate_sel,
+const struct vcpu *v,
+unsigned int *sel,
+unsigned long *off,
+unsigned int *ar)
+{
+struct desc_struct desc;
+const struct desc_struct *pdesc;
+
+
+pdesc = (const struct desc_struct *)
+(!(gate_sel & 4) ? GDT_VIRT_START(v) : LDT_VIRT_START(v))
++ (gate_sel >> 3);
+if ( (gate_sel < 4) ||
+ ((gate_sel >= FIRST_RESERVED_GDT_BYTE) && !(gate_sel & 4)) ||
+ __get_user(desc, pdesc) )
+return 0;
+
+*sel = (desc.a >> 16) & 0xfffc;
+*off = (desc.a & 0x) | (desc.b & 0x);
+*ar = desc.b & 0x;
+
+/*
+ * check_descriptor() clears the DPL field and stores the
+ * guest requested DPL in the selector's RPL field.
+ */
+if ( *ar & _SEGMENT_DPL )
+return 0;
+*ar |= (desc.a >> (16 - 13)) & _SEGMENT_DPL;
+
+if ( !is_pv_32bit_vcpu(v) )
+{
+if ( (*ar & 0x1f00) != 0x0c00 ||
+ (gate_sel >= FIRST_RESERVED_GDT_BYTE - 8 && !(gate_sel & 4)) ||
+ __get_user(desc, pdesc + 1) ||
+ (desc.b & 0x1f00) )
+return 0;
+
+*off |= (unsigned long)desc.a << 32;
+return 1;
+}
+
+switch ( *ar & 0x1f00 )
+{
+case 0x0400:
+*off &= 0x;
+break;
+case 0x0c00:
+break;
+default:
+return 0;
+}
+
+return 1;
+}
+
+static inline int check_stack_limit(unsigned int ar, unsigned int limit,
+unsigned int esp, unsigned int decr)
+{
+return (((esp - decr) < (esp - 1)) &&
+(!(ar & _SEGMENT_EC) ? (esp - 1) <= limit : (esp - decr) > limit));
+}
+
+struct gate_op_ctxt {
+struct x86_emulate_ctxt ctxt;
+struct {
+unsigned long base, limit;
+} cs;
+bool insn_fetch;
+};
+
+static int gate_op_read(
+enum x86_segment seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+struct x86_emulate_ctxt *ctxt)
+{
+const struct gate_op_ctxt *goc =
+container_of(ctxt, struct gate_op_ctxt, ctxt);
+unsigned int rc = bytes, sel = 0;
+unsigned long addr = offset, limit = 0;
+
+switch ( seg )
+{
+case x86_seg_cs:
+addr += goc->cs.base;
+limit = goc->cs.limit;
+break;
+case x86_seg_ds:
+sel = read_sreg(ds);
+break;
+case x86_seg_es:
+sel = read_sreg(es);
+break;
+case x86_seg_fs:
+sel = read_sreg(fs);
+break;
+case x86_seg_gs:
+sel = read_sreg(gs);
+break;
+case x86_seg_ss:
+sel = ctxt->regs->ss;
+break;
+default:
+return X86EMUL_UNHANDLEABLE;
+}
+if ( sel )
+{
+unsigned int ar;
+
+ASSERT(!goc->insn_fetch);
+if ( !read_descriptor(sel, current, , , , 0) ||
+ !(ar & _SEGMENT_S) ||
+ !(ar & _SEGMENT_P) ||
+ ((ar & _SEGMENT_CODE) && !(ar & _SEGMENT_WR)) )
+return X86EMUL_UNHANDLEABLE;
+addr += offset;
+}
+else if ( seg != x86_seg_cs )
+return X86EMUL_UNHANDLEABLE;
+
+/* We don't mean to emulate any branches. */
+if ( limit < bytes - 1 || offset > limit - bytes + 1 )
+return X86EMUL_UNHANDLEABLE;
+
+addr = (uint32_t)addr;
+
+if ( (rc = __copy_from_user(p_data, (void *)addr, bytes)) )
+{
+/*
+ * TODO: This should report PFEC_insn_fetch when goc->insn_fetch &&
+ * cpu_has_nx, but we'd then need a "fetch" 

[Xen-devel] [PATCH for-next v3 00/22] x86: refactor trap handling code

[Wei Liu]

V3 of the series. Rebased on top of x86-next branch.

Patches are broken down into the smallest trunk possible to ease review and
future rebasing.

   git://xenbits.xen.org/people/liuw/xen.git wip.move-traps-v3

Wei Liu (22):
  x86/traps: move privilege instruction emulation code
  x86/traps: move gate op emulation code
  x86/traps: move emulate_invalid_rdtscp
  x86/traps: move emulate_forced_invalid_op
  x86/pv: clean up emulate.c
  x86/traps: move PV hypercall handlers to pv/traps.c
  x86/traps: move pv_inject_event to pv/traps.c
  x86/traps: move set_guest_{machinecheck,nmi}_trapbounce
  x86/traps: move {un,}register_guest_nmi_callback
  x86/traps: delcare percpu softirq_trap
  x86/traps: move guest_has_trap_callback to pv/traps.c
  x86/traps: move send_guest_trap to pv/traps.c
  x86/traps: move toggle_guest_mode
  x86/traps: move do_iret to pv/traps.c
  x86/traps: move init_int80_direct_trap
  x86/traps: move callback_op code
  x86/traps: move hypercall_page_initialise_ring3_kernel
  x86/traps: merge x86_64/compat/traps.c into pv/traps.c
  x86: clean up pv/traps.c
  x86: guest_has_trap_callback should return bool
  x86: fix coding style issues in asm-x86/traps.h
  x86: clean up traps.c

 xen/arch/x86/pv/Makefile   |1 +
 xen/arch/x86/pv/emulate.c  | 1947 
 xen/arch/x86/pv/traps.c| 1014 +++
 xen/arch/x86/traps.c   | 2483 +++-
 xen/arch/x86/x86_64/compat/traps.c |  416 --
 xen/arch/x86/x86_64/traps.c|  288 +
 xen/include/asm-x86/pv/domain.h|7 +
 xen/include/asm-x86/pv/traps.h |   54 +
 xen/include/asm-x86/traps.h|   27 +-
 9 files changed, 3202 insertions(+), 3035 deletions(-)
 create mode 100644 xen/arch/x86/pv/emulate.c
 delete mode 100644 xen/arch/x86/x86_64/compat/traps.c
 create mode 100644 xen/include/asm-x86/pv/traps.h

-- 
2.11.0


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

Re: [Xen-devel] Livepatching and Xen Security

[Ian Jackson]

George Dunlap writes ("Livepatching and Xen Security"):
> # Executive summary

I am completely in agreement with your analysis and your conclusions.

Ian.

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

Re: [Xen-devel] [PATCH v2 3/9] OssTest: Add target_dir_exists

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("Re: [PATCH v2 3/9] OssTest: Add 
target_dir_exists"):
> On Tue, Dec 13, 2016 at 04:24:56PM +, Ian Jackson wrote:
> > Konrad Rzeszutek Wilk writes ("[PATCH v2 3/9] OssTest: Add 
> > target_dir_exists"):
> > > We have target_file_exists but not an equivalant one for directories.
> > > This adds it in and is used in the "ts-xen-build: Make {xen|}dist.tar.gz
> > > only if $builddir/install/{$xen|}install" patch.
> > 
> > Do you care about the distinction between a file and a directory ?
> 
> Yes. I just need to mke sure that the directory exists, while there
> may be multiple files (in it).

No, that wasn't what I meant.  I meant: do you actually need to test
whether the name you are giving to the test refers to a directory, or
simply to tell whether it exists ?

The distinction is only relevant if the object might also
non-erroneously be a file.  (If it's erroneously a file, and you
proceed as if it's a directory, you will crash later.)

> > IOW I don't understand why target_file_exists wouldn't do.
> > 
> > If you think the word "file" in its name is confusing, please feel
> > free to add a doc comment or to rename that function.
> 
> The functions are pretty similar. The file one does 'test -e' while
> this one does 'test -d'.

test -e tests for general existence of things.  I think test -e would
do for you in this case.

Thanks
Ian.

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

Re: [Xen-devel] [PATCH v2 6/9] ts-xen-build: Build the livepatch test-cases

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("Re: [PATCH v2 6/9] ts-xen-build: Build the 
livepatch test-cases"):
> > or something ?
> 
> I ended up doing two patches - one to create an enable_livepatch
> (in mfi-common) to seed the jobs.
> 
> And then another to piggyback on that.
> 
> I am attaching them here (as attachment), and I think it makes
> it simpler?

Why wouldn't you simply always build the live patch if it is
available ?

I don't think this runvar-based system, where the xen version is
tested, is a very good idea.

> @@ -95,6 +96,12 @@ sub checkout () {
> echo >>.config LIBLEAFDIR_x86_64=lib
> echo >>.config KERNELS=''
>  END
> +   (${enable_livepatch} ? < +   if test -f xen/Kconfig; then
> +   echo >>xen/.config CONFIG_LIVEPATCH=y
> +   echo >>xen/.config CONFIG_FAST_SYMBOL_LOOKUP=y
> +fi
> +END

I see you copied this from the xsm build, but I think there is no
reason for osstest to ever build without livepatching support ?  So
this could be unconditional.  You could put it nexst to CONFIG_EXPERT
and _FEP and _VERBOSE_DEBUG.

> +if ($enable_livepatch) {
> +buildcmd_stamped_logged(600, 'xen', 'xenlpt', < +export XEN_ROOT=$builddir/xen
> +export DESTDIR=$builddir/xen/dist/xenlpt
> +export BASEDIR=$builddir/xen/xen
> +mkdir -p \${DESTDIR}/usr/lib/debug
> +END
> +$make_prefix make -C xen/test -f $builddir/xen/xen/Rules.mk 
> install

So here this would need to be conditional.  But it should be
conditional on whether the build can produce it, so use
target_file_exists.

Ian.

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

[Xen-devel] Livepatching and Xen Security

[George Dunlap]

# Executive summary

* It is important for the Livepatching feature to be declared
"security supported".

* At the moment it's not clear whether we can get osstest support in
by the release or not, or if we did whether that would be considered
sufficient to consider it supported

* I would argue that if various vendors can demonstrate that they have
tested the key functionality of the feature in one of the 4.9 RCs at
least as well as osstest would to, that should be sufficient to
declare it security supported for 4.9.

# Why is this important?

Having a feature "security supported" does two things.

First of all, it indicates to users which parts of Xen are considered
safe to use in environments where security is important.

One of the key selling points of Xen is its security compared to other
hypervisors.  But there is a lot of functionality which *can* be
enabled in Xen that isn't really secure: for instance, there are
hundreds of devices emulated by qemu that you *can* enable, but for
which it would not be really safe in the face of a determined
attacker.  Statements of security support help indicate to users which
subset of functionality they should use.

Secondly, it indicates whether a bug discovered in the feature will go
through the XenProject Security Response Process -- i.e., whether it
will be issued an XSA.

Issuing an XSA does two things.  First, it allows people on the
predisclosure list to update their systems before issues are made
known to the entire world.  Secondly, it gives people *not* on the
predisclosure list a structured way of finding out about important
security issues about which they may need to take some action.

# Potential Livepatch security issues

To think about what "security support for Livepatching" means, we have
to have to answer the question, "If there were a security-related bug
in Livepatching, what would it look like?"  This helps us think about
what kind of promises we would give, and what kinds of testing we
would consider necessary to provide security support.

In each case, we must ask: Is this the kind of bug that software
vendors and cloud providers would want embargoed notice for?  Is this
the kind of bug that members not on the pre-disclosure list would like
to be notified of so they can react to quickly?

There are four general areas I think there may be bugs.

## Unprivileged access to Livepatching hypercalls

First, and most obvious, would be a bug that allowed unprivileged
guests access to the livepatching hypercalls.  Livepatching's explicit
purpose is to make it as easy as possible to execute arbitrary code
inside the hypervisor, so any bug which gave an unprivileged guest
access would obviously be a major security issue.

## Bugs in the patch creation tools which create patches with vulnerabilities

Suppose that we have hypervisor version A, which has a security
vulnerability, and a software patch which generates hypervisor version
B, which, when built and booted as a normal binary will not have the
vulnerability.

The livepatch creation tools are designed to help developers create a
binary blob, such that when uploaded into a running copy of hypervisor
A, will cause it to behave like hypervisor B.

But suppose there was a bug in the tools, such that the blob would
successfully upload, but leave open vulnerabilities -- either by not
correctly fixing the original vulnerability, or by opening yet a
different vulnerability.

## Bugs in the patch-application code such that vulnerabilities exist
after application

Suppose instead that we have a binary patch which is correct -- i.e.,
if it were applied as designed it would close the vulnerability and
not open a new one.  But suppose that there was a bug in the patch
application code such that, after the patch process reported success,
known vulnerabilities existed.

As a simple example, suppose that the patch was simply not applied,
but that it was reported as applied anyway.

Or suppose that the patch was applied partially, but not completely.
For instance, say there was an off-by-one error that caused only 2 of
3 required functions to be patched.

Or again, suppose there was a bug in the patch application code such
that, as a side effect of applying the patch and closing the original
vulnerability, a secondary vulnerability was opened up -- say, an
accidental modification to a hypercall table or IDT entries.

## Bugs which allow a guest to prevent the application of a livepatch

In order to apply a patch, the livepatching code first makes several
checks, then pauses the entire system while it finishes the change.
To pause the system, it sends a message to all the other processors
telling them to stop what they're doing, and it waits for them to say
they're ready.

You could imagine a bug in either of these two which might be
triggerably by the guest.  For instance, there could be a bug in the
code which checks whether the livepatch can be applied, such that the
guest can make the check fail.  Or, there 

[Xen-devel] [xen-unstable-smoke test] 109579: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  93ade42f47300f3f353aa9bd59b737bca8f2d342
baseline version:
 xen  a7d4a5904b62731551e366ff62d84759c8ee68e2

Last test of basis   109547  2017-05-17 18:12:36 Z0 days
Failing since109570  2017-05-18 10:02:26 Z0 days3 attempts
Testing same since   109579  2017-05-18 14:17:47 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Samuel Thibault 
  Steven Haigh 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=93ade42f47300f3f353aa9bd59b737bca8f2d342
+ . ./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 xen-unstable-smoke 
93ade42f47300f3f353aa9bd59b737bca8f2d342
+ branch=xen-unstable-smoke
+ revision=93ade42f47300f3f353aa9bd59b737bca8f2d342
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x93ade42f47300f3f353aa9bd59b737bca8f2d342 = 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
++ : 

Re: [Xen-devel] [PATCH v2 6/9] ts-xen-build: Build the livepatch test-cases

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("Re: [PATCH v2 6/9] ts-xen-build: Build the 
livepatch test-cases"):
> So I feel like the only way to figure out whether the livepatch tests cases
> can be built is if I check either the version of Xen (4.9 or above say)
> or if an file exists (xen/xen/test/Makefile).

> Similar to how ovm_enable or xsm_enable is constructed.
> Let me do that.

Yes, this is the right approach.  I would test for a file.

Ian.

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

Re: [Xen-devel] [PATCH] livepatch/Makefile: Add 'install' stanza [and 1 more messages]

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("[PATCH] livepatch/Makefile: Add 'install' 
stanza"):
> So that you can do:
> 
> DESTDIR=`pwd`/dist/xenlptinstall/usr/lib/debug
> mkdir -p $DESTDIR
> BASEDIR=`pwd`/xen XEN_ROOT=`pwd` make -C xen/test -f `pwd`/xen/Rules.mk 
> install

Looking at our other DESTDIR settings, they do not include things like
`/usr/lib/debug'.  Normally DESTDIR seems to be set to `/' or
`$DISTDIR/install' aka `dist/install/'.

How about an interface where that
  make dist-tests
installs things in
  dists/tests
by default, eg
  dists/tests/usr/lib/debug/some-livepath-thing
?

This would probably be achieved by having dist-tests set
DESTDIR=$(DISTDIR)/tests, eg

dist-tests: DESTDIR=$(DISTDIR)/tests
dist-tests: install-tests

Then `make install-tests' should default DESTDIR to / and put things
in /usr/lib/debug.

Jan Beulich writes ("Re: [Xen-devel] [PATCH] livepatch/Makefile: Add 'install' 
stanza"):
> If we really want to provide a standard way to install tests (which
> I'm not sure about, after all these are tests and hence play no
> role during an actual installation),

We need a way to _ship_ tests as a formal deliverable from the build
system.  Consumers of tests (that can be run out of tree, like these)
should not be expected to fish them out of the build tree.

In our existing build system, we ship things with `make dist'.
This ships them into dist/ by using the install targets.

I don't see any reason to diverge from this for tests.  It would be
silly to make special snowflake machinery to ship tests simply to
avoid having a mostly-unused `make install-tests'.  (Obviously `make
install' ought not to run `make install-tests' by default.)

> shouldn't this then at least be
> accompanied by a matching uninstall rule?

I don't think that is necessary.

> Also I think if more stuff is to be added here, this Makefile could
> do with some abstraction (SUBDIR or subdir-y instead of
> explicitly naming the sole current subdirectory) to avoid later
> additions needing to touch all this again.

This is a sensible suggestion.

Ian.

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

[Xen-devel] [PATCH] xen: make xen_flush_tlb_all() static

[Juergen Gross]

xen_flush_tlb_all() is used in arch/x86/xen/mmu.c only. Make it static.

Signed-off-by: Juergen Gross 
---
 arch/x86/xen/mmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 5e375a5e815f..3be06f3caf3c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -42,7 +42,7 @@ xmaddr_t arbitrary_virt_to_machine(void *vaddr)
 }
 EXPORT_SYMBOL_GPL(arbitrary_virt_to_machine);
 
-void xen_flush_tlb_all(void)
+static void xen_flush_tlb_all(void)
 {
struct mmuext_op *op;
struct multicall_space mcs;
-- 
2.12.0


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

Re: [Xen-devel] [PATCH] Use non-debug build for Xen 4.9

[Wei Liu]

On Thu, May 18, 2017 at 04:38:29PM +0100, Julien Grall wrote:
> Modify Config.mk and Kconfig.debug to disable debug by default in
> preparation for late RCs and eventual release.
> 
> Signed-off-by: Julien Grall 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH] Use non-debug build for Xen 4.9

[Julien Grall]

Modify Config.mk and Kconfig.debug to disable debug by default in
preparation for late RCs and eventual release.

Signed-off-by: Julien Grall 
---
 tools/Rules.mk| 2 +-
 xen/Kconfig.debug | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/Rules.mk b/tools/Rules.mk
index f55fb669b8..c3fdbc4d4f 100644
--- a/tools/Rules.mk
+++ b/tools/Rules.mk
@@ -30,7 +30,7 @@ CFLAGS_xeninclude = -I$(XEN_INCLUDE)
 XENSTORE_XENSTORED ?= y
 
 # A debug build of tools?
-debug ?= y
+debug ?= n
 debug_symbols ?= $(debug)
 
 # Set CONFIG_GOLANG=y in .config (or in make) to build golang
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 689f2974c0..e01a194091 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -3,7 +3,7 @@ menu "Debugging Options"
 
 config DEBUG
bool "Developer Checks"
-   default y
+   default n
---help---
  If you say Y here this will enable developer checks such as asserts
  and extra printks. This option is intended for development purposes
-- 
2.11.0


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

[Xen-devel] [libvirt test] 109561: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  ca21d75d25e04422e434828344924b914ea21ca9
baseline version:
 libvirt  bb09afd5a2c5fc8b4869b27b0c723b544be810ae

Last test of basis   109516  2017-05-17 04:20:58 Z1 days
Testing same since   109561  2017-05-18 04:24:18 Z0 days1 attempts


People who touched revisions under test:
  Gordon Messmer 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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

[Xen-devel] [PATCH v2 0/3] xen/blkback: several fixes of resource management

[Juergen Gross]

Destroying a Xen guest domain while it was doing I/Os via xen-blkback
leaked several resources, including references of the guest's memory
pages.

This patch series addresses those leaks by correcting usage of
reference counts and the sequence when to free which resource.

The series applies on top of commit 2d4456c73a487abe ("block:
xen-blkback: add null check to avoid null pointer dereference") in
Jens Axboe's tree kernel/git/axboe/linux-block.git

V2: changed flag to type bool in patch 1 (Dietmar Hahn)

Juergen Gross (3):
  xen/blkback: fix disconnect while I/Os in flight
  xen/blkback: don't free be structure too early
  xen/blkback: don't use xen_blkif_get() in xen-blkback kthread

 drivers/block/xen-blkback/blkback.c |  3 ---
 drivers/block/xen-blkback/common.h  |  1 +
 drivers/block/xen-blkback/xenbus.c  | 15 ---
 3 files changed, 9 insertions(+), 10 deletions(-)

-- 
2.12.0


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

[Xen-devel] [PATCH v2 2/3] xen/blkback: don't free be structure too early

[Juergen Gross]

The be structure must nor be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).

Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
---
 drivers/block/xen-blkback/xenbus.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 998915174bb8..4cdf0490983e 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -315,9 +315,10 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
 
 static void xen_blkif_free(struct xen_blkif *blkif)
 {
-
-   xen_blkif_disconnect(blkif);
+   WARN_ON(xen_blkif_disconnect(blkif));
xen_vbd_free(>vbd);
+   kfree(blkif->be->mode);
+   kfree(blkif->be);
 
/* Make sure everything is drained before shutting down */
kmem_cache_free(xen_blkif_cachep, blkif);
@@ -514,8 +515,6 @@ static int xen_blkbk_remove(struct xenbus_device *dev)
xen_blkif_put(be->blkif);
}
 
-   kfree(be->mode);
-   kfree(be);
return 0;
 }
 
-- 
2.12.0


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

[Xen-devel] [PATCH v2 1/3] xen/blkback: fix disconnect while I/Os in flight

[Juergen Gross]

Today disconnecting xen-blkback is broken in case there are still
I/Os in flight: xen_blkif_disconnect() will bail out early without
releasing all resources in the hope it will be called again when
the last request has terminated. This, however, won't happen as
xen_blkif_free() won't be called on termination of the last running
request: xen_blkif_put() won't decrement the blkif refcnt to 0 as
xen_blkif_disconnect() didn't finish before thus some xen_blkif_put()
calls in xen_blkif_disconnect() didn't happen.

To solve this deadlock xen_blkif_disconnect() and
xen_blkif_alloc_rings() shouldn't use xen_blkif_put() and
xen_blkif_get() but use some other way to do their accounting of
resources.

This at once fixes another error in xen_blkif_disconnect(): when it
returned early with -EBUSY for another ring than 0 it would call
xen_blkif_put() again for already handled rings on a subsequent call.
This will lead to inconsistencies in the refcnt handling.

Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
---
 drivers/block/xen-blkback/common.h | 1 +
 drivers/block/xen-blkback/xenbus.c | 7 +--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkback/common.h 
b/drivers/block/xen-blkback/common.h
index dea61f6ab8cb..638597b17a38 100644
--- a/drivers/block/xen-blkback/common.h
+++ b/drivers/block/xen-blkback/common.h
@@ -281,6 +281,7 @@ struct xen_blkif_ring {
 
wait_queue_head_t   wq;
atomic_tinflight;
+   boolactive;
/* One thread per blkif ring. */
struct task_struct  *xenblkd;
unsigned intwaiting_reqs;
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 1f3dfaa54d87..998915174bb8 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -159,7 +159,7 @@ static int xen_blkif_alloc_rings(struct xen_blkif *blkif)
init_waitqueue_head(>shutdown_wq);
ring->blkif = blkif;
ring->st_print = jiffies;
-   xen_blkif_get(blkif);
+   ring->active = true;
}
 
return 0;
@@ -249,6 +249,9 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
struct xen_blkif_ring *ring = >rings[r];
unsigned int i = 0;
 
+   if (!ring->active)
+   continue;
+
if (ring->xenblkd) {
kthread_stop(ring->xenblkd);
wake_up(>shutdown_wq);
@@ -296,7 +299,7 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
BUG_ON(ring->free_pages_num != 0);
BUG_ON(ring->persistent_gnt_c != 0);
WARN_ON(i != (XEN_BLKIF_REQS_PER_PAGE * blkif->nr_ring_pages));
-   xen_blkif_put(blkif);
+   ring->active = false;
}
blkif->nr_ring_pages = 0;
/*
-- 
2.12.0


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

[Xen-devel] [PATCH v2 3/3] xen/blkback: don't use xen_blkif_get() in xen-blkback kthread

[Juergen Gross]

There is no need to use xen_blkif_get()/xen_blkif_put() in the kthread
of xen-blkback. Thread stopping is synchronous and using the blkif
reference counting in the kthread will avoid to ever let the reference
count drop to zero at the end of an I/O running concurrent to
disconnecting and multiple rings.

Setting ring->xenblkd to NULL after stopping the kthread isn't needed
as the kthread does this already.

Signed-off-by: Juergen Gross 
Tested-by: Steven Haigh 
Acked-by: Roger Pau Monné 
---
 drivers/block/xen-blkback/blkback.c | 3 ---
 drivers/block/xen-blkback/xenbus.c  | 1 -
 2 files changed, 4 deletions(-)

diff --git a/drivers/block/xen-blkback/blkback.c 
b/drivers/block/xen-blkback/blkback.c
index 726c32e35db9..6b14c509f3c7 100644
--- a/drivers/block/xen-blkback/blkback.c
+++ b/drivers/block/xen-blkback/blkback.c
@@ -609,8 +609,6 @@ int xen_blkif_schedule(void *arg)
unsigned long timeout;
int ret;
 
-   xen_blkif_get(blkif);
-
set_freezable();
while (!kthread_should_stop()) {
if (try_to_freeze())
@@ -665,7 +663,6 @@ int xen_blkif_schedule(void *arg)
print_stats(ring);
 
ring->xenblkd = NULL;
-   xen_blkif_put(blkif);
 
return 0;
 }
diff --git a/drivers/block/xen-blkback/xenbus.c 
b/drivers/block/xen-blkback/xenbus.c
index 4cdf0490983e..792da683e70d 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-blkback/xenbus.c
@@ -255,7 +255,6 @@ static int xen_blkif_disconnect(struct xen_blkif *blkif)
if (ring->xenblkd) {
kthread_stop(ring->xenblkd);
wake_up(>shutdown_wq);
-   ring->xenblkd = NULL;
}
 
/* The above kthread_stop() guarantees that at this point we
-- 
2.12.0


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

Re: [Xen-devel] Questions about PVHv2/HVMlite

[Roger Pau Monné]

On Thu, May 18, 2017 at 09:48:02AM -0500, Gary R Hook wrote:
> On 05/18/2017 03:16 AM, Roger Pau Monné wrote:
> > 
> > So using your example, the config file should look like:
> > 
> > extra = "root=/dev/xvda1 console=hvc0"
> > kernel = "/root/64/vmlinuz-4.11.0-pvh+"
> > ramdisk = "/root/64/initrd.img-4.11.0-pvh+"
> > builder="hvm"
> > device_model_version="none"
> > memory = 4096
> > name = "sospv2"
> > vcpus = 8
> > vif = ['']
> > disk = ['phy:/dev/vg0/pvclient2,xvda,w']
> 
> Well, huzzah!
> 
> amd@sospvclient2:~$ dmesg | grep -i xen
> [0.00] Hypervisor detected: Xen
> [0.00] Xen version 4.9.
> [0.00] Xen Platform PCI: unrecognised magic value
> [0.00] ACPI: RSDP 0x000FFFC0 24 (v02 Xen   )
> [0.00] ACPI: XSDT 0xFC007FA0 34 (v01 XenHVM 
> HVML )
> [0.00] ACPI: FACP 0xFC007D70 00010C (v05 XenHVM 
> HVML )
> [0.00] ACPI: DSDT 0xFC001050 006C9B (v05 XenHVM 
> INTL 20140214)
> [0.00] ACPI: APIC 0xFC007E80 6C (v02 XenHVM 
> HVML )
> [0.00] Booting paravirtualized kernel on Xen PVH
> [0.00] xen: PV spinlocks enabled
>  ^^^
> 
> 
> > This is a temporary interface, and it's not stable.
> 
> "Stable" as in syntax and keywords are subject to change?

"not stable" as in device_model_version="none" will stop working at some point
(because xl/libxl will only understand pvh=1).

> >  Long term PVH guest should
> > be created using "pvh=1", sadly this has not yet been implemented.
> 
> Do I understand this to mean that using "pvh=1" in the config file hasn't
> been wired
> up to do everything needed to create a PVH guest?

That's right, the pvh option doesn't exist ATM.

> Is there more to be done
> besides
> turning that parameter into "builder='hvm" device_model_version="none"?

Hm, no, pvh=1 should be a guest type in libxl, so there's more to it. It should
have it's own libxl_domain_type, and it's own struct in
libxl_domain_build_info. Boris was working on this, he might be able to share
some more info.

> Or,
> better yet,
> are there any design notes on this?

The interface it's not yet clear, it's very likely that we will have a design
discussion about this in the upcoming XenSummit.

Roger.

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

Re: [Xen-devel] [PATCH v2 for-4.9] x86/pagewalk: Fix determination of Protection Key access rights

[Andrew Cooper]

On 18/05/17 15:31, Tim Deegan wrote:
> Hi,
>
> At 15:02 +0100 on 18 May (1495119734), Andrew Cooper wrote:
>>  * When fabricating gl1e's from superpages, propagate the protection key as
>>well, so the protection key logic sees the real key as opposed to 0.
>>
>>  * Experimentally, the protection key checks are performed ahead of the other
>>access rights.  In particular, accesses which fail both protection key and
>>regular permission checks yield PFEC_prot_key in the resulting pagefault.
>>
>>  * Protection keys apply to all user mode data accesses, including accesses
>>from supervisor code.
> I think this would be clearer as "all data accesses to user-mode addresses".

Done.

>
>>  PKRU WD applies to any data write, not just to
>>mapping which are writable.  However, a supervisor access without CR0.WP
>>bypasses any protection from protection keys.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Tim Deegan 

Thanks.

~Andrew

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

Re: [Xen-devel] [PATCH v3 for-4.9 0/3] libxl/devd: bugfixes

[Wei Liu]

On Thu, May 18, 2017 at 04:06:33PM +0100, Julien Grall wrote:
> (CC Ian and Wei)
> 

I did see this. Ian said he wanted to review this in detail. That's why
I haven't committed them.

> On 17/05/17 15:02, Julien Grall wrote:
> > On 16/05/17 08:59, Roger Pau Monne wrote:
> > > Hello,
> > 
> > Hi Roger,
> > 
> > > 
> > > The first two patches in the series fix a race with concurrent device
> > > addition/removal and two bugs related to manipulation of the list of
> > > active
> > > domains in the devd subcommand. The last patch is not a bugfix itself,
> > > but
> > > it makes the code easier to understand.
> > > 
> > > IMHO they should be part of 4.9 because they are confined to devd
> > > code, and
> > > without them devd is unusable (it's trivial to segfault it), so the
> > > risk is
> > > low. Worse thing that could happen is that devd crashes, which is
> > > already the
> > > case without them.
> > 
> > For the first 2 patches:
> > 
> > Release-acked-by: Julien Grall 
> > 
> > For the last patch, at this stage of the release I would prefer to defer
> > it for Xen 4.10.
> > 
> > Cheers,
> > 
> 
> -- 
> Julien Grall
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH 0/3] gcc 7 build fixes (hypervisor side)

[Julien Grall]

Hi Jan,

On 18/05/17 09:01, Jan Beulich wrote:

I think it would be good for 4.9 to build out of the box with this recently
released compiler version.

1: xmalloc: correct _xmalloc_array() indentation
2: x86: fix build with gcc 7
3: arm: fix build with gcc 7

Signed-off-by: Jan Beulich 


For the 3 fixes:

Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] arm: fix build with gcc 7

[Julien Grall]

Hi,

On 18/05/17 09:41, Jan Beulich wrote:

The compiler dislikes duplicat "const", and the ones it complains about


s/duplicat/duplicate/


look like they we in fact meant to be placed differently.

Also fix array_access_okay() (just like on x86), despite the construct
being unused on ARM: -Wint-in-bool-context, enabled by default in
gcc 7, doesn't like multiplication in conditional operators. "Hide" it,
at the risk of the next compiler version becoming smarter and
recognizing even that. (The hope is that added smartness then would
also better deal with legitimate cases like the one here.) The change
could have been done in access_ok(), but I think we better keep it at
the place the compiler is actually unhappy about.


I am wondering if we should drop array_access_ok and access_ok as they 
are not used.


Anyway, I am happy with both way:

Reviewed-by: Julien Grall 

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH 3/3] libxc: Add support for the altp2m suppress #VE hvmop

[Adrian Pop]

This adds a wrapper for issuing HVMOP_altp2m_set_suppress_ve from a
domain.

Signed-off-by: Adrian Pop 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_altp2m.c   | 24 
 2 files changed, 26 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 2d97d36c38..5e1e4cfa81 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1923,6 +1923,8 @@ int xc_altp2m_destroy_view(xc_interface *handle, domid_t 
domid,
 /* Switch all vCPUs of the domain to the specified altp2m view */
 int xc_altp2m_switch_to_view(xc_interface *handle, domid_t domid,
  uint16_t view_id);
+int xc_altp2m_set_suppress_ve(xc_interface *handle, domid_t domid,
+  uint16_t view_id, xen_pfn_t gfn, uint8_t sve);
 int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t gfn,
  xenmem_access_t access);
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 0639632477..b0f3e344af 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -163,6 +163,30 @@ int xc_altp2m_switch_to_view(xc_interface *handle, domid_t 
domid,
 return rc;
 }
 
+int xc_altp2m_set_suppress_ve(xc_interface *handle, domid_t domid,
+  uint16_t view_id, xen_pfn_t gfn, uint8_t sve)
+{
+int rc;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+
+arg = xc_hypercall_buffer_alloc(handle, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_suppress_ve;
+arg->domain = domid;
+arg->u.set_suppress_ve.view = view_id;
+arg->u.set_suppress_ve.gfn = gfn;
+arg->u.set_suppress_ve.suppress_ve = sve;
+
+rc = xencall2(handle->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(handle, arg);
+return rc;
+}
+
 int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t gfn,
  xenmem_access_t access)
-- 
2.12.1


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

[Xen-devel] [PATCH 0/3] x86: Add a hvmop for setting the #VE suppress bit

[Adrian Pop]

As the code stands right now, after DomU has enabled #VE using
HVMOP_altp2m_vcpu_enable_notify, all its pages have the #VE suppress bit
cleared, generating #VEs for any EPT violation.  There is currently no
way to change the value of the #VE suppress bit for a page from a
domain; it can only be done in Xen internally using ept_set_entry().

Following the discussion from
https://lists.xen.org/archives/html/xen-devel/2017-03/msg01312.html this
patch introduces a new hvmop to set this bit and thus have control over
which pages generate #VE and which VM-Exit.

I'm not sure whether it's best to define p2m_set_suppress_ve() in
mem_access.c since this file contains common functions for x86 (vmx &
svm) and the function is Intel-specific.

Adrian Pop (2):
  x86/altp2m: Add a hvmop for setting the suppress #VE bit
  libxc: Add support for the altp2m suppress #VE hvmop

Vlad Ioan Topan (1):
  x86/mm: Change default value for suppress #VE in set_mem_access()

 tools/libxc/include/xenctrl.h   |  2 ++
 tools/libxc/xc_altp2m.c | 24 +++
 xen/arch/x86/hvm/hvm.c  | 14 +++
 xen/arch/x86/mm/mem_access.c| 51 +++--
 xen/include/public/hvm/hvm_op.h | 15 
 xen/include/xen/mem_access.h|  3 +++
 6 files changed, 107 insertions(+), 2 deletions(-)

-- 
2.12.1


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

[Xen-devel] [PATCH 2/3] x86/altp2m: Add a hvmop for setting the suppress #VE bit

[Adrian Pop]

Introduce a new hvmop, HVMOP_altp2m_set_suppress_ve, which allows a
domain to change the value of the #VE suppress bit for a page.

Signed-off-by: Adrian Pop 
---
 xen/arch/x86/hvm/hvm.c  | 14 
 xen/arch/x86/mm/mem_access.c| 48 +
 xen/include/public/hvm/hvm_op.h | 15 +
 xen/include/xen/mem_access.h|  3 +++
 4 files changed, 80 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 2e76c2345b..eb01527c5b 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4356,6 +4356,7 @@ static int do_altp2m_op(
 case HVMOP_altp2m_destroy_p2m:
 case HVMOP_altp2m_switch_p2m:
 case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_set_suppress_ve:
 case HVMOP_altp2m_change_gfn:
 break;
 default:
@@ -4472,6 +4473,19 @@ static int do_altp2m_op(
 a.u.set_mem_access.view);
 break;
 
+case HVMOP_altp2m_set_suppress_ve:
+if ( a.u.set_suppress_ve.pad1 || a.u.set_suppress_ve.pad2 )
+rc = -EINVAL;
+else
+{
+gfn_t gfn = _gfn(a.u.set_mem_access.gfn);
+unsigned int altp2m_idx = a.u.set_mem_access.view;
+uint8_t suppress_ve = a.u.set_suppress_ve.suppress_ve;
+
+rc = p2m_set_suppress_ve(d, gfn, suppress_ve, altp2m_idx);
+}
+break;
+
 case HVMOP_altp2m_change_gfn:
 if ( a.u.change_gfn.pad1 || a.u.change_gfn.pad2 )
 rc = -EINVAL;
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index d0b0767855..b9e611d3db 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -466,6 +466,54 @@ int p2m_get_mem_access(struct domain *d, gfn_t gfn, 
xenmem_access_t *access)
 }
 
 /*
+ * Set/clear the #VE suppress bit for a page.  Only available on VMX.
+ */
+int p2m_set_suppress_ve(struct domain *d, gfn_t gfn, uint8_t suppress_ve,
+unsigned int altp2m_idx)
+{
+struct p2m_domain *host_p2m = p2m_get_hostp2m(d);
+struct p2m_domain *ap2m = NULL;
+struct p2m_domain *p2m = NULL;
+mfn_t mfn;
+p2m_access_t a;
+p2m_type_t t;
+unsigned long gfn_l;
+int rc = 0;
+
+if ( !cpu_has_vmx )
+return -EOPNOTSUPP;
+
+if ( altp2m_idx > 0 )
+{
+if ( altp2m_idx >= MAX_ALTP2M ||
+d->arch.altp2m_eptp[altp2m_idx] == mfn_x(INVALID_MFN) )
+return -EINVAL;
+
+p2m = ap2m = d->arch.altp2m_p2m[altp2m_idx];
+}
+else
+{
+p2m = host_p2m;
+}
+
+p2m_lock(host_p2m);
+if ( ap2m )
+p2m_lock(ap2m);
+
+gfn_l = gfn_x(gfn);
+mfn = p2m->get_entry(p2m, gfn_l, , , 0, NULL, NULL);
+if ( !mfn_valid(mfn) )
+return -ESRCH;
+rc = p2m->set_entry(p2m, gfn_l, mfn, PAGE_ORDER_4K, t, a,
+suppress_ve);
+if ( ap2m )
+p2m_unlock(ap2m);
+p2m_unlock(host_p2m);
+
+return rc;
+}
+
+/*
  * Local variables:
  * mode: C
  * c-file-style: "BSD"
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index bc00ef0e65..9736092f58 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -231,6 +231,18 @@ struct xen_hvm_altp2m_set_mem_access {
 typedef struct xen_hvm_altp2m_set_mem_access xen_hvm_altp2m_set_mem_access_t;
 DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_mem_access_t);
 
+struct xen_hvm_altp2m_set_suppress_ve {
+/* view */
+uint16_t view;
+uint8_t suppress_ve;
+uint8_t pad1;
+uint32_t pad2;
+/* gfn */
+uint64_t gfn;
+};
+typedef struct xen_hvm_altp2m_set_suppress_ve xen_hvm_altp2m_set_suppress_ve_t;
+DEFINE_XEN_GUEST_HANDLE(xen_hvm_altp2m_set_suppress_ve_t);
+
 struct xen_hvm_altp2m_change_gfn {
 /* view */
 uint16_t view;
@@ -262,6 +274,8 @@ struct xen_hvm_altp2m_op {
 #define HVMOP_altp2m_set_mem_access   7
 /* Change a p2m entry to have a different gfn->mfn mapping */
 #define HVMOP_altp2m_change_gfn   8
+/* Set the "Suppress #VE" bit on a page */
+#define HVMOP_altp2m_set_suppress_ve  9
 domid_t domain;
 uint16_t pad1;
 uint32_t pad2;
@@ -270,6 +284,7 @@ struct xen_hvm_altp2m_op {
 struct xen_hvm_altp2m_vcpu_enable_notify enable_notify;
 struct xen_hvm_altp2m_view   view;
 struct xen_hvm_altp2m_set_mem_access set_mem_access;
+struct xen_hvm_altp2m_set_suppress_veset_suppress_ve;
 struct xen_hvm_altp2m_change_gfn change_gfn;
 uint8_t pad[64];
 } u;
diff --git a/xen/include/xen/mem_access.h b/xen/include/xen/mem_access.h
index 5ab34c1553..b6e6a7650a 100644
--- a/xen/include/xen/mem_access.h
+++ b/xen/include/xen/mem_access.h
@@ -78,6 +78,9 @@ long p2m_set_mem_access_multi(struct domain *d,
  */
 int p2m_get_mem_access(struct domain *d, gfn_t gfn, xenmem_access_t *access);
 
+int p2m_set_suppress_ve(struct domain 

[Xen-devel] [PATCH 1/3] x86/mm: Change default value for suppress #VE in set_mem_access()

[Adrian Pop]

From: Vlad Ioan Topan 

The default value for the "suppress #VE" bit set by set_mem_access()
currently depends on whether the call is made from the same domain (the
bit is set when called from another domain and cleared if called from
the same domain). This patch changes that behavior to inherit the old
suppress #VE bit value if it is already set and to set it to 1
otherwise, which is safer and more reliable.

Signed-off-by: Vlad Ioan Topan 
Signed-off-by: Adrian Pop 
---
 xen/arch/x86/mm/mem_access.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 5adaf6df90..d0b0767855 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -273,8 +273,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
p2m_domain *hp2m,
 }
 }
 
-return ap2m->set_entry(ap2m, gfn_l, mfn, PAGE_ORDER_4K, t, a,
- (current->domain != d));
+return ap2m->set_entry(ap2m, gfn_l, mfn, PAGE_ORDER_4K, t, a, -1);
 }
 
 static int set_mem_access(struct domain *d, struct p2m_domain *p2m,
-- 
2.12.1


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

Re: [Xen-devel] [PATCH v3 for-4.9 0/3] libxl/devd: bugfixes

[Julien Grall]

(CC Ian and Wei)

On 17/05/17 15:02, Julien Grall wrote:

On 16/05/17 08:59, Roger Pau Monne wrote:

Hello,


Hi Roger,



The first two patches in the series fix a race with concurrent device
addition/removal and two bugs related to manipulation of the list of
active
domains in the devd subcommand. The last patch is not a bugfix itself,
but
it makes the code easier to understand.

IMHO they should be part of 4.9 because they are confined to devd
code, and
without them devd is unusable (it's trivial to segfault it), so the
risk is
low. Worse thing that could happen is that devd crashes, which is
already the
case without them.


For the first 2 patches:

Release-acked-by: Julien Grall 

For the last patch, at this stage of the release I would prefer to defer
it for Xen 4.10.

Cheers,



--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/3] xen/blkback: several fixes of resource management

[Juergen Gross]

On 18/05/17 16:38, Roger Pau Monné wrote:
> On Tue, May 16, 2017 at 08:23:17AM +0200, Juergen Gross wrote:
>> Destroying a Xen guest domain while it was doing I/Os via xen-blkback
>> leaked several resources, including references of the guest's memory
>> pages.
>>
>> This patch series addresses those leaks by correcting usage of
>> reference counts and the sequence when to free which resource.
>>
>> The series applies on top of commit 2d4456c73a487abe ("block:
>> xen-blkback: add null check to avoid null pointer dereference") in
>> Jens Axboe's tree kernel/git/axboe/linux-block.git
>>
>> Juergen Gross (3):
>>   xen/blkback: fix disconnect while I/Os in flight
>>   xen/blkback: don't free be structure too early
>>   xen/blkback: don't use xen_blkif_get() in xen-blkback kthread
> 
> All 3:
> 
> Acked-by: Roger Pau Monné 
> 
> The comment reported by Dietmar in patch #1 would be nice to fix.

Okay, I'll send V2 soon.


Juergen


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

[Xen-devel] [ovmf baseline-only test] 71343: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt   5 libvirt-buildfail   like 71342
 build-i386-libvirt5 libvirt-buildfail   like 71342

version targeted for testing:
 ovmf 7a85e8474127ae6df47337a04797b2b443b57682
baseline version:
 ovmf 11a6cc5bda811513d2fbe47d8cb1a70b48077800

Last test of basis71342  2017-05-18 06:51:54 Z0 days
Testing same since71343  2017-05-18 13:19:36 Z0 days1 attempts


People who touched revisions under test:
  Dandan Bi 
  Laszlo Ersek 

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



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

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

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


Push not applicable.


commit 7a85e8474127ae6df47337a04797b2b443b57682
Author: Dandan Bi 
Date:   Thu May 18 09:51:42 2017 +0800

MdeModulePkg/PciHostBridgeDxe: Fix EBC build failure

Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Jiewen Yao 

commit 639c7dd86d1d63a6c4ac5f19f8a97986aa1f363b
Author: Laszlo Ersek 
Date:   Sun Mar 12 23:59:04 2017 +0100

OvmfPkg: resolve PcdLib for PEIMs to PeiPcdLib by default

In the previous patch we had to add two explicit Null resolutions, but
here we can remove five PeiPcdLib ones, after setting the default to it.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

commit fbce1fe983f6d0cc10607c533d1bd09c4bceba0a
Author: Laszlo Ersek 
Date:   Sun Mar 12 23:52:28 2017 +0100

OvmfPkg: resolve PcdLib for all PEIMs individually

Currently the default (module type independent) PcdLib resolution is to
BasePcdLibNull.inf, which is inherited by all PEIMs. In the next patch,
we'll flip the PEIM default resolution to PeiPcdLib.inf, but in order to
keep that patch both correct and simple to review, we should spell out the
Null resolution for those two PEIMs (ReportStatusCodeRouterPei and
StatusCodeHandlerPei) that are now the only ones that don't specify an
explicit resolution.

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

commit 5e167d7e784c92591921c29b61f0f7a000d9c7ce
Author: Laszlo Ersek 
Date:   Sun Mar 12 22:01:40 2017 +0100

OvmfPkg/PlatformPei: don't allocate reserved mem varstore if SMM_REQUIRE

For the emulated variable store, PlatformPei allocates reserved memory (as
early as possible, so that the address remains the same during reboot),
and PcdEmuVariableNvStoreReserved carries the address to
EmuVariableFvbRuntimeDxe.

However, EmuVariableFvbRuntimeDxe is excluded from the SMM_REQUIRE build,
and then noone consumes PcdEmuVariableNvStoreReserved. Don't waste
reserved memory whenever that's the case.

(Even a dynamic default for PcdEmuVariableNvStoreReserved would be
unnecessary; but that way the PcdSet64S() call in the
ReserveEmuVariableNvStore() function doesn't compile.)

Cc: Jordan Justen 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
Reviewed-by: Jordan Justen 

commit 

Re: [Xen-devel] [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu

[Dario Faggioli]

On Thu, 2017-05-18 at 07:16 -0600, Jan Beulich wrote:
> > > > On 18.05.17 at 15:03,  wrote:
> > 
> > As I said last time, I'd rename cpu_callback() to something less
> > generic, like vpmu_cpu_callback() (or vpmu_cpuhp_callback()).
> 
> The vpmu_ prefix is clearly pointless for a static function.
> 
And "just" using cpu_callback is what we do in a lot of (although, not
everywhere :-( ) other places:

xen/common/timer.c:.notifier_call = cpu_callback,
xen/common/kexec.c:.notifier_call = cpu_callback
xen/common/cpupool.c:.notifier_call = cpu_callback
xen/arch/x86/hvm/hvm.c:.notifier_call = cpu_callback
xen/arch/x86/cpu/mcheck/mce_intel.c:.notifier_call = cpu_callback
xen/common/stop_machine.c:.notifier_call = cpu_callback
xen/common/tmem_xen.c:.notifier_call = cpu_callback
xen/common/tasklet.c:.notifier_call = cpu_callback,
xen/common/trace.c:.notifier_call = cpu_callback
xen/drivers/passthrough/io.c:.notifier_call = cpu_callback,
xen/drivers/cpufreq/cpufreq.c:.notifier_call = cpu_callback

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] xen/arm: Hiding SMMUs from Dom0 when using ACPI on Xen

[Julien Grall]

Hello,

On 18/05/17 12:59, Manish Jaggi wrote:

On 2/27/2017 11:42 PM, Julien Grall wrote:

On 02/27/2017 04:58 PM, Shanker Donthineni wrote:

Hi Julien,


Hi Shanker,

Please don't drop people in CC. In my case, any e-mail I am not CCed
are skipping my inbox and I may not read them for a while.



On 02/27/2017 08:12 AM, Julien Grall wrote:



On 27/02/17 13:23, Vijay Kilari wrote:

Hi Julien,


Hello Vijay,


On Wed, Feb 22, 2017 at 7:40 PM, Julien Grall 
wrote:

Hello,

There was few discussions recently about hiding SMMUs from DOM0 when
using
ACPI. I thought it would be good to have a separate thread for this.

When using ACPI, the SMMUs will be described in the IO Remapping
Table
(IORT). The specification can be found on the ARM website [1].

For a brief summary, the IORT can be used to discover the SMMUs
present on
the platform and find for a given device the ID to configure
components such
as ITS (DeviceID) and SMMU (StreamID).

The appendix A in the specification gives an example how DeviceID and
StreamID can be found. For instance, when a PCI device is both
protected by
an SMMU and MSI-capable the following translation will happen:
RID -> StreamID -> DeviceID

Currently, SMMUs are hidden from DOM0 because they are been used by
Xen and
we don't support stage-1 SMMU. If we pass the IORT as it is, DOM0
will try
to initialize SMMU and crash.

I first thought about using a Xen specific way (STAO) or extending a
flag in
IORT. But that is not ideal.

So we would have to rewrite the IORT for DOM0. Given that a range of
RID can
mapped to multiple ranges of DeviceID, we would have to translate
RID one by
one to find the associated DeviceID. I think this may end up to
complex code
and have a big IORT table.


Why can't we replace Output base of IORT of PCI node with SMMU output
base?.
I mean similar to PCI node without SMMU, why can't replace output base
of PCI node with
SMMU's output base?.


Because I don't see anything in the spec preventing one RC ID mapping
to produce multiple SMMU ID mapping. So which output base would you
use?



Basically, remove SMMU nodes, and replaces output of the PCIe and named
nodes ID mappings with ITS nodes.

RID --> StreamID  --> dviceID  --> ITS device id = RID --> dviceID  -->
ITS device id


Can you detail it? You seem to assume that one RC ID mapping range
will only produce ID mapping range. AFAICT, this is not mandated by
the spec.


You are correct that it is not mandated by the spec, but AFAIK there
seems to be no valid use case for that.


Xen has to be compliant with the spec, if the spec says something then 
we should do it unless there is a strong reason not to.


In this case, it is not too difficult to implement the suggestion I 
wrote a couple of months ago. So why would we try to put us in a corner?




RID range should not overlap between ID Array entries.


I believe you misunderstood my point here. So let me give an example. My 
understanding of the spec is it is possible to have:


RC A
 // doesn't use SMMU 0 so just outputs DeviceIDs to ITS GROUP 0
 // Input ID --> Output reference: Output ID
0x-0x --> ITS GROUP 0 : 0x->0x

SMMU 0
// Note that range of StreamIDs that map to DeviceIDs excludes
// the NIC 0 DeviceID as it does not generate MSIs
 // Input ID --> Output reference: Output ID
0x-0x01ff --> ITS GROUP 0 : 0x1->0x101ff
0x0200-0x --> ITS GROUP 0 : 0x2->0x207ff

// SMMU 0 Control interrupt is MSI based
 // Input ID --> Output reference: Output ID
N/A --> ITS GROUP 0 : 0x21


I believe this would be updated in the next IORT spec revision.


Well, Xen should still support current revision of IORT even if the next 
version add more restriction.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/3] xen/blkback: several fixes of resource management

[Roger Pau Monné]

On Tue, May 16, 2017 at 08:23:17AM +0200, Juergen Gross wrote:
> Destroying a Xen guest domain while it was doing I/Os via xen-blkback
> leaked several resources, including references of the guest's memory
> pages.
> 
> This patch series addresses those leaks by correcting usage of
> reference counts and the sequence when to free which resource.
> 
> The series applies on top of commit 2d4456c73a487abe ("block:
> xen-blkback: add null check to avoid null pointer dereference") in
> Jens Axboe's tree kernel/git/axboe/linux-block.git
> 
> Juergen Gross (3):
>   xen/blkback: fix disconnect while I/Os in flight
>   xen/blkback: don't free be structure too early
>   xen/blkback: don't use xen_blkif_get() in xen-blkback kthread

All 3:

Acked-by: Roger Pau Monné 

The comment reported by Dietmar in patch #1 would be nice to fix.

Roger.

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

Re: [Xen-devel] [xen-4.8-testing test] 109515: tolerable FAIL - PUSHED

[Ian Jackson]

Julien Grall writes ("Re: [Xen-devel] [xen-4.8-testing test] 109515: tolerable 
FAIL - PUSHED"):
> The arm64 jobs are blocked because of the missing ocamlopt
> package. I think testing Xen 4.8 would be good so we may want to
> backport the patch 4d0240e033 "tools: ocaml: In configure, check for
> ocamlopt". I have noticed similar build failure on Xen 4.7 (Xen 4.6
> does not seem to have arm64 test).

Thanks.  I have backported that change to 4.8 and 4.7.

Ian.

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

Re: [Xen-devel] Questions about PVHv2/HVMlite

[Gary R Hook]

On 05/18/2017 03:16 AM, Roger Pau Monné wrote:


So using your example, the config file should look like:

extra = "root=/dev/xvda1 console=hvc0"
kernel = "/root/64/vmlinuz-4.11.0-pvh+"
ramdisk = "/root/64/initrd.img-4.11.0-pvh+"
builder="hvm"
device_model_version="none"
memory = 4096
name = "sospv2"
vcpus = 8
vif = ['']
disk = ['phy:/dev/vg0/pvclient2,xvda,w']


Well, huzzah!

amd@sospvclient2:~$ dmesg | grep -i xen
[0.00] Hypervisor detected: Xen
[0.00] Xen version 4.9.
[0.00] Xen Platform PCI: unrecognised magic value
[0.00] ACPI: RSDP 0x000FFFC0 24 (v02 Xen   )
[0.00] ACPI: XSDT 0xFC007FA0 34 (v01 XenHVM 
 HVML )
[0.00] ACPI: FACP 0xFC007D70 00010C (v05 XenHVM 
 HVML )
[0.00] ACPI: DSDT 0xFC001050 006C9B (v05 XenHVM 
 INTL 20140214)
[0.00] ACPI: APIC 0xFC007E80 6C (v02 XenHVM 
 HVML )

[0.00] Booting paravirtualized kernel on Xen PVH
[0.00] xen: PV spinlocks enabled
 ^^^



This is a temporary interface, and it's not stable.


"Stable" as in syntax and keywords are subject to change?


 Long term PVH guest should
be created using "pvh=1", sadly this has not yet been implemented.


Do I understand this to mean that using "pvh=1" in the config file 
hasn't been wired
up to do everything needed to create a PVH guest? Is there more to be 
done besides
turning that parameter into "builder='hvm" device_model_version="none"? 
Or, better yet,

are there any design notes on this?


Hope this helps, Roger.


It seems it did. Thank you very much!

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

Re: [Xen-devel] [Xen-users] vif-bridge errors when creating and destroying dozens of VMs simultaneously

[Antony Saba]

George,

Patch works as expected, no failures on create and no stale iptables
rules after running under the same load that was producing the errors
previously.

Ubuntu 16.04
Linux 3.13.0-83-generic
iptables v1.6.0
Xen 4.6 5 from distro packages

Thanks!

-Tony

On Wed, May 17, 2017 at 7:44 AM, George Dunlap  wrote:
> On Wed, May 17, 2017 at 1:46 PM, George Dunlap  
> wrote:
>> On 17/05/17 13:43, Ian Jackson wrote:
>>> George Dunlap writes ("Re: [Xen-devel] [Xen-users] vif-bridge errors when 
>>> creating and destroying dozens of VMs simultaneously"):
 So we have three options:
>>> ...
 3. Try to check to see if the version of iptables we have supports -w,
 and use it if available.  This should also work on all systems, but
 introduces a bit of complication.  It also doesn't allow us to
 reliably use a timeout.
>>>
>>> I think this is best.  Eventually we can get rid of the check for -w.
>>>
>>> I think a timeout in this context is not very helpful.
>>>
>>> Also, a loop, on a busy system, might need to have many attempts,
>>> because it will be polling.
>>
>> FWIW the iptables internal mechanism will try to grab the lock, and if
>> it fails (and -w is set), will call sleep(1) before trying again.  My
>> bash loop would do exactly the same thing.
>>
>> But I agree that if timeouts are not important, doing it via iptables is
>> probably cleaner.  Let me work up a patch.
>
> Antony,
>
> Attached is a patch to add the -w option if it's available.  I've
> smoke-tested that it works under normal conditions; but my simplistic
> attempts to get the bug to trigger have failed.  Can you give it a try
> and see if it works?
>
> Thanks,
>  -George



-- 
Antony Saba, aws...@gmail.com

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

Re: [Xen-devel] [resend PATCH] xen: common: rbtree: ported updates from linux tree

[Dario Faggioli]

On Thu, 2017-05-18 at 07:59 -0600, Jan Beulich wrote:
> > > > On 11.05.17 at 19:21,  wrote:
> > 
> > The patch contains the updated version of rbtree implementation
> > from linux
> > kernel tree containing the fixes so far handled.
> 
> I suppose this isn't just fixes, but also enhancements. Furthermore
> I'd appreciate if you recorded the Linux version this was taken from,
> so that anyone wanting to do another upgrade would know what
> the baseline is. In any event, as long as this is just a general
> overhaul and upgrade, I'd like to either see individual bugs pointed
> out which get fixed _and_ which affect us, or I'd expect this to be
> part of a series which actually requires some of the new
> functionality.
>
I fully agree.

And in fact, this is actually quite a big patch, and does (although it
touches only a few files) a bunch of different things (new
functionalities, improved comments, etc).

So, Jan, would it be ok for this thing that Praveen is trying to do, to
be a series, with one patch for each original Linux commit? I think, if
it were me doing this, that would be how I'd do it.

Otherwise it is e.g. hard to understand why ...
> 
> > Signed-off-by: Praveen Kumar 
> > ---
> >  xen/common/rbtree.c| 748
> > +
> >  xen/include/xen/compiler.h |  60 +++
> >  xen/include/xen/rbtree.h   | 120 --
> >  xen/include/xen/rbtree_augmented.h | 283 ++
> 
> ... namely this last (new) header (and what it provides) is needed
> at all.
> 
Indeed. And in fact, for our original purpose (which is to use rb-trees 
instead of linked lists for Credit2's runqueues), I don't think we
actually need the augmented variant.

Praveen, as we agreed on IRC, it is ok to send this patch (which I
think should have been a patch series) first, but stating why you are
actually doing this (i.e., a few words on the original purpose I'm
mentioning above), is really useful, to set the context, and should be
there (in the cover letter or a follow up email).

Also, do Cc me please (in addition to what get_maintainers.pl
says). :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [xen-unstable-smoke test] 109547: tolerable trouble: broken/pass - PUSHED

[Ian Jackson]

Julien Grall writes ("Re: [Xen-devel] [xen-unstable-smoke test] 109547: 
tolerable trouble: broken/pass - PUSHED"):
> On 05/17/2017 08:32 PM, osstest service owner wrote:
> > flight 109547 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/109547/
> >
> > Failures :-/ but no regressions.
> >
> > Tests which did not succeed, but are not blocking:
> >  test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
> 
> It seems that build-arm64 job does not exist for the smoking test. Ian, 
> would it be possible to add it?

That's kind of odd, isn't it.  Obviously it's a bug that it generates
a test job which depends on build jobs which aren't generated.

However, currently, with only two arm64 boxes, I don't think we have
enough bandwidth to add this to the smoke tests.  I have put a note in
my backlog to revisit this when we have more arm64 hardware.

Ian.

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

Re: [Xen-devel] [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL support to VNC

[Ian Jackson]

Simon Waterman writes ("Re: [PATCH RFC 0/6] qemu-xen-trad: sasl: add SASL 
support to VNC"):
> It's not the QEMU in the stubdom that would need to be newer
> but rather the one that's spawned in domain-0 to provide the
> VNC backend when you use an IOEMU stubdom.  As I understand
> it this also needs to be qemu-xen-traditional but maybe
> I've got that wrong?

No, I don't think it does.

> I agree entirely that enabling upstream QEMU to be used
> here would be a better approach and that might be easier
> than getting it running inside the stubdom itself.

Yes.

> Maybe I could look into that if it's not already supported.

Please do!  The relevant code is in libxl and shouldn't be too hard to
find.

I think it would probably be right to just unconditionally use
qemu-xen rather than trad for the PV backend qemu.

> Has any thought been put into running the VNC server in
> the stubdom itself?  That might be nice as VNC access
> would be possible without access to the domain-0 at all.
> It might help with the 'rebootable' domain-0 work too as
> VNC connections wouldn't drop when the domain-0 is restarted.

I think if we had upstream qemu stubdomains, we would probably be able
to do something like this.

Regards,
Ian.

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

Re: [Xen-devel] [PATCH v9 27/28] ARM: vITS: create and initialize virtual ITSes for Dom0

[Julien Grall]

Hi Andre,

On 11/05/17 18:53, Andre Przywara wrote:

For each hardware ITS create and initialize a virtual ITS for Dom0.
We use the same memory mapped address to keep the doorbell working.
This introduces a function to initialize a virtual ITS.
We maintain a list of virtual ITSes, at the moment for the only
purpose of later being able to free them again.
We configure the virtual ITSes to match the hardware ones, that is we
keep the number of device ID bits and event ID bits the same as the host
ITS.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c   | 75 
 xen/arch/arm/vgic-v3.c   |  4 +++
 xen/include/asm-arm/domain.h |  1 +
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 4 files changed, 84 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 8f6ff11..ca35aca 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -52,6 +52,7 @@
  */
 struct virt_its {
 struct domain *d;
+struct list_head vits_list;
 paddr_t doorbell_address;
 unsigned int devid_bits;
 unsigned int evid_bits;
@@ -103,14 +104,49 @@ unsigned int vgic_v3_its_count(const struct domain *d)

 int vgic_v3_its_init_domain(struct domain *d)
 {
+int ret;
+
+INIT_LIST_HEAD(>arch.vgic.vits_list);
 spin_lock_init(>arch.vgic.its_devices_lock);
 d->arch.vgic.its_devices = RB_ROOT;

+if ( is_hardware_domain(d) )
+{
+struct host_its *hw_its;
+
+list_for_each_entry(hw_its, _its_list, entry)
+{
+/*
+ * For each host ITS create a virtual ITS using the same
+ * base and thus doorbell address.
+ * Use the same number of device ID and event ID bits as the host.
+ */
+ret = vgic_v3_its_init_virtual(d, hw_its->addr,
+   hw_its->devid_bits,
+   hw_its->evid_bits);
+if ( ret )
+{
+vgic_v3_its_free_domain(d);


You don't need this call. vgic_v3_free_domain will always be called when 
a domain is destroyed even if it has not finished to be built.



+return ret;
+}
+else
+d->arch.vgic.has_its = true;
+}
+}
+
 return 0;
 }

 void vgic_v3_its_free_domain(struct domain *d)
 {
+struct virt_its *pos, *temp;
+
+list_for_each_entry_safe( pos, temp, >arch.vgic.vits_list, vits_list )
+{
+list_del(>vits_list);
+xfree(pos);
+}
+
 ASSERT(RB_EMPTY_ROOT(>arch.vgic.its_devices));
 }

@@ -1407,6 +1443,45 @@ static const struct mmio_handler_ops 
vgic_its_mmio_handler = {
 .write = vgic_v3_its_mmio_write,
 };

+int vgic_v3_its_init_virtual(struct domain *d, paddr_t guest_addr,
+ unsigned int devid_bits, unsigned int evid_bits)


Why this is exported? The only caller in the same file.


+{
+struct virt_its *its;
+uint64_t base_attr;
+
+its = xzalloc(struct virt_its);
+if ( !its )
+return -ENOMEM;
+
+base_attr  = GIC_BASER_InnerShareable << GITS_BASER_SHAREABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_SameAsInner << 
GITS_BASER_OUTER_CACHEABILITY_SHIFT;
+base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+
+its->cbaser  = base_attr;
+base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;/* 4K pages */
+its->baser_dev = GITS_BASER_TYPE_DEVICE << GITS_BASER_TYPE_SHIFT;
+its->baser_dev |= (sizeof(dev_table_entry_t) - 1) <<
+  GITS_BASER_ENTRY_SIZE_SHIFT;
+its->baser_dev |= base_attr;
+its->baser_coll  = GITS_BASER_TYPE_COLLECTION << GITS_BASER_TYPE_SHIFT;
+its->baser_coll |= (sizeof(coll_table_entry_t) - 1) <<
+   GITS_BASER_ENTRY_SIZE_SHIFT;
+its->baser_coll |= base_attr;
+its->d = d;
+its->doorbell_address = guest_addr + ITS_DOORBELL_OFFSET;
+its->devid_bits = devid_bits;
+its->evid_bits = evid_bits;
+spin_lock_init(>vcmd_lock);
+spin_lock_init(>its_lock);
+
+register_mmio_handler(d, _its_mmio_handler, guest_addr, SZ_64K, its);
+
+/* Register the virtual ITSes to be able to clean them up later. */


There is only one virtual ITS registered here. So s/ITSes/ITS/


+list_add_tail(>vits_list, >arch.vgic.vits_list);
+
+return 0;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index 41cda78..fd4b5f4 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -1700,6 +1700,10 @@ static int vgic_v3_domain_init(struct domain *d)
 d->arch.vgic.intid_bits = GUEST_GICV3_GICD_INTID_BITS;
 }

+/*
+ * For a hardware domain, this will iterate over the host ITSes
+ * and maps  one virtual ITS per host ITS at the same address.
+ */


This kind of comment will get easily rotten if you put it on the caller. 

Re: [Xen-devel] [PATCH v9 26/28] ARM: vITS: increase mmio_count for each ITS

[Julien Grall]

Hi Andre,

On 11/05/17 18:53, Andre Przywara wrote:

Increase the count of MMIO regions needed by one for each ITS Dom0 has
to emulate. We emulate the ITSes 1:1 from the hardware, so the number
is the number of host ITSes.

Signed-off-by: Andre Przywara 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 for-4.9] x86/pagewalk: Fix determination of Protection Key access rights

[Tim Deegan]

Hi,

At 15:02 +0100 on 18 May (1495119734), Andrew Cooper wrote:
>  * When fabricating gl1e's from superpages, propagate the protection key as
>well, so the protection key logic sees the real key as opposed to 0.
> 
>  * Experimentally, the protection key checks are performed ahead of the other
>access rights.  In particular, accesses which fail both protection key and
>regular permission checks yield PFEC_prot_key in the resulting pagefault.
> 
>  * Protection keys apply to all user mode data accesses, including accesses
>from supervisor code.

I think this would be clearer as "all data accesses to user-mode addresses".

>  PKRU WD applies to any data write, not just to
>mapping which are writable.  However, a supervisor access without CR0.WP
>bypasses any protection from protection keys.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Tim Deegan 


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

Re: [Xen-devel] [PATCH v9 23/28] ARM: vITS: handle DISCARD command

[Julien Grall]

Hi Andre,

On 11/05/17 18:53, Andre Przywara wrote:

The DISCARD command drops the connection between a DeviceID/EventID
and an LPI/collection pair.
We mark the respective structure entries as not allocated and make
sure that any queued IRQs are removed.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/vgic-v3-its.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index ef7c78f..f7a8d77 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -723,6 +723,27 @@ out_unlock:
 return ret;
 }

+static int its_handle_discard(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+int ret;
+
+spin_lock(>its_lock);
+
+/* Remove from the radix tree and remove the host entry. */
+ret = its_discard_event(its, devid, eventid);
+
+/* Remove from the guest's ITTE. */
+if ( ret || write_itte_locked(its, devid, eventid,
+  UNMAPPED_COLLECTION, INVALID_LPI, NULL) )


I am not sure to fully understand this if. If ret is not NULL you 
override it and never call write_itte_locked.


Is it what you wanted? If so, then probably a bit more documentation 
would be useful to explain why writte_itte_locked is skipped.



+ret = -1;
+
+spin_unlock(>its_lock);
+
+return ret;
+}
+
 #define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
 #define ITS_CMD_OFFSET(reg) ((reg) & GENMASK(19, 5))

@@ -755,6 +776,9 @@ static int vgic_its_handle_cmds(struct domain *d, struct 
virt_its *its)
 case GITS_CMD_CLEAR:
 ret = its_handle_clear(its, command);
 break;
+case GITS_CMD_DISCARD:
+ret = its_handle_discard(its, command);
+break;
 case GITS_CMD_INT:
 ret = its_handle_int(its, command);
 break;



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu

[Kang, Luwei]

> > --- a/xen/arch/x86/cpu/vpmu.c
> > +++ b/xen/arch/x86/cpu/vpmu.c
> > @@ -859,6 +859,7 @@ static int cpu_callback(
> >  {
> >  vpmu_save_force(vcpu);
> >  vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
> > +per_cpu(last_vcpu, cpu) = NULL;// OR: this_cpu(last_vcpu) 
> > = NULL;
> >  }
> > As you mentioned in before comments, it has been done in 
> > vpmu_save_force(). So this change is unnecessary.
> 
> Indeed. But all I was talking is last_pcpu (whereas you once again talk about 
> last_vcpu).
> 
> > In summary, I think it is enough to solve the issue in vpmu_load() and 
> > vpmu_arch_destroy().
> 
> That's what I alluded to in my reply.
> 
> > After cpu_callback() function, per_cpu(last_vcpu, vpmu->last_pcpu)
> > will be NULL
> 
> No. per_cpu(..., ) simply is invalid.
> 
> > and VPMU_CONTEXT_LOADED will be clear.
> > In vpmu_arch_destroy(), there will not make remote call to clear last.
> 
> I don't understand this sentence.

I mean per_cpu(..., ) will be NULL after cpu_callback(), so that 
"per_cpu(last_vcpu, vpmu->last_pcpu) == v" check in 
vpmu_arch_destroy() will be fail when last_pcpu is the offlined pCPU. Or, it 
may make a remote call to clear the last_vpcu (vpmu_clear_last()).
But I don't understand why simply is invalid, last_vcpu set to NULL is 
presented in source code.  How to comprehend it?

Thanks,
Luwei Kang

> 
> > In vpmu_load(), remote call will guarded by VPMU_CONTEXT_LOADED flag 
> > check. As for vpmu->last_pcpu, we can't use some
> random online one to produce false.
> > What is your opinion?
> 
> I continue to think that it needs to be made sure last_pcpu is valid before 
> using it for anything. Agreed, my previous suggestion of
> simply storing an invalid value was not very useful, as the questionable 
> comparison is != (when making the suggestion I did wrongly
> rememeber it to be == ), but that doesn't eliminate the need to sanity check 
> the value before use. Perhaps all that's needed are a
> couple of cpu_online() checks.
> 
> Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm   5 xen-buildfail REGR. vs. 107636
 build-arm64   5 xen-buildfail REGR. vs. 107636
 build-amd64-xsm   5 xen-buildfail REGR. vs. 107636
 build-i3865 xen-buildfail REGR. vs. 107636
 build-amd64   5 xen-buildfail REGR. vs. 107636
 build-i386-xsm5 xen-buildfail REGR. vs. 107636
 build-armhf-xsm   5 xen-buildfail REGR. vs. 107636
 build-armhf   5 xen-buildfail REGR. vs. 107636

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

Re: [Xen-devel] [PATCH v9 22/28] ARM: vITS: handle MOVI command

[Julien Grall]

Hi Andre,

On 11/05/17 18:53, Andre Przywara wrote:

The MOVI command moves the interrupt affinity from one redistributor
(read: VCPU) to another.
For now migration of "live" LPIs is not yet implemented, but we store
the changed affinity in the host LPI structure and in our virtual ITTE.

Signed-off-by: Andre Przywara 
---
 xen/arch/arm/gic-v3-its.c| 30 
 xen/arch/arm/gic-v3-lpi.c| 15 ++
 xen/arch/arm/vgic-v3-its.c   | 59 
 xen/include/asm-arm/gic_v3_its.h |  4 +++
 4 files changed, 108 insertions(+)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index 8a50f7d..f00597e 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -915,6 +915,36 @@ struct pending_irq *gicv3_assign_guest_event(struct domain 
*d,
 return pirq;
 }

+/* Changes the target VCPU for a given host LPI assigned to a domain. */
+int gicv3_lpi_change_vcpu(struct domain *d, paddr_t vdoorbell,
+  uint32_t vdevid, uint32_t veventid,
+  unsigned int vcpu_id)
+{
+uint32_t host_lpi;
+struct its_device *dev;
+
+spin_lock(>arch.vgic.its_devices_lock);
+dev = get_its_device(d, vdoorbell, vdevid);
+if ( dev )
+host_lpi = get_host_lpi(dev, veventid);
+else
+host_lpi = 0;
+spin_unlock(>arch.vgic.its_devices_lock);
+
+if ( !host_lpi )
+return -ENOENT;
+
+/*
+ * TODO: This just changes the virtual affinity, the physical LPI
+ * still stays on the same physical CPU.
+ * Consider to move the physical affinity to the pCPU running the new
+ * vCPU. However this requires scheduling a host ITS command.
+ */
+gicv3_lpi_update_host_vcpuid(host_lpi, vcpu_id);


If you do that, the next interrupt will get the wrong vCPU lock. I guess 
this will be solved by the vGIC rework?



+
+return 0;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/gic-v3-lpi.c b/xen/arch/arm/gic-v3-lpi.c
index d427539..6af5ad9 100644
--- a/xen/arch/arm/gic-v3-lpi.c
+++ b/xen/arch/arm/gic-v3-lpi.c
@@ -225,6 +225,21 @@ void gicv3_lpi_update_host_entry(uint32_t host_lpi, int 
domain_id,
 write_u64_atomic(>data, hlpi.data);
 }

+int gicv3_lpi_update_host_vcpuid(uint32_t host_lpi, unsigned int vcpu_id)
+{
+union host_lpi *hlpip;
+
+ASSERT(host_lpi >= LPI_OFFSET);
+
+host_lpi -= LPI_OFFSET;
+
+hlpip = _data.host_lpis[host_lpi / HOST_LPIS_PER_PAGE][host_lpi % 
HOST_LPIS_PER_PAGE];
+
+write_u16_atomic(>vcpu_id, vcpu_id);
+
+return 0;
+}
+
 static int gicv3_lpi_allocate_pendtable(uint64_t *reg)
 {
 uint64_t val;
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index c5c0e5e..ef7c78f 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -670,6 +670,59 @@ out_remove_mapping:
 return ret;
 }

+static int its_handle_movi(struct virt_its *its, uint64_t *cmdptr)
+{
+uint32_t devid = its_cmd_get_deviceid(cmdptr);
+uint32_t eventid = its_cmd_get_id(cmdptr);
+uint16_t collid = its_cmd_get_collection(cmdptr);
+unsigned long flags;
+struct pending_irq *p;
+struct vcpu *ovcpu, *nvcpu;
+uint32_t vlpi;
+int ret = -1;
+
+spin_lock(>its_lock);
+/* Check for a mapped LPI and get the LPI number. */
+if ( !read_itte_locked(its, devid, eventid, , ) )
+goto out_unlock;
+
+if ( vlpi == INVALID_LPI )
+goto out_unlock;
+
+/* Check the new collection ID and get the new VCPU pointer */
+nvcpu = get_vcpu_from_collection(its, collid);
+if ( !nvcpu )
+goto out_unlock;
+
+p = gicv3_its_get_event_pending_irq(its->d, its->doorbell_address,
+devid, eventid);
+if ( unlikely(!p) )
+goto out_unlock;
+
+spin_lock_irqsave(>arch.vgic.lock, flags);


The locking is still a problem here because of at least the crafted memory.


+
+/* Update our cached vcpu_id in the pending_irq. */
+p->lpi_vcpu_id = nvcpu->vcpu_id;
+
+spin_unlock_irqrestore(>arch.vgic.lock, flags);
+
+/* Now store the new collection in the translation table. */
+if ( !write_itte_locked(its, devid, eventid, collid, vlpi, ) )
+goto out_unlock;
+
+spin_unlock(>its_lock);
+
+/* TODO: lookup currently-in-guest virtual IRQs and migrate them? */


That's going to be an issue if you don't do that because do_LPI would 
get the wrong lock. Hopefully this will get resolved by the vGIC rework? 
If so, then a todo would be useful where the locking is fragile.


This comment would also apply for all the place in the new code. So we 
can find easily when doing the rework.



+
+return gicv3_lpi_change_vcpu(its->d, its->doorbell_address,
+ devid, eventid, nvcpu->vcpu_id);
+
+out_unlock:
+

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-libvirt-xsm  6 xen-boot fail REGR. vs. 109486
 test-amd64-amd64-amd64-pvgrub  9 debian-di-install   fail REGR. vs. 109486
 test-amd64-i386-xl-raw  18 guest-start/debian.repeat fail REGR. vs. 109486
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 109486

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start  fail REGR. vs. 109486

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-start/win.repeat fail like 109441
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 109486
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 109486
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 109486
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 109486
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 109486
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 109486
 test-amd64-amd64-xl-qemuu-ws16-amd64  9 windows-installfail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64  9 windows-installfail never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   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
 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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-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-libvirt 12 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-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win10-i386  9 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386  9 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386  9 windows-installfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64  9 windows-install fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64  9 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386  9 windows-installfail never 

Re: [Xen-devel] [PATCH v9 21/28] ARM: vITS: handle MAPTI command

[Julien Grall]

Hi Andre,

On 11/05/17 18:53, Andre Przywara wrote:

The MAPTI commands associates a DeviceID/EventID pair with a LPI/CPU
pair and actually instantiates LPI interrupts.
We connect the already allocated host LPI to this virtual LPI, so that
any triggering LPI on the host can be quickly forwarded to a guest.
Beside entering the VCPU and the virtual LPI number in the respective
host LPI entry, we also initialize and add the already allocated
struct pending_irq to our radix tree, so that we can now easily find it
by its virtual LPI number.
We also read the property table to update the enabled bit and the
priority for our new LPI, as we might have missed this during an earlier
INVALL call (which only checks mapped LPIs).


This patch is doing more than implementing MAPTI. It also implements 
MAPI and this should be mention in the commit message/title.



Since write_itte_locked() now sees its first usage, we change the
declaration to static.


Your signed-off-by is missing here.


---
 xen/arch/arm/gic-v3-its.c|  28 +
 xen/arch/arm/vgic-v3-its.c   | 124 ++-
 xen/include/asm-arm/gic_v3_its.h |   3 +
 3 files changed, 152 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
index be4c3e0..8a50f7d 100644
--- a/xen/arch/arm/gic-v3-its.c
+++ b/xen/arch/arm/gic-v3-its.c
@@ -887,6 +887,34 @@ int gicv3_remove_guest_event(struct domain *d, paddr_t 
vdoorbell_address,
 return 0;
 }

+/*
+ * Connects the event ID for an already assigned device to the given VCPU/vLPI
+ * pair. The corresponding physical LPI is already mapped on the host side
+ * (when assigning the physical device to the guest), so we just connect the
+ * target VCPU/vLPI pair to that interrupt to inject it properly if it fires.
+ * Returns a pointer to the already allocated struct pending_irq that is
+ * meant to be used by that event.
+ */
+struct pending_irq *gicv3_assign_guest_event(struct domain *d,
+ paddr_t vdoorbell_address,
+ uint32_t vdevid, uint32_t 
veventid,
+ struct vcpu *v, uint32_t virt_lpi)
+{
+struct pending_irq *pirq;
+uint32_t host_lpi = 0;
+
+pirq = get_event_pending_irq(d, vdoorbell_address, vdevid, veventid,
+ _lpi);
+
+if ( !pirq || !host_lpi )


Again, if you have one valid then the other is valid. If not, then you 
have a bigger problem.


Also, please test host_lpi against INVALID_LPI to avoid assuming it will 
always be 0.



+return NULL;
+
+gicv3_lpi_update_host_entry(host_lpi, d->domain_id,
+v ? v->vcpu_id : INVALID_VCPU_ID, virt_lpi);
+
+return pirq;
+}
+
 /* Scan the DT for any ITS nodes and create a list of host ITSes out of it. */
 void gicv3_its_dt_init(const struct dt_device_node *node)
 {
diff --git a/xen/arch/arm/vgic-v3-its.c b/xen/arch/arm/vgic-v3-its.c
index 731fe0c..c5c0e5e 100644
--- a/xen/arch/arm/vgic-v3-its.c
+++ b/xen/arch/arm/vgic-v3-its.c
@@ -286,9 +286,9 @@ static bool read_itte(struct virt_its *its, uint32_t devid, 
uint32_t evid,
  * If vcpu_ptr is provided, returns the VCPU belonging to that collection.
  * Must be called with the ITS lock held.
  */
-bool write_itte_locked(struct virt_its *its, uint32_t devid,
-   uint32_t evid, uint32_t collid, uint32_t vlpi,
-   struct vcpu **vcpu_ptr)
+static bool write_itte_locked(struct virt_its *its, uint32_t devid,
+  uint32_t evid, uint32_t collid, uint32_t vlpi,
+  struct vcpu **vcpu_ptr)
 {
 paddr_t addr;
 struct vits_itte itte;
@@ -429,6 +429,33 @@ out_unlock:
 return ret;
 }

+/*
+ * For a given virtual LPI read the enabled bit and priority from the virtual
+ * property table and update the virtual IRQ's state in the given pending_irq.
+ * Must be called with the respective VGIC VCPU lock held.
+ */
+static int update_lpi_property(struct domain *d, struct pending_irq *p)
+{
+paddr_t addr;
+uint8_t property;
+int ret;
+
+addr = d->arch.vgic.rdist_propbase & GENMASK(51, 12);
+
+ret = vgic_access_guest_memory(d, addr + p->irq - LPI_OFFSET,
+   , sizeof(property), false);
+if ( ret )
+return ret;
+
+p->lpi_priority = property & LPI_PROP_PRIO_MASK;


Again, I don't think this will update lpi_priority atomically. So who is 
preventing this to happen?



+if ( property & LPI_PROP_ENABLED )
+set_bit(GIC_IRQ_GUEST_ENABLED, >status);
+else
+clear_bit(GIC_IRQ_GUEST_ENABLED, >status);
+
+return 0;
+}
+
 /* Must be called with the ITS lock held. */
 static int its_discard_event(struct virt_its *its,
  uint32_t vdevid, uint32_t vevid)
@@ -556,6 +583,93 @@ static int its_handle_mapd(struct virt_its *its, uint64_t 

[Xen-devel] [PATCH v2 for-4.9] x86/pagewalk: Fix determination of Protection Key access rights

[Andrew Cooper]

 * When fabricating gl1e's from superpages, propagate the protection key as
   well, so the protection key logic sees the real key as opposed to 0.

 * Experimentally, the protection key checks are performed ahead of the other
   access rights.  In particular, accesses which fail both protection key and
   regular permission checks yield PFEC_prot_key in the resulting pagefault.

 * Protection keys apply to all user mode data accesses, including accesses
   from supervisor code.  PKRU WD applies to any data write, not just to
   mapping which are writable.  However, a supervisor access without CR0.WP
   bypasses any protection from protection keys.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: George Dunlap 
CC: Julien Grall 

v2:
 * Fix all implementation bugs, now I have working hardware and have fixed the
   XTF test to understand PKE.
---
 xen/arch/x86/mm/guest_walk.c | 63 ++--
 1 file changed, 32 insertions(+), 31 deletions(-)

diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c
index 32d818e..5c6a85b 100644
--- a/xen/arch/x86/mm/guest_walk.c
+++ b/xen/arch/x86/mm/guest_walk.c
@@ -197,12 +197,12 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 int flags = (_PAGE_PRESENT|_PAGE_USER|_PAGE_RW|
  _PAGE_ACCESSED|_PAGE_DIRTY);
 /*
- * Import cache-control bits. Note that _PAGE_PAT is actually
- * _PAGE_PSE, and it is always set. We will clear it in case
- * _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear.
+ * Import protection key and cache-control bits. Note that _PAGE_PAT
+ * is actually _PAGE_PSE, and it is always set. We will clear it in
+ * case _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear.
  */
 flags |= (guest_l3e_get_flags(gw->l3e)
-  & (_PAGE_PAT|_PAGE_PWT|_PAGE_PCD));
+  & (_PAGE_PKEY_BITS|_PAGE_PAT|_PAGE_PWT|_PAGE_PCD));
 if ( !(gfn_x(start) & 1) )
 /* _PAGE_PSE_PAT not set: remove _PAGE_PAT from flags. */
 flags &= ~_PAGE_PAT;
@@ -302,12 +302,12 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 int flags = (_PAGE_PRESENT|_PAGE_USER|_PAGE_RW|
  _PAGE_ACCESSED|_PAGE_DIRTY);
 /*
- * Import cache-control bits. Note that _PAGE_PAT is actually
- * _PAGE_PSE, and it is always set. We will clear it in case
- * _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear.
+ * Import protection key and cache-control bits. Note that _PAGE_PAT
+ * is actually _PAGE_PSE, and it is always set. We will clear it in
+ * case _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear.
  */
 flags |= (guest_l2e_get_flags(gw->l2e)
-  & (_PAGE_PAT|_PAGE_PWT|_PAGE_PCD));
+  & (_PAGE_PKEY_BITS|_PAGE_PAT|_PAGE_PWT|_PAGE_PCD));
 if ( !(gfn_x(start) & 1) )
 /* _PAGE_PSE_PAT not set: remove _PAGE_PAT from flags. */
 flags &= ~_PAGE_PAT;
@@ -365,6 +365,30 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
  */
 ar = (ar_and & AR_ACCUM_AND) | (ar_or & AR_ACCUM_OR);
 
+#if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
+/*
+ * If all access checks are thus far ok, check Protection Key for 64bit
+ * data accesses to user mappings.
+ *
+ * N.B. In the case that the walk ended with a superpage, the fabricated
+ * gw->l1e contains the appropriate leaf pkey.
+ */
+if ( (ar & _PAGE_USER) && !(walk & PFEC_insn_fetch) &&
+ guest_pku_enabled(v) )
+{
+unsigned int pkey = guest_l1e_get_pkey(gw->l1e);
+unsigned int pkru = read_pkru();
+
+if ( read_pkru_ad(pkru, pkey) ||
+ ((walk & PFEC_write_access) && read_pkru_wd(pkru, pkey) &&
+  ((walk & PFEC_user_mode) || guest_wp_enabled(v))) )
+{
+gw->pfec |= PFEC_prot_key;
+goto out;
+}
+}
+#endif
+
 if ( (walk & PFEC_insn_fetch) && (ar & _PAGE_NX_BIT) )
 /* Requested an instruction fetch and found NX? Fail. */
 goto out;
@@ -400,29 +424,6 @@ guest_walk_tables(struct vcpu *v, struct p2m_domain *p2m,
 goto out;
 }
 
-#if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
-/*
- * If all access checks are thusfar ok, check Protection Key for 64bit
- * user data accesses.
- *
- * N.B. In the case that the walk ended with a superpage, the fabricated
- * gw->l1e contains the appropriate leaf pkey.
- */
-if ( (walk & PFEC_user_mode) && !(walk & PFEC_insn_fetch) &&
- guest_pku_enabled(v) )
-{
-unsigned int pkey = guest_l1e_get_pkey(gw->l1e);
-unsigned int pkru = read_pkru();
-
-if ( read_pkru_ad(pkru, pkey) 

Re: [Xen-devel] [resend PATCH] xen: common: rbtree: ported updates from linux tree

[Jan Beulich]

>>> On 11.05.17 at 19:21,  wrote:
> The patch contains the updated version of rbtree implementation from linux
> kernel tree containing the fixes so far handled.

I suppose this isn't just fixes, but also enhancements. Furthermore
I'd appreciate if you recorded the Linux version this was taken from,
so that anyone wanting to do another upgrade would know what
the baseline is. In any event, as long as this is just a general
overhaul and upgrade, I'd like to either see individual bugs pointed
out which get fixed _and_ which affect us, or I'd expect this to be
part of a series which actually requires some of the new functionality.
Otherwise it is e.g. hard to understand why ...

> Signed-off-by: Praveen Kumar 
> ---
>  xen/common/rbtree.c| 748 
> +
>  xen/include/xen/compiler.h |  60 +++
>  xen/include/xen/rbtree.h   | 120 --
>  xen/include/xen/rbtree_augmented.h | 283 ++

... namely this last (new) header (and what it provides) is needed
at all.

I don't think there's much point in reviewing these changes if
indeed they've been taken from Linux literally (I'm sure you
would have pointed out meaningful changes in the commit
message).

> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -127,4 +127,64 @@
>  # define CLANG_DISABLE_WARN_GCC_COMPAT_END
>  #endif
>  
> +#include 

Anything requiring this header very unlikely belongs into compiler.h.

> +#ifndef __always_inline
> +#define __always_inline inline
> +#endif

Please use always_inline instead, which we already have.

> +#define __READ_ONCE_SIZE   \
> +({ \
> +switch(size) { \
> +case 1: *(__u8 *)res = *(volatile __u8 *)p; break; \
> +case 2: *(__u16 *)res = *(volatile __u16 *)p; break;   \
> +case 4: *(__u32 *)res = *(volatile __u32 *)p; break;   \
> +case 8: *(__u64 *)res = *(volatile __u64 *)p; break;   \

No new uses of __u or u or their signed counterparts
please. We have {,u}int_t for that purpose. Iirc even Linux
maintainers nowadays object to these double underscore prefixed
names outside of user visible header files.

> +default:   \
> +barrier(); \
> +__builtin_memcpy((void *)res, (const void *)p, size);  \
> +barrier(); \

Compiler barriers aren't equivalents of uses of "volatile" on all
architectures, so the correctness here would need to be
explained.

> +}  \
> +})
> +
> +static __always_inline
> +void __read_once_size(const volatile void *p, void *res, int size)
> +{
> +__READ_ONCE_SIZE;
> +}
> +
> +static __always_inline
> +void __write_once_size(volatile void *p, void *res, int size)
> +{
> +switch (size) {
> +case 1: *(volatile __u8 *)p = *(__u8 *)res; break;
> +case 2: *(volatile __u16 *)p = *(__u16 *)res; break;
> +case 4: *(volatile __u32 *)p = *(__u32 *)res; break;
> +case 8: *(volatile __u64 *)p = *(__u64 *)res; break;
> +default:
> +barrier();
> +__builtin_memcpy((void *)p, (const void *)res, size);
> +barrier();
> +}
> +}
> +
> +#define __READ_ONCE(x, check)  \
> +({ \
> +union { typeof(x) __val; char __c[1]; } __u;   \
> +__read_once_size(&(x), __u.__c, sizeof(x));\
> +})

The "check" parameter is unused, so ...

> +#define READ_ONCE(x) __READ_ONCE(x, 1)

... this wrapper can be dropped.

> +#define WRITE_ONCE(x, val) \
> +({ \
> +union { typeof(x) __val; char __c[1]; } __u =  \
> +{ .__val = (__force typeof(x)) (val) };\
> +__write_once_size(&(x), __u.__c, sizeof(x));   \
> +__u.__val; \
> +})
> +
> +
> +
> +
>  #endif /* __LINUX_COMPILER_H */

No way you get to add four blank lines in a row to any file.

In any event it is not clear to me whether we really need all of this:
Are there properties at the use sites which neither
{read,write}_atomic() nor ACCESS_ONCE() can fulfill? And if indeed
we need yet another flavor, you'd need to do away with all these
underscore prefixed names.

Jan

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

Re: [Xen-devel] [Qemu-devel] [RFC PATCH V2 0/2] Qemu: Add Xen vIOMMU interrupt remapping function.

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Subject: [Qemu-devel] [RFC PATCH V2 0/2] Qemu: Add Xen vIOMMU interrupt 
remapping function.
Type: series
Message-id: 1495085580-10631-1-git-send-email-tianyu@intel.com

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
cbe4736 msi: Handle remappable format interrupt request
65e2601 xen-pt: bind/unbind interrupt remapping format MSI

=== OUTPUT BEGIN ===
Checking PATCH 1/2: xen-pt: bind/unbind interrupt remapping format MSI...
ERROR: spaces required around that ':' (ctx:VxW)
#35: FILE: hw/xen/xen_pt_msi.c:172:
+   is_msix ? "-X": "", addr, data);
  ^

ERROR: else should follow close brace '}'
#39: FILE: hw/xen/xen_pt_msi.c:176:
+}
+else {

ERROR: space prohibited after that open parenthesis '('
#61: FILE: hw/xen/xen_pt_msi.c:215:
+if ( addr & MSI_ADDR_IF_MASK ) {

ERROR: space prohibited before that close parenthesis ')'
#61: FILE: hw/xen/xen_pt_msi.c:215:
+if ( addr & MSI_ADDR_IF_MASK ) {

WARNING: line over 80 characters
#77: FILE: hw/xen/xen_pt_msi.c:231:
+rc = xc_domain_unbind_msi_irq(xen_xc, xen_domid, gvec, pirq, 
gflags);

total: 4 errors, 1 warnings, 74 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

Checking PATCH 2/2: msi: Handle remappable format interrupt request...
ERROR: braces {} are necessary for all arms of this statement
#30: FILE: hw/i386/xen/xen-hvm.c:154:
+if (msi_addr_lo & MSI_ADDR_IF_MASK)
[...]

total: 1 errors, 0 warnings, 67 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@freelists.org
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 xen-buildfail REGR. vs. 109547

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f745b55f137c9c086552dc7463ba2cefccab8292
baseline version:
 xen  a7d4a5904b62731551e366ff62d84759c8ee68e2

Last test of basis   109547  2017-05-17 18:12:36 Z0 days
Testing same since   109570  2017-05-18 10:02:26 Z0 days2 attempts


People who touched revisions under test:
  Ian Jackson 
  Samuel Thibault 
  Steven Haigh 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit f745b55f137c9c086552dc7463ba2cefccab8292
Author: Wei Liu 
Date:   Wed May 17 15:26:08 2017 +0100

build: stubdom and tools should depend on public header target

Build can fail if stubdom build is run before tools build because:

1. tools/include build uses relative path and depends on XEN_OS
2. stubdom needs tools/include to be built, at which time XEN_OS is
   mini-os and corresponding symlinks are created
3. libraries inside tools needs tools/include to be built, at which
   time XEN_OS is the host os name, but symlinks won't be created
   because they are already there
4. libraries get the wrong headers and fail to build

Since both tools and stubdom build need the public headers, we build
tools/include before stubdom and tools. Remove runes in stubdom and
tools to avoid building tools/include more than once.

Provide a new dist target for tools/include.  Hook up the install,
clean, dist and distclean targets for tools/include.

The new arrangement ensures tools build gets the correct headers
because XEN_OS is set to host os when building tools/include. As for
stubdom, it explicitly links to the mini-os directory without relying
on XEN_OS so it should be fine.

Reported-by: Steven Haigh 
Signed-off-by: Wei Liu 
Tested-by: Steven Haigh 
Acked-by: Ian Jackson 
Release-acked-by: Julien Grall 
Acked-by: Samuel Thibault 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu

[Jan Beulich]

>>> On 18.05.17 at 15:06,  wrote:
 On 18.05.17 at 13:51,  wrote:
>> In vpmu_load(), remote call will guarded by VPMU_CONTEXT_LOADED flag 
> check. As for vpmu->last_pcpu, we can't use some random online one to produce 
> false.
>> What is your opinion?
> 
> I continue to think that it needs to be made sure last_pcpu is valid
> before using it for anything. Agreed, my previous suggestion of
> simply storing an invalid value was not very useful, as the
> questionable comparison is != (when making the suggestion I
> did wrongly rememeber it to be == ),

And I was wrong here and right originally:

int vpmu_load(struct vcpu *v, bool_t from_guest)
{
...
/* First time this VCPU is running here */
if ( vpmu->last_pcpu != pcpu )
{

If last_pcpu was NR_CPUS or nr_cpu_ids or any other always
invalid value, this condition would be true, which is exactly what
we want. Whereas if you leave the field alone, and another (or
the same) CPU comes (back) up with that number, we may
wrongly not enter the if() body.

Jan


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

Re: [Xen-devel] [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu

[Jan Beulich]

>>> On 18.05.17 at 15:03,  wrote:
> On 05/18/2017 05:07 AM, Jan Beulich wrote:
> On 17.05.17 at 17:57,  wrote:
>>> @@ -581,9 +582,14 @@ static void vpmu_arch_destroy(struct vcpu *v)
>>>  
>>>  if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>>>  {
>>> -/* Unload VPMU first. This will stop counters */
>>> -on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
>>> - vpmu_save_force, v, 1);
>>> +/*
>>> + * Unload VPMU first if VPMU_CONTEXT_LOADED being set.
>>> + * This will stop counters.
>>> + */
>>> +if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
>>> +on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
>>> + vpmu_save_force, v, 1);
>>> +
>>>   vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>>>  }
>>>  }
>> So this is a good step towards what was requested during v1 review,
>> provided it is correct (I'll let Boris comment). 
> 
> From correctness perspective I don't see any problems.
> 
> As I said last time, I'd rename cpu_callback() to something less
> generic, like vpmu_cpu_callback() (or vpmu_cpuhp_callback()).

The vpmu_ prefix is clearly pointless for a static function.

>> You didn't, however, do
>> anything about the other unguarded last_pcpu uses (in vpmu_load()
>> and upwards from the code above in vpmu_arch_destroy()). These
>> _may_ be implicitly fine, but if so please at least add suitable
>> ASSERT()s.
> 
> I wonder whether we should have such an ASSERT() in on_selected_cpus()
> instead.

That's a good idea (and I'll queue a patch to that effect for
post-4.9), but it won't deal with all issues here. Namely the use
of last_pcpu in vpmu_arch_destroy() which the v2 patch didn't
touch is a problem already before calling on_selected_cpus():
per_cpu(last_vcpu, vpmu->last_pcpu) is simply invalid if
vpmu->last_pcpu is offline.

Jan


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

Re: [Xen-devel] [PATCH v2] x86/vpmu: add cpu hot unplug notifier for vpmu

[Jan Beulich]

>>> On 18.05.17 at 13:51,  wrote:
>> >>> On 17.05.17 at 17:57,  wrote:
>> > @@ -581,9 +582,14 @@ static void vpmu_arch_destroy(struct vcpu *v)
>> >
>> >  if ( vpmu->arch_vpmu_ops && vpmu->arch_vpmu_ops->arch_vpmu_destroy )
>> >  {
>> > -/* Unload VPMU first. This will stop counters */
>> > -on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
>> > - vpmu_save_force, v, 1);
>> > +/*
>> > + * Unload VPMU first if VPMU_CONTEXT_LOADED being set.
>> > + * This will stop counters.
>> > + */
>> > +if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
>> > +on_selected_cpus(cpumask_of(vcpu_vpmu(v)->last_pcpu),
>> > + vpmu_save_force, v, 1);
>> > +
>> >   vpmu->arch_vpmu_ops->arch_vpmu_destroy(v);
>> >  }
>> >  }
>> 
>> So this is a good step towards what was requested during v1 review, provided 
> it is correct (I'll let Boris comment). You didn't,
>> however, do anything about the other unguarded last_pcpu uses (in 
> vpmu_load() and upwards from the code above in
>> vpmu_arch_destroy()). These _may_ be implicitly fine, but if so please at 
> least add suitable ASSERT()s.
>> 
> 
> Hi Jan,
> Thanks for your reply. I think I understand the issue you mentioned. But 
> sorry,  I am not very clear what is your solution from your description.
> At first, I want to change like this:
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -859,6 +859,7 @@ static int cpu_callback(
>  {
>  vpmu_save_force(vcpu);
>  vpmu_reset(vpmu, VPMU_CONTEXT_LOADED);
> +per_cpu(last_vcpu, cpu) = NULL;// OR: this_cpu(last_vcpu) = 
> NULL;
>  }
> As you mentioned in before comments, it has been done in 
> vpmu_save_force(). So this change is unnecessary.

Indeed. But all I was talking is last_pcpu (whereas you once again
talk about last_vcpu).

> In summary, I think it is enough to solve the issue in vpmu_load() and 
> vpmu_arch_destroy().

That's what I alluded to in my reply.

> After cpu_callback() function, per_cpu(last_vcpu, vpmu->last_pcpu)
> will be NULL

No. per_cpu(..., ) simply is invalid.

> and VPMU_CONTEXT_LOADED will be clear.
> In vpmu_arch_destroy(), there will not make remote call to clear last.

I don't understand this sentence.

> In vpmu_load(), remote call will guarded by VPMU_CONTEXT_LOADED flag 
> check. As for vpmu->last_pcpu, we can't use some random online one to produce 
> false.
> What is your opinion?

I continue to think that it needs to be made sure last_pcpu is valid
before using it for anything. Agreed, my previous suggestion of
simply storing an invalid value was not very useful, as the
questionable comparison is != (when making the suggestion I
did wrongly rememeber it to be == ), but that doesn't eliminate
the need to sanity check the value before use. Perhaps all that's
needed are a couple of cpu_online() checks.

Jan


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