Re: [Xen-devel] Ping: [PATCH v2 0/3] XSA-248...251 follow-up

[Jan Beulich]

>>> On 08.02.18 at 13:34,  wrote:
> On 02/07/2018 03:27 PM, Jan Beulich wrote:
> On 20.12.17 at 10:37,  wrote:
>>> The parts of this series aren't really dependent upon one another,
>>> they belong together solely because of their origin.
>>>
>>> 1: x86/shadow: widen reference count
>>> 2: x86/mm: clean up SHARED_M2P{,_ENTRY} uses
>>> 3: x86: use paging_mark_pfn_dirty()
>> 
>> George,
>> 
>> any chance to get an ack or otherwise (or an indication that they
>> can go in with just Andrew's ack, which was provided via IRC) for
>> the latter two?
> 
> Due to some quirks in my mail setup right now I can't respond directly
> (or rather, I have just done so but I know they'll never get to you), so:
> 
> #2: Reviewed-by: George Dunlap 
> #3: Acked-by: George Dunalp 

Thanks. The other two mails (apparently sent a few minutes before
this one) arrived fine though.

Jan


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

[Xen-devel] [seabios test] 119025: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvopsbroken
 build-amd64-pvops 4 host-install(4)broken REGR. vs. 115539

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  4a6dbcea3e412fe12effa2f812f50dd7eae90955
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  101 days
Failing since115733  2017-11-10 17:19:59 Z   94 days  118 attempts
Testing same since   118668  2018-02-08 04:50:43 Z5 days6 attempts


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

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 blocked 
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 blocked 
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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

broken-job build-amd64-pvops broken
broken-step build-amd64-pvops host-install(4)

Not pushing.


commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955
Author: Nikolay Nikolov 
Date:   Sun Feb 4 17:27:01 2018 +0200

floppy: Use timer_check() in floppy_wait_irq()

Use timer_check() instead of using floppy_motor_counter in BDA for the
timeout check in floppy_wait_irq().

The problem with using floppy_motor_counter was that, after it reaches
0, it immediately stops the floppy 

Re: [Xen-devel] [PATCH 7/7] x86: add iommu_ops to map and unmap pages, and also to flush the IOTLB

[Tian, Kevin]

> From: Paul Durrant
> Sent: Monday, February 12, 2018 6:47 PM
> 
> This patch adds iommu_ops to allow a domain with control_iommu
> privilege
> to map and unmap pages from any guest over which it has mapping
> privilege
> in the IOMMU.
> These operations implicitly disable IOTLB flushing so that the caller can
> batch operations and then explicitly flush the IOTLB using the iommu_op
> also added by this patch.

given that last discussion is 2yrs ago and you said actual implementation
already biased from original spec, it'd be difficult to judge whether current
change is sufficient or just 1st step. Could you summarize what have
been changed from last spec, and also any further tasks in your TODO list?

at least just map/unmap operations definitely not meet XenGT requirement...

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

Re: [Xen-devel] [PATCH 6/7] x86: add iommu_op to query reserved ranges

[Tian, Kevin]

> From: Paul Durrant
> Sent: Monday, February 12, 2018 6:47 PM
> 
> Certain areas of memory, such as RMRRs, must be mapped 1:1
> (i.e. BFN == MFN) through the IOMMU.
> 
> This patch adds an iommu_op to allow these ranges to be queried.
> 
> Signed-off-by: Paul Durrant 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  xen/arch/x86/iommu_op.c   | 121
> ++
>  xen/include/public/iommu_op.h |  35 
>  xen/include/xlat.lst  |   2 +
>  3 files changed, 158 insertions(+)
> 
> diff --git a/xen/arch/x86/iommu_op.c b/xen/arch/x86/iommu_op.c
> index edd8a384b3..ac81b98b7a 100644
> --- a/xen/arch/x86/iommu_op.c
> +++ b/xen/arch/x86/iommu_op.c
> @@ -22,6 +22,58 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +struct get_rdm_ctxt {
> +unsigned int max_entries;
> +unsigned int nr_entries;
> +XEN_GUEST_HANDLE(xen_iommu_reserved_region_t) regions;
> +};
> +
> +static int get_rdm(xen_pfn_t start, xen_ulong_t nr, u32 id, void *arg)
> +{
> +struct get_rdm_ctxt *ctxt = arg;
> +
> +if ( ctxt->nr_entries < ctxt->max_entries )
> +{
> +xen_iommu_reserved_region_t region = {
> +.start_bfn = start,
> +.nr_frames = nr,
> +};
> +
> +if ( copy_to_guest_offset(ctxt->regions, ctxt->nr_entries, ,
> +  1) )
> +return -EFAULT;

RMRR entries are device specific. it's why a 'id' (i.e. sbdf) field 
is introduced for such check.

> +}
> +
> +ctxt->nr_entries++;
> +
> +return 1;
> +}
> +
> +static int iommuop_query_reserved(struct
> xen_iommu_op_query_reserved *op)

I didn't get why we cannot reuse existing XENMEM_reserved_
device_memory_map?

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

Re: [Xen-devel] [PATCH 5/7] public / x86: introduce __HYPERCALL_iommu_op

[Tian, Kevin]

> From: Paul Durrant
> Sent: Monday, February 12, 2018 6:47 PM
> 
> This patch introduces the boilerplate for a new hypercall to allow a
> domain to control IOMMU mappings for its own pages.
> Whilst there is duplication of code between the native and compat entry
> points which appears ripe for some form of combination, I think it is
> better to maintain the separation as-is because the compat entry point
> will necessarily gain complexity in subsequent patches.
> 
> NOTE: This hypercall is only implemented for x86 and is currently
>   restricted by XSM to dom0 since it could be used to cause IOMMU
>   faults which may bring down a host.
> 
> Signed-off-by: Paul Durrant 
[...]
> +
> +
> +static bool can_control_iommu(void)
> +{
> +struct domain *currd = current->domain;
> +
> +/*
> + * IOMMU mappings cannot be manipulated if:
> + * - the IOMMU is not enabled or,
> + * - the IOMMU is passed through or,
> + * - shared EPT configured or,
> + * - Xen is maintaining an identity map.

"for dom0"

> + */
> +if ( !iommu_enabled || iommu_passthrough ||
> + iommu_use_hap_pt(currd) || need_iommu(currd) )

I guess it's clearer to directly check iommu_dom0_strict here

> +return false;
> +
> +return true;
> +}


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

Re: [Xen-devel] [PATCH 0/7] paravirtual IOMMU interface

[Tian, Kevin]

> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: Monday, February 12, 2018 6:47 PM
> 
> The idea of a paravirtual IOMMU interface was last discussed on xen-devel
> more than two years ago and narrowed down on a draft specification [1].
> There was also an RFC patch series posted with an implementation,
> however
> this was never followed through.
> 
> In this patch series I have tried to simplify the interface and therefore
> have moved away from the draft specification.

bear sending out an updated spec?

> 
> Patches #1 - #3 in the series introduce 'bus frame numbers' into Xen (frame
> numbers relating to the IOMMU rather than the MMU). The modifications
> are
> in common code and so affect ARM as well as x86.
> 
> Patch #4 adds a pre-requisite method in iommu_ops and an
> implementation
> for VT-d. I have not done an implmentation for AMD IOMMUs as my test
> hard-
> ware is Intel based, but one may be added in future.
> 
> Patches #5 - #7 introduce the new 'iommu_op' hypercall with sub-
> operations
> to query ranges reserved in the IOMMU, map and unmap pages, and flush
> the
> IOTLB.
> 
> For testing purposes, I have implemented patches to a Linux PV dom0 to
> set
> up a 1:1 BFN:GFN mapping and use normal swiotlb dma operations rather
> then xen-swiotlb.
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-
> 02/msg01428.html
> 
> Paul Durrant (7):
>   iommu: introduce the concept of BFN...
>   iommu: make use of type-safe BFN and MFN in exported functions
>   iommu: push use of type-safe BFN and MFN into iommu_ops
>   vtd: add lookup_page method to iommu_ops
>   public / x86: introduce __HYPERCALL_iommu_op
>   x86: add iommu_op to query reserved ranges
>   x86: add iommu_ops to map and unmap pages, and also to flush the
> IOTLB
> 
>  tools/flask/policy/modules/xen.if |   1 +
>  xen/arch/arm/p2m.c|   3 +-
>  xen/arch/x86/Makefile |   1 +
>  xen/arch/x86/hvm/hypercall.c  |   1 +
>  xen/arch/x86/hypercall.c  |   1 +
>  xen/arch/x86/iommu_op.c   | 476
> ++
>  xen/arch/x86/mm.c |   7 +-
>  xen/arch/x86/mm/p2m-ept.c |   8 +-
>  xen/arch/x86/mm/p2m-pt.c  |   8 +-
>  xen/arch/x86/mm/p2m.c |  15 +-
>  xen/arch/x86/pv/hypercall.c   |   1 +
>  xen/arch/x86/x86_64/mm.c  |   5 +-
>  xen/common/grant_table.c  |  10 +-
>  xen/common/memory.c   |   4 +-
>  xen/drivers/passthrough/amd/iommu_cmd.c   |  18 +-
>  xen/drivers/passthrough/amd/iommu_map.c   |  85 ++---
>  xen/drivers/passthrough/amd/pci_amd_iommu.c   |   4 +-
>  xen/drivers/passthrough/arm/smmu.c|  22 +-
>  xen/drivers/passthrough/iommu.c   |  28 +-
>  xen/drivers/passthrough/vtd/iommu.c   |  76 +++-
>  xen/drivers/passthrough/vtd/iommu.h   |   2 +
>  xen/drivers/passthrough/vtd/x86/vtd.c |   3 +-
>  xen/drivers/passthrough/x86/iommu.c   |   2 +-
>  xen/include/Makefile  |   2 +
>  xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |   8 +-
>  xen/include/public/iommu_op.h | 127 +++
>  xen/include/public/xen.h  |   1 +
>  xen/include/xen/hypercall.h   |  12 +
>  xen/include/xen/iommu.h   |  42 ++-
>  xen/include/xlat.lst  |   5 +
>  xen/include/xsm/dummy.h   |   6 +
>  xen/include/xsm/xsm.h |   6 +
>  xen/xsm/dummy.c   |   1 +
>  xen/xsm/flask/hooks.c |   6 +
>  xen/xsm/flask/policy/access_vectors   |   2 +
>  35 files changed, 868 insertions(+), 131 deletions(-)
>  create mode 100644 xen/arch/x86/iommu_op.c
>  create mode 100644 xen/include/public/iommu_op.h
> ---
> Cc: Andrew Cooper 
> Cc: Daniel De Graaf 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Julien Grall 
> Cc: Jun Nakajima 
> Cc: Kevin Tian 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Suravee Suthikulpanit 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> 
> --
> 2.11.0


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

[Xen-devel] [PATCH v2] pvcalls-front improvements

[Stefano Stabellini]

Hi all,

this small series introduces a per socket refcount to increase the
efficiency on socket release operations, and makes releasing passive
sockets safe.

Cheers,

Stefano


Changes in v2:
- add acked-by
- fix check in pvcalls_enter_soc
- fix code style
- nicer checks in pvcalls_front_release


Stefano Stabellini (2):
  pvcalls-front: introduce a per sock_mapping refcount
  pvcalls-front: wait for other operations to return when release passive 
sockets

 drivers/xen/pvcalls-front.c | 199 +++-
 1 file changed, 87 insertions(+), 112 deletions(-)

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

[Xen-devel] [PATCH v2 1/2] pvcalls-front: introduce a per sock_mapping refcount

[Stefano Stabellini]

Introduce a per sock_mapping refcount, in addition to the existing
global refcount. Thanks to the sock_mapping refcount, we can safely wait
for it to be 1 in pvcalls_front_release before freeing an active socket,
instead of waiting for the global refcount to be 1.

Signed-off-by: Stefano Stabellini 

---
Changes in v2:
- fix code style
- nicer checks in pvcalls_front_release
- fix check in pvcalls_enter_sock
---
 drivers/xen/pvcalls-front.c | 193 +++-
 1 file changed, 81 insertions(+), 112 deletions(-)

diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
index 4c789e6..163bf8c 100644
--- a/drivers/xen/pvcalls-front.c
+++ b/drivers/xen/pvcalls-front.c
@@ -60,6 +60,7 @@ struct sock_mapping {
bool active_socket;
struct list_head list;
struct socket *sock;
+   atomic_t refcount;
union {
struct {
int irq;
@@ -93,6 +94,34 @@ struct sock_mapping {
};
 };
 
+static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
+{
+   struct sock_mapping *map = NULL;
+
+   if (!pvcalls_front_dev ||
+   dev_get_drvdata(_front_dev->dev) == NULL)
+   return ERR_PTR(-ENOTCONN);
+
+   pvcalls_enter();
+   map = (struct sock_mapping *)sock->sk->sk_send_head;
+   if (map == NULL) {
+   pvcalls_exit()
+   return ERR_PTR(-ENOTSOCK);
+   }
+
+   atomic_inc(>refcount);
+   return map;
+}
+
+static inline void pvcalls_exit_sock(struct socket *sock)
+{
+   struct sock_mapping *map = NULL;
+
+   map = (struct sock_mapping *)sock->sk->sk_send_head;
+   atomic_dec(>refcount);
+   pvcalls_exit();
+}
+
 static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
 {
*req_id = bedata->ring.req_prod_pvt & (RING_SIZE(>ring) - 1);
@@ -369,31 +398,23 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
return -EOPNOTSUPP;
 
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
-   return -ENOTCONN;
-   }
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
 
bedata = dev_get_drvdata(_front_dev->dev);
 
-   map = (struct sock_mapping *)sock->sk->sk_send_head;
-   if (!map) {
-   pvcalls_exit();
-   return -ENOTSOCK;
-   }
-
spin_lock(>socket_lock);
ret = get_request(bedata, _id);
if (ret < 0) {
spin_unlock(>socket_lock);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return ret;
}
ret = create_active(map, );
if (ret < 0) {
spin_unlock(>socket_lock);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return ret;
}
 
@@ -423,7 +444,7 @@ int pvcalls_front_connect(struct socket *sock, struct 
sockaddr *addr,
smp_rmb();
ret = bedata->rsp[req_id].ret;
bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return ret;
 }
 
@@ -488,23 +509,15 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
msghdr *msg,
if (flags & (MSG_CONFIRM|MSG_DONTROUTE|MSG_EOR|MSG_OOB))
return -EOPNOTSUPP;
 
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
-   return -ENOTCONN;
-   }
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
bedata = dev_get_drvdata(_front_dev->dev);
 
-   map = (struct sock_mapping *) sock->sk->sk_send_head;
-   if (!map) {
-   pvcalls_exit();
-   return -ENOTSOCK;
-   }
-
mutex_lock(>active.out_mutex);
if ((flags & MSG_DONTWAIT) && !pvcalls_front_write_todo(map)) {
mutex_unlock(>active.out_mutex);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return -EAGAIN;
}
if (len > INT_MAX)
@@ -526,7 +539,7 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
msghdr *msg,
tot_sent = sent;
 
mutex_unlock(>active.out_mutex);
-   pvcalls_exit();
+   pvcalls_exit_sock(sock);
return tot_sent;
 }
 
@@ -591,19 +604,11 @@ int pvcalls_front_recvmsg(struct socket *sock, struct 
msghdr *msg, size_t len,
if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
return -EOPNOTSUPP;
 
-   pvcalls_enter();
-   if (!pvcalls_front_dev) {
-   pvcalls_exit();
-   return -ENOTCONN;
-   }
+   map = pvcalls_enter_sock(sock);
+   if (IS_ERR(map))
+   return PTR_ERR(map);
bedata = 

Re: [Xen-devel] [PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

[Stefano Stabellini]

On Mon, 12 Feb 2018, Juergen Gross wrote:
> On 05/02/18 23:51, Stefano Stabellini wrote:
> > Passive sockets can have ongoing operations on them, specifically, we
> > have two wait_event_interruptable calls in pvcalls_front_accept.
> > 
> > Add two wake_up calls in pvcalls_front_release, then wait for the
> > potential waiters to return and release the sock_mapping refcount.
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> Acked-by: Juergen Gross 

Thanks!

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

Re: [Xen-devel] [PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

[Stefano Stabellini]

On Mon, 12 Feb 2018, Juergen Gross wrote:
> On 05/02/18 23:51, Stefano Stabellini wrote:
> > Introduce a per sock_mapping refcount, in addition to the existing
> > global refcount. Thanks to the sock_mapping refcount, we can safely wait
> > for it to be 1 in pvcalls_front_release before freeing an active socket,
> > instead of waiting for the global refcount to be 1.
> > 
> > Signed-off-by: Stefano Stabellini 
> > ---
> >  drivers/xen/pvcalls-front.c | 190 
> > ++--
> >  1 file changed, 78 insertions(+), 112 deletions(-)
> > 
> > diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> > index 4c789e6..164d3ad 100644
> > --- a/drivers/xen/pvcalls-front.c
> > +++ b/drivers/xen/pvcalls-front.c
> > @@ -60,6 +60,7 @@ struct sock_mapping {
> > bool active_socket;
> > struct list_head list;
> > struct socket *sock;
> > +   atomic_t refcount;
> > union {
> > struct {
> > int irq;
> > @@ -93,6 +94,33 @@ struct sock_mapping {
> > };
> >  };
> >  
> > +static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
> > +{
> > +   struct sock_mapping *map = NULL;
> > +
> > +   if (!pvcalls_front_dev || _front_dev->dev == NULL)
> 
> Did you mean:
> if (!pvcalls_front_dev || !pvcalls_front_dev->dev)

I actually meant:

if (!pvcalls_front_dev || dev_get_drvdata(_front_dev->dev) == NULL)

 
> > +   return ERR_PTR(-ENOTCONN);
> > +
> > +   pvcalls_enter();
> > +   map = (struct sock_mapping *) sock->sk->sk_send_head;
> 
> Style: no blank after the cast, please (multiple times).

OK, I'll fix them all


> > +   if (map == NULL) {
> > +   pvcalls_exit()
> > +   return ERR_PTR(-ENOTSOCK);
> > +   }
> > +
> > +   atomic_inc(>refcount);
> > +   return map;
> > +}
> > +
> > +static inline void pvcalls_exit_sock(struct socket *sock)
> > +{
> > +   struct sock_mapping *map = NULL;
> > +
> > +   map = (struct sock_mapping *) sock->sk->sk_send_head;
> > +   atomic_dec(>refcount);
> > +   pvcalls_exit();
> > +}
> > +
> >  static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
> >  {
> > *req_id = bedata->ring.req_prod_pvt & (RING_SIZE(>ring) - 1);
> > @@ -369,31 +397,23 @@ int pvcalls_front_connect(struct socket *sock, struct 
> > sockaddr *addr,
> > if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
> > return -EOPNOTSUPP;
> >  
> > -   pvcalls_enter();
> > -   if (!pvcalls_front_dev) {
> > -   pvcalls_exit();
> > -   return -ENOTCONN;
> > -   }
> > +   map = pvcalls_enter_sock(sock);
> > +   if (IS_ERR(map))
> > +   return PTR_ERR(map);
> >  
> > bedata = dev_get_drvdata(_front_dev->dev);
> >  
> > -   map = (struct sock_mapping *)sock->sk->sk_send_head;
> > -   if (!map) {
> > -   pvcalls_exit();
> > -   return -ENOTSOCK;
> > -   }
> > -
> > spin_lock(>socket_lock);
> > ret = get_request(bedata, _id);
> > if (ret < 0) {
> > spin_unlock(>socket_lock);
> > -   pvcalls_exit();
> > +   pvcalls_exit_sock(sock);
> > return ret;
> > }
> > ret = create_active(map, );
> > if (ret < 0) {
> > spin_unlock(>socket_lock);
> > -   pvcalls_exit();
> > +   pvcalls_exit_sock(sock);
> > return ret;
> > }
> >  
> > @@ -423,7 +443,7 @@ int pvcalls_front_connect(struct socket *sock, struct 
> > sockaddr *addr,
> > smp_rmb();
> > ret = bedata->rsp[req_id].ret;
> > bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
> > -   pvcalls_exit();
> > +   pvcalls_exit_sock(sock);
> > return ret;
> >  }
> >  
> > @@ -488,23 +508,15 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
> > msghdr *msg,
> > if (flags & (MSG_CONFIRM|MSG_DONTROUTE|MSG_EOR|MSG_OOB))
> > return -EOPNOTSUPP;
> >  
> > -   pvcalls_enter();
> > -   if (!pvcalls_front_dev) {
> > -   pvcalls_exit();
> > -   return -ENOTCONN;
> > -   }
> > +   map = pvcalls_enter_sock(sock);
> > +   if (IS_ERR(map))
> > +   return PTR_ERR(map);
> > bedata = dev_get_drvdata(_front_dev->dev);
> >  
> > -   map = (struct sock_mapping *) sock->sk->sk_send_head;
> > -   if (!map) {
> > -   pvcalls_exit();
> > -   return -ENOTSOCK;
> > -   }
> > -
> > mutex_lock(>active.out_mutex);
> > if ((flags & MSG_DONTWAIT) && !pvcalls_front_write_todo(map)) {
> > mutex_unlock(>active.out_mutex);
> > -   pvcalls_exit();
> > +   pvcalls_exit_sock(sock);
> > return -EAGAIN;
> > }
> > if (len > INT_MAX)
> > @@ -526,7 +538,7 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
> > msghdr *msg,
> > tot_sent = sent;
> >  
> > mutex_unlock(>active.out_mutex);
> > -   pvcalls_exit();
> > +   pvcalls_exit_sock(sock);
> > return tot_sent;
> >  }
> >  
> > @@ -591,19 +603,11 @@ int pvcalls_front_recvmsg(struct 

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

[Michael Young]

On Fri, 9 Feb 2018, Christian Lindig wrote:

Sorry, I can’t make a promise because of my other obligations. I do 
wonder, though: this patch did not come out of nowhere but supposedly 
was working - what is different here?


The patch was from Fedora and is broken there too! It fixes the build 
issues but it doesn't look like anyone tested it (I use xenstored).


I have been trying to narrow down where the problem is and I think there 
are actually two issues;
one in tools/ocaml/xenstored/utils.ml which I think causes an error like 
Fatal error: exception Failure("int_of_string")

and one in tools/ocaml/libs/xb/xb.ml which I think causes an error like
Fatal error: exception Failure("evtchn bind_interdomain failed")

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 
118942

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

version targeted for testing:
 qemuu019bb9ac98f51c3ce362978c6e0c82d853762aa0
baseline version:
 qemuuc7b02d7d032d6022060e4b393827c963c93ce63f

Last test of basis   118942  2018-02-11 21:18:32 Z1 days
Testing same since   119000  2018-02-12 13:17:55 Z0 days1 attempts


People who touched revisions under test:
  Eric Blake 
  Peter Maydell 
  Vladimir Sementsov-Ogievskiy 

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

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Julien Grall]

On 12/02/2018 23:16, Mirela Simonovic wrote:

Hi Julien,


Hi,


On 02/12/2018 10:41 PM, Julien Grall wrote:



On 12/02/2018 20:12, Mirela Simonovic wrote:

Hi Julien,


Hi Mirela,

Thank you for the review.

I've done pretty much the same work in parallel, but there are few 
additional minor changes I've made. Briefly, the difference is in 
return values that some already implemented functions should return 
starting from v1.0 (and even v0.2 errata). Please let me know whether 
you omitted that intentionally.


Could you give a bit more details here? From a brief look we don't 
seem to implement correctly:
- CPU_OFF: PSCI_DENY should be return on failure (though it should 
never fail in Xen case) and the check on the vCPU state is pointless.


I believe CPU_OFF is fine today, it never returns.

- MIGRATE_INFO_TYPE: should technically return int32_t instead of 
uint32_t. That not really matter for now.


If you speak about denying SMC64 call from AArch32, then this is 
already done in vsmccc.c (see vsmccc_call).


Agreed on above, there are 2 more:

1. MIGRATE_INFO_TYPE should return PSCI_NOT_SUPPORTED instead 
PSCI_0_2_TOS_MP_OR_NOT_PRESENT. The function is effectively not 
implemented, but in v0.2 it was mandatory, so it couldn't return 
PSCI_NOT_SUPPORTED (I guess this was some kind of a workaround). Since 
v0.2 errata and v1.0 release the function is made optional and it should 
return "not supported" error - just removing the function should be fine 
(and mismatching return type issue would be gone).


Looking at the spec:

"2 Trusted OS is either not present or does not require migration. A 
system of this type does not require the caller to use the MIGRATE 
function. MIGRATE function calls return NOT_SUPPORTED."


So returning 2 in our case seems to be valid.



2. A new error code has been introduced in PSCI v1.0: 
PSCI_INVALID_ADDRESS. This error should be returned by PSCI functions 
which receive an address as the argument when the provided address is 
incorrect. In implementation in Xen this affects CPU_ON and CPU_SUSPEND. 
CPU_ON today returns invalid parameter error and that needs to be 
replaced with invalid address error. I'm not sure for CPU_SUSPEND since 
its implementation doesn't use/check any of the arguments today...
I disagree, not all PSCI_INVALID_PARAMETERS should be replaced by 
PSCI_INVALID_ADDRESS. They have two distinct meaning. However, I am not 
sure where we would need to use it in Xen. The error is described as 
"INVALID_ADDRESS is returned when the entry point address is known by 
the implementation to be invalid, because it is in a range that is known 
not to be available to the caller."


The only potential one would be the check on is_thumb, but even there it 
does not match the description. The range is still available to the 
guest. I think that check should just be dropped.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Mirela Simonovic]

Hi Julien,


On 02/12/2018 10:41 PM, Julien Grall wrote:



On 12/02/2018 20:12, Mirela Simonovic wrote:

Hi Julien,


Hi Mirela,

Thank you for the review.

I've done pretty much the same work in parallel, but there are few 
additional minor changes I've made. Briefly, the difference is in 
return values that some already implemented functions should return 
starting from v1.0 (and even v0.2 errata). Please let me know whether 
you omitted that intentionally.


Could you give a bit more details here? From a brief look we don't 
seem to implement correctly:
- CPU_OFF: PSCI_DENY should be return on failure (though it should 
never fail in Xen case) and the check on the vCPU state is pointless.


I believe CPU_OFF is fine today, it never returns.

- MIGRATE_INFO_TYPE: should technically return int32_t instead of 
uint32_t. That not really matter for now.


If you speak about denying SMC64 call from AArch32, then this is 
already done in vsmccc.c (see vsmccc_call).


Agreed on above, there are 2 more:

1. MIGRATE_INFO_TYPE should return PSCI_NOT_SUPPORTED instead 
PSCI_0_2_TOS_MP_OR_NOT_PRESENT. The function is effectively not 
implemented, but in v0.2 it was mandatory, so it couldn't return 
PSCI_NOT_SUPPORTED (I guess this was some kind of a workaround). Since 
v0.2 errata and v1.0 release the function is made optional and it should 
return "not supported" error - just removing the function should be fine 
(and mismatching return type issue would be gone).


2. A new error code has been introduced in PSCI v1.0: 
PSCI_INVALID_ADDRESS. This error should be returned by PSCI functions 
which receive an address as the argument when the provided address is 
incorrect. In implementation in Xen this affects CPU_ON and CPU_SUSPEND. 
CPU_ON today returns invalid parameter error and that needs to be 
replaced with invalid address error. I'm not sure for CPU_SUSPEND since 
its implementation doesn't use/check any of the arguments today...


Thanks,
Mirela



I can submit these patches if you want. Currently I have few - one 
for each fix, easier to review. I guess all of them should be 
squashed with the patch you submitted.


One more note - starting from v1.0, PSCI_NOT_SUPPORTED error should 
be returned for all optional functions that are not implemented. Is 
that the case? I.e. when there is no case for a particular function 
ID in do_vpsci_0_2_call the PSCI_NOT_SUPPORTED error will be returned?


This is done by vmsccc_handle_call().
See set_user_regs(regs, 0, ARM_SMCC_ERR_UNKNOWN_FUNCTION) which is 
equivalent to PSCI_NOT_SUPPORTED.


[...]


+static int32_t do_psci_1_0_features(uint32_t psci_func_id)
+{
+    /* /!\ Ordered by function ID and not name */
+    switch ( psci_func_id )
+    {
+    case PSCI_0_2_FN32_PSCI_VERSION:
+    case PSCI_0_2_FN32_CPU_SUSPEND:
+    case PSCI_0_2_FN64_CPU_SUSPEND:


Just a note here - PSCI_FEATURES should return additional information 
just for CPU_SUSPEND (supported power state and mode). AFAIU, that 
value is also 0, so the return code should be fine.


I think so, from what I understood this is inline with CPU_SUSPEND 
only supports 0.2 format.


Cheers,




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

[Xen-devel] [linux-next test] 118987: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 118893
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 118893
 test-armhf-armhf-libvirt 19 leak-check/check fail REGR. vs. 118893
 test-armhf-armhf-libvirt-xsm 10 debian-install   fail REGR. vs. 118893
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118893
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 118893
 test-armhf-armhf-xl-xsm  10 debian-install   fail REGR. vs. 118893
 test-armhf-armhf-xl-cubietruck 10 debian-install fail REGR. vs. 118893

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 118893

Tests which did not succeed, but are not blocking:
 test-amd64-i386-examine   8 reboot   fail  like 118893
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot   fail like 118893
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot   fail like 118893
 test-amd64-i386-pair 10 xen-boot/src_hostfail  like 118893
 test-amd64-i386-pair 11 xen-boot/dst_hostfail  like 118893
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot  fail like 118893
 test-amd64-i386-freebsd10-amd64  7 xen-boot   fail like 118893
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 
118893
 test-amd64-i386-xl7 xen-boot fail  like 118893
 test-amd64-i386-rumprun-i386  7 xen-boot fail  like 118893
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  7 xen-boot fail like 118893
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot   fail like 118893
 test-amd64-i386-libvirt-xsm   7 xen-boot fail  like 118893
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail  like 118893
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail  like 118893
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot  fail like 118893
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot  fail like 118893
 test-amd64-i386-xl-xsm7 xen-boot fail  like 118893
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot   fail like 118893
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-bootfail like 118893
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot  fail like 118893
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail like 118893
 test-amd64-i386-xl-raw7 xen-boot fail  like 118893
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot   fail like 118893
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot  fail like 118893
 test-amd64-i386-libvirt   7 xen-boot fail  like 118893
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot   fail like 118893
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-bootfail like 118893
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot   fail like 118893
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot  fail like 118893
 test-amd64-amd64-xl-pvhv2-intel 12 guest-startfail like 118893
 test-amd64-i386-freebsd10-i386  7 xen-bootfail like 118893
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118893
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118893
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118893
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118893
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118893
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118893
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Julien Grall]

On 12/02/2018 20:12, Mirela Simonovic wrote:

Hi Julien,


Hi Mirela,

Thank you for the review.

I've done pretty much the same work in parallel, but there are few 
additional minor changes I've made. Briefly, the difference is in return 
values that some already implemented functions should return starting 
from v1.0 (and even v0.2 errata). Please let me know whether you omitted 
that intentionally.


Could you give a bit more details here? From a brief look we don't seem 
to implement correctly:
	- CPU_OFF: PSCI_DENY should be return on failure (though it should 
never fail in Xen case) and the check on the vCPU state is pointless.
	- MIGRATE_INFO_TYPE: should technically return int32_t instead of 
uint32_t. That not really matter for now.


If you speak about denying SMC64 call from AArch32, then this is already 
done in vsmccc.c (see vsmccc_call).


I can submit these patches if you want. Currently I have few - one for 
each fix, easier to review. I guess all of them should be squashed with 
the patch you submitted.


One more note - starting from v1.0, PSCI_NOT_SUPPORTED error should be 
returned for all optional functions that are not implemented. Is that 
the case? I.e. when there is no case for a particular function ID in 
do_vpsci_0_2_call the PSCI_NOT_SUPPORTED error will be returned?


This is done by vmsccc_handle_call().
See set_user_regs(regs, 0, ARM_SMCC_ERR_UNKNOWN_FUNCTION) which is 
equivalent to PSCI_NOT_SUPPORTED.


[...]


+static int32_t do_psci_1_0_features(uint32_t psci_func_id)
+{
+    /* /!\ Ordered by function ID and not name */
+    switch ( psci_func_id )
+    {
+    case PSCI_0_2_FN32_PSCI_VERSION:
+    case PSCI_0_2_FN32_CPU_SUSPEND:
+    case PSCI_0_2_FN64_CPU_SUSPEND:


Just a note here - PSCI_FEATURES should return additional information 
just for CPU_SUSPEND (supported power state and mode). AFAIU, that value 
is also 0, so the return code should be fine.


I think so, from what I understood this is inline with CPU_SUSPEND only 
supports 0.2 format.


Cheers,

--
Julien Grall

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

[Xen-devel] [seabios test] 118982: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken pass in 
118934
 test-amd64-amd64-qemuu-nested-amd  4 host-install(4) broken pass in 118934

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

version targeted for testing:
 seabios  4a6dbcea3e412fe12effa2f812f50dd7eae90955
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z  100 days
Failing since115733  2017-11-10 17:19:59 Z   94 days  117 attempts
Testing same since   118668  2018-02-08 04:50:43 Z4 days5 attempts


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

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



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

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

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

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

broken-job test-amd64-amd64-qemuu-nested-amd broken
broken-job test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm broken
broken-step test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm host-install(4)
broken-step test-amd64-amd64-qemuu-nested-amd host-install(4)

Not pushing.


commit 4a6dbcea3e412fe12effa2f812f50dd7eae90955
Author: Nikolay Nikolov 
Date:   Sun Feb 4 17:27:01 2018 +0200

floppy: Use timer_check() in floppy_wait_irq()

Use timer_check() instead of using floppy_motor_counter in BDA for the
timeout check 

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Mirela Simonovic]

Hi Julien,

I've done pretty much the same work in parallel, but there are few 
additional minor changes I've made. Briefly, the difference is in return 
values that some already implemented functions should return starting 
from v1.0 (and even v0.2 errata). Please let me know whether you omitted 
that intentionally.
I can submit these patches if you want. Currently I have few - one for 
each fix, easier to review. I guess all of them should be squashed with 
the patch you submitted.


One more note - starting from v1.0, PSCI_NOT_SUPPORTED error should be 
returned for all optional functions that are not implemented. Is that 
the case? I.e. when there is no case for a particular function ID in 
do_vpsci_0_2_call the PSCI_NOT_SUPPORTED error will be returned?



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

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

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

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

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

---
 We may want to provide a way for the toolstack to specify a PSCI
 version. This could be useful if a guest is expecting a given
 version.

 Changes in v2:
 - Return v1.1 on GET_VERSION call as claimed by this patch
 - Order by function ID the calls in FEATURES call
---
  tools/libxl/libxl_arm.c  |  3 ++-
  xen/arch/arm/domain_build.c  |  1 +
  xen/arch/arm/vpsci.c | 39 ++-
  xen/include/asm-arm/perfc_defn.h |  1 +
  xen/include/asm-arm/psci.h   |  1 +
  xen/include/asm-arm/vpsci.h  |  2 +-
  6 files changed, 44 insertions(+), 3 deletions(-)

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

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

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

index 6ab8ab64d0..e82b62db1a 100644
--- a/xen/arch/arm/vpsci.c
+++ b/xen/arch/arm/vpsci.c
@@ -106,7 +106,11 @@ static int32_t do_psci_cpu_off(uint32_t power_state)
  
  static uint32_t do_psci_0_2_version(void)

  {
-return PSCI_VERSION(0, 2);
+/*
+ * PSCI is backward compatible from 0.2. So we can bump the version
+ * without any issue.
+ */
+return PSCI_VERSION(1, 1);
  }
  
  static register_t do_psci_0_2_cpu_suspend(uint32_t power_state,

@@ -191,6 +195,29 @@ static void do_psci_0_2_system_reset(void)
  domain_shutdown(d,SHUTDOWN_reboot);
  }
  
+static int32_t do_psci_1_0_features(uint32_t psci_func_id)

+{
+/* /!\ Ordered by function ID and not name */
+switch ( psci_func_id )
+{
+case PSCI_0_2_FN32_PSCI_VERSION:
+case PSCI_0_2_FN32_CPU_SUSPEND:
+case PSCI_0_2_FN64_CPU_SUSPEND:


Just a note here - PSCI_FEATURES should return additional information 
just for CPU_SUSPEND (supported power state and mode). AFAIU, that value 
is also 0, so the return code should be fine.



+case PSCI_0_2_FN32_CPU_OFF:
+case PSCI_0_2_FN32_CPU_ON:
+case PSCI_0_2_FN64_CPU_ON:
+case PSCI_0_2_FN32_AFFINITY_INFO:
+case PSCI_0_2_FN64_AFFINITY_INFO:
+case PSCI_0_2_FN32_MIGRATE_INFO_TYPE:
+case PSCI_0_2_FN32_SYSTEM_OFF:
+case PSCI_0_2_FN32_SYSTEM_RESET:
+case PSCI_1_0_FN32_PSCI_FEATURES:
+return 0;
+default:
+return PSCI_NOT_SUPPORTED;
+}
+}
+
  #define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
  #define PSCI_ARG(reg, n) get_user_reg(reg, n)
  
@@ -304,6 +331,16 @@ bool do_vpsci_0_2_call(struct cpu_user_regs *regs, uint32_t fid)

  PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
  return true;
  }
+
+case PSCI_1_0_FN32_PSCI_FEATURES:
+{
+uint32_t psci_func_id = PSCI_ARG32(regs, 1);
+
+perfc_incr(vpsci_features);
+

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  a08df2278be1a8d5b677f0ba78e13ca20ae141f8
baseline version:
 xtf  9eeb26f3faeb25925c0cfde9ec18571fdbfbe4fa

Last test of basis   118484  2018-01-31 12:18:50 Z   12 days
Testing same since   119006  2018-02-12 15:15:50 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 :

To xenbits.xen.org:/home/xen/git/xtf.git
   9eeb26f..a08df22  a08df2278be1a8d5b677f0ba78e13ca20ae141f8 -> 
xen-tested-master

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

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

[Julien Grall]

Hi all,

Quick reminder, the meeting will be tomorrow (Tuesday 13th February) at 
5PM UTC. We will use uberconference for the meeting:


  Join the call: https://www.uberconference.com/stefano-stabellini
  Optional dial in number: 669-999-0613
  No PIN needed

Cheers,

On 06/02/18 10:11, Julien Grall wrote:

Hi all,

I would suggest to have the next community call on Tuesday 13th February 
5pm GMT. Does it sound good?


Do you have any specific topic you would like to discuss?

Cheers,



--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 22/49] ARM: new VGIC: Implement virtual IRQ injection

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

Provide a vgic_queue_irq_unlock() function which decides whether a
given IRQ needs to be queued to a VCPU's ap_list.
This should be called whenever an IRQ becomes pending or enabled,
either as a result of a hardware IRQ injection, from devices emulated by
Xen (like the architected timer) or from MMIO accesses to the distributor
emulation.
Also provides the necessary functions to allow to inject an IRQ to a guest.
Since this is the first code that starts using our locking mechanism,
we add some (hopefully) clear documentation of our locking strategy and
requirements along with this patch.

This is based on Linux commit 81eeb95ddbab, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/vgic/vgic.c | 224 +++
  xen/arch/arm/vgic/vgic.h |  10 +++
  2 files changed, 234 insertions(+)

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
index 3075091caa..f517df6d00 100644
--- a/xen/arch/arm/vgic/vgic.c
+++ b/xen/arch/arm/vgic/vgic.c
@@ -21,6 +21,32 @@
  #include 
  #include "vgic.h"
  
+/*

+ * Locking order is always:
+ * kvm->lock (mutex)


You probably want to update the locking order to match Xen one. In that 
case, I am not sure if we need to take the domain lock in the code?




+ *   its->cmd_lock (mutex)
+ * its->its_lock (mutex)



+ *   vgic_cpu->ap_list_lock
+ * kvm->lpi_list_lock
+ *   vgic_irq->irq_lock
+ *
+ * If you need to take multiple locks, always take the upper lock first,
+ * then the lower ones, e.g. first take the its_lock, then the irq_lock.
+ * If you are already holding a lock and need to take a higher one, you
+ * have to drop the lower ranking lock first and re-aquire it after having


s/re-aquite/acquire/


+ * taken the upper one.
+ *
+ * When taking more than one ap_list_lock at the same time, always take the
+ * lowest numbered VCPU's ap_list_lock first, so:
+ *   vcpuX->vcpu_id < vcpuY->vcpu_id:
+ * spin_lock(vcpuX->arch.vgic_cpu.ap_list_lock);
+ * spin_lock(vcpuY->arch.vgic_cpu.ap_list_lock);
+ *
+ * Since the VGIC must support injecting virtual interrupts from ISRs, we have
+ * to use the spin_lock_irqsave/spin_unlock_irqrestore versions of outer
+ * spinlocks for any lock that may be taken while injecting an interrupt.


It is quite nice to see the locking explained in the file and in general 
a lot of explanation within the code :).



+ */
+
  /*
   * Iterate over the VM's list of mapped LPIs to find the one with a
   * matching interrupt ID and return a reference to the IRQ structure.
@@ -97,6 +123,204 @@ void vgic_put_irq(struct domain *d, struct vgic_irq *irq)
  xfree(irq);
  }
  
+/**

+ * vgic_target_oracle - compute the target vcpu for an irq
+ *
+ * @irq:The irq to route. Must be already locked.
+ *
+ * Based on the current state of the interrupt (enabled, pending,
+ * active, vcpu and target_vcpu), compute the next vcpu this should be
+ * given to. Return NULL if this shouldn't be injected at all.
+ *
+ * Requires the IRQ lock to be held.
+ */
+static struct vcpu *vgic_target_oracle(struct vgic_irq *irq)
+{
+ASSERT(spin_is_locked(>irq_lock));
+
+/* If the interrupt is active, it must stay on the current vcpu */
+if ( irq->active )
+return irq->vcpu ? : irq->target_vcpu;
I am not sure to understand why you check whether irq->vcpu is NULL. If 
the interrupt is active, then irq->vcpu should be NULL. Did I miss anything?



+
+/*
+ * If the IRQ is not active but enabled and pending, we should direct
+ * it to its configured target VCPU.
+ * If the distributor is disabled, pending interrupts shouldn't be
+ * forwarded.
+ */
+if ( irq->enabled && irq_is_pending(irq) )
+{
+if ( unlikely(irq->target_vcpu &&
+ !irq->target_vcpu->domain->arch.vgic.enabled) )


The indentation looks wrong here.


+return NULL;
+
+return irq->target_vcpu;
+}
+
+/* If neither active nor pending and enabled, then this IRQ should not


Comment style:

/*
 * ...


+ * be queued to any VCPU.
+ */
+return NULL;
+}
+
+/*
+ * Only valid injection if changing level for level-triggered IRQs or for a
+ * rising edge.
+ */
+static bool vgic_validate_injection(struct vgic_irq *irq, bool level)
+{
+switch (irq->config)


switch ( ... )


+{
+case VGIC_CONFIG_LEVEL:
+return irq->line_level != level;
+case VGIC_CONFIG_EDGE:
+return level;
+}
+


I would add an ASSERT_UNREACHABLE().


+return false;
+}
+
+/*
+ * Check whether an IRQ needs to (and can) be queued to a VCPU's ap list.
+ * Do the queuing if necessary, taking the right locks in the right order.
+ * Returns true when the IRQ was queued, false otherwise.
+ *
+ * Needs to be entered with the IRQ lock already held, but will return
+ * with all locks dropped.
+ */
+bool vgic_queue_irq_unlock(struct 

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

[Andrew Cooper]

On 12/02/18 18:41, Roger Pau Monné wrote:
> On Mon, Feb 12, 2018 at 03:04:21PM +, Andrew Cooper wrote:
>> On 12/02/18 14:39, Wei Liu wrote:
>>> On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote:
  .macro ALTERNATIVE oldinstr, newinstr, feature
  .L\@_orig_s:
  \oldinstr
  .L\@_orig_e:
 + .skip (-((repl_len(1) - orig_len) > 0) * (repl_len(1) - orig_len)), 
 0x90
>>> Seeing the negation at the beginning, I suppose this should also be a
>>> gas specific macro?
>> The build failures are because clang's integrated assembler can't cope
>> with non-absolute references with .skip, but we already know about this
>> and have code identical to this in tree.  (I temporarily removed it in
>> patch 4).
> Newer clang (6) supports .skip with labels, but doesn't support the
> (-(... And it's having some issues with the rest of the expression,
> will have to check more closely tomorrow.
>
> I wonder, what's Linux doing in this regard? It seems like clang/llvm
> is quite committed to support building Linux, so it might be good to
> follow suit in this case.

This is basically the same as what Linux does.  Linux unconditionally
uses -no-integrated-as.

~Andrew

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

Re: [Xen-devel] RTDS with extra time issue

[Andrii Anisov]

Dario,


On 12.02.18 12:20, Andrii Anisov wrote:
Actually as per Meng's explanation and calculations the problem was on 
my side - wrong DomR task/VCPU parameters.
I was running the system with dummy loads and values received from 
CARTS and all seems to be ok (no deadline misses occured).
Well, what I expressed as dummy loads was all domains are generic armv8 
kernels with minimal fs'es running `dd if=/dev/zero of=/dev/null`, 
except DomR. In this case no DL misses occurred with parameters given by 
CARTS.


Now I have real driver domain, Android with GPU sharing. Loads are like 
youtube playback in DomA, dd from mmc through ssh in DomD. And I see 
unexpected DL misses for the same RT configurations.


Well this provides some ground for another my concern about XEN 
scheduling approach. My doubt is that scheduling is done within softirq, 
so all time spent with pcpu for exception itself and possible timer 
actions is accounted for the vcpu which context was interrupted. This 
seems to be not really fair and might be disruptive for RT scheduling.


--

*Andrii Anisov*



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

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 03:04:21PM +, Andrew Cooper wrote:
> On 12/02/18 14:39, Wei Liu wrote:
> > On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote:
> >>  .macro ALTERNATIVE oldinstr, newinstr, feature
> >>  .L\@_orig_s:
> >>  \oldinstr
> >>  .L\@_orig_e:
> >> + .skip (-((repl_len(1) - orig_len) > 0) * (repl_len(1) - orig_len)), 
> >> 0x90
> > Seeing the negation at the beginning, I suppose this should also be a
> > gas specific macro?
> 
> The build failures are because clang's integrated assembler can't cope
> with non-absolute references with .skip, but we already know about this
> and have code identical to this in tree.  (I temporarily removed it in
> patch 4).

Newer clang (6) supports .skip with labels, but doesn't support the
(-(... And it's having some issues with the rest of the expression,
will have to check more closely tomorrow.

I wonder, what's Linux doing in this regard? It seems like clang/llvm
is quite committed to support building Linux, so it might be good to
follow suit in this case.

Roger.

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

Re: [Xen-devel] [RFC PATCH 17/49] ARM: timer: Handle level triggered IRQs correctly

[Andre Przywara]

Hi,

On 12/02/18 15:19, Julien Grall wrote:
> Hi Andre,
> 
> On 09/02/18 14:39, Andre Przywara wrote:
>> The ARM Generic Timer uses a level-sensitive interrupt semantic. We
>> easily catch when the line goes high, as this triggers the hardware IRQ.
>> However we have to sync the state of the interrupt condition at certain
>> points to catch when the line goes low and we can remove the vtimer vIRQ
>> from the vGIC (and the LR).
>> The VGIC in Xen so far only implemented edge triggered vIRQs, really, so
>> we need to add new functionality to re-sample the interrupt state.
> 
> You might want to make a summary of the discussion we had with Marc Z.
> today here. This would help the other to understand why sample the
> interrupt state is necessary :).

Yes, I just saw that I somehow missed copying the elaborate comment from
Christoffer. Fixed now, indeed without this background it's next to
impossible to understand this ;-)

> Also do we need to do that for the emulated physical timer?

Mmh, good question. I believe this whole timer story needs a good think
again.

>>
>> Signed-off-by: Andre Przywara 
>> ---
>>   xen/arch/arm/time.c | 34 ++
>>   xen/arch/arm/traps.c    |  1 +
>>   xen/include/xen/timer.h |  2 ++
>>   3 files changed, 37 insertions(+)
>>
>> diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
>> index c11fcfeadd..98ebb4305d 100644
>> --- a/xen/arch/arm/time.c
>> +++ b/xen/arch/arm/time.c
>> @@ -263,6 +263,40 @@ static void vtimer_interrupt(int irq, void
>> *dev_id, struct cpu_user_regs *regs)
>>   vgic_inject_irq(current->domain, current,
>> current->arch.virt_timer.irq, true);
>>   }
>>   +/**
> 
> One * is enough.

That's kernel-doc comment style:
https://www.kernel.org/doc/html/v4.9/kernel-documentation.html#writing-kernel-doc-comments

That allows tools to scan the tree and extract function documentation in
an automated way. A bit like markdown: still perfectly readable by
humans, but parse-able by scripts as well.

I was hoping that it wouldn't hurt to have this in Xen as well, as I
copied this already in other parts of this code.

>> + * vtimer_sync() - update the state of the virtual timer after a
>> guest run
>> + * @vcpu: The VCPU to sync the arch timer state
>> + *
>> + * After returning from a guest, update the state of the virtual
>> interrupt
>> + * line, to model the level triggered interrupt correctly.
>> + * If the guest has handled a timer interrupt, the virtual interrupt
>> line
>> + * needs to be lowered explicitly. vgic_inject_irq() takes care of that.
>> + */
>> +void vtimer_sync(struct vcpu *vcpu)
>> +{
>> +    struct vtimer *vtimer = >arch.virt_timer;
>> +    bool level;
>> +
>> +    vtimer->ctl = READ_SYSREG32(CNTV_CTL_EL0);
>> +    vtimer->cval = READ_SYSREG64(CNTV_CVAL_EL0);
> 
> Why do you need to save cval?

Originally I was copying KVM code which checked the actual IRQ condition
(by comparing the counter with CVAL). So this might be a leftover from
there. Need to check whether we actually need an up-to-date value of this.

>> +
>> +    /*
>> + * Technically we should mask with 0x7 here, to catch if the timer
>> + * interrupt is masked. However Xen always masks the timer upon
>> entering
>> + * the hypervisor, leaving it up to the guest to un-mask it.
>> + * So we would always read a "low" level, despite the condition
>> being
>> + * actually "high". Igoring the mask bit solves this (for now).
> 
> s/Igoring/Ignoring/
> 
>> + * Another possible check would be to compare the value of
>> CNTVCT_EL0
>> + * against vtimer->cval and derive the interrupt state from that.
>> + *
>> + * TODO: The proper fix for this is to make vtimer vIRQ hardware
>> mapped,
>> + * but this requires reworking the arch timer to implement this.
> 
> That something we should look at it once the vGIC is done :).

Indeed, looking forward to it (well, somewhat ... ) ;-)

>> + */
>> +    level = (vtimer->ctl & 0x5) == (CNTx_CTL_ENABLE | CNTx_CTL_PENDING);
> 
> Can you please use the proper define rather than plain value?

Ah, right, that was a leftover from experimentation.
Also a test to see if reviewers are really reading this ;-)

>> +
>> +    vgic_inject_irq(vcpu->domain, vcpu, vtimer->irq, level);
>> +}
>> +
>>   /*
>>    * Arch timer interrupt really ought to be level triggered, since the
>>    * design of the timer/comparator mechanism is based around that
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 1cba7e584d..2d770a14a5 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -2024,6 +2024,7 @@ static void enter_hypervisor_head(struct
>> cpu_user_regs *regs)
>>   if ( current->arch.hcr_el2 & HCR_VA )
>>   current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
>>   
> 
> You need to sample the virtual timer before clearing the LRs, right? If
> so, you likely want to add a comment here to avoid reshuffling the code.

Yes, good 

Re: [Xen-devel] [PATCH 6/7] x86/alt: Drop explicit padding of origin sites

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:06AM +, Andrew Cooper wrote:
> Now that the alternatives infrastructure can calculate the required padding
> automatically, there is no need to hard code it.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote:
> The correct amount of padding in an origin patch site can be calculated
> automatically, based on the relative lengths of the replacements.
> 
> This requires a bit of trickery to calculate correctly, especially in the
> ALTENRATIVE_2 case where a branchless max() calculation in needed.  The
> calculation is further complicated because GAS's idea of true is -1 rather
> than 1, which is why the extra negations are required.
> 
> Additionally, have apply_alternatives() attempt to optimise the padding nops.
> 
> Signed-off-by: Andrew Cooper 

LGTM, just a couple of nits:

Reviewed-by: Roger Pau Monné 

> ---
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> ---
>  xen/arch/x86/alternative.c| 32 
>  xen/include/asm-x86/alternative-asm.h | 40 
> +++
>  xen/include/asm-x86/alternative.h | 39 ++
>  3 files changed, 89 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
> index f8ddab5..ec87ff4 100644
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -180,13 +180,37 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>  uint8_t *orig = ALT_ORIG_PTR(a);
>  uint8_t *repl = ALT_REPL_PTR(a);
>  uint8_t buf[MAX_PATCH_LEN];
> +unsigned int total_len = a->orig_len + a->pad_len;
>  
> -BUG_ON(a->repl_len > a->orig_len);
> -BUG_ON(a->orig_len > sizeof(buf));
> +BUG_ON(a->repl_len > total_len);
> +BUG_ON(total_len > sizeof(buf));
>  BUG_ON(a->cpuid >= NCAPINTS * 32);
>  
>  if ( !boot_cpu_has(a->cpuid) )
> +{
> +unsigned int i;
> +
> +/* No replacement to make, but try to optimise any padding. */
> +if ( a->pad_len <= 1 )
> +continue;
> +
> +/* Search the padding area for any byte which isn't a nop. */
> +for ( i = a->orig_len; i < total_len; ++i )
> +if ( orig[i] != 0x90 )

Maybe better to compare against ASM_NOP1?

> +break;
> +
> +/*
> + * Only make any changes if all padding bytes are unoptimised
> + * nops.  With multiple alternatives over the same origin site, 
> we
> + * may have already made a replacement, or optimised the nops.
> + */
> +if ( i != total_len )
> +continue;
> +
> +add_nops(buf, a->pad_len);
> +text_poke(orig + a->orig_len, buf, a->pad_len);
>  continue;
> +}
>  
>  memcpy(buf, repl, a->repl_len);
>  
> @@ -194,8 +218,8 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>  if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
>  *(s32 *)(buf + 1) += repl - orig;
>  
> -add_nops(buf + a->repl_len, a->orig_len - a->repl_len);
> -text_poke(orig, buf, a->orig_len);
> +add_nops(buf + a->repl_len, total_len - a->repl_len);
> +text_poke(orig, buf, total_len);
>  }
>  }
>  
> diff --git a/xen/include/asm-x86/alternative-asm.h 
> b/xen/include/asm-x86/alternative-asm.h
> index 150bd1a..f7e37cb 100644
> --- a/xen/include/asm-x86/alternative-asm.h
> +++ b/xen/include/asm-x86/alternative-asm.h
> @@ -9,30 +9,41 @@
>   * enough information for the alternatives patching code to patch an
>   * instruction. See apply_alternatives().
>   */
> -.macro altinstruction_entry orig repl feature orig_len repl_len
> +.macro altinstruction_entry orig repl feature orig_len repl_len pad_len
>  .long \orig - .
>  .long \repl - .
>  .word \feature
>  .byte \orig_len
>  .byte \repl_len
> +.byte \pad_len
>  .endm
>  
>  #define orig_len   (.L\@_orig_e   - .L\@_orig_s)
> +#define pad_len(.L\@_orig_p   - .L\@_orig_e)
> +#define total_len  (.L\@_orig_p   - .L\@_orig_s)
>  #define repl_len(nr)   (.L\@_repl_e\()nr  - .L\@_repl_s\()nr)
>  #define decl_repl(insn, nr) .L\@_repl_s\()nr: insn; .L\@_repl_e\()nr:
> +#define gas_max(a, b)  ((a) ^ (((a) ^ (b)) & -(-((a) < (b)

That seems to work fine at least on newish versions of clang, so I'm
not sure the g prefix is required (as_max).

>  
>  .macro ALTERNATIVE oldinstr, newinstr, feature
>  .L\@_orig_s:
>  \oldinstr
>  .L\@_orig_e:
> + .skip (-((repl_len(1) - orig_len) > 0) * (repl_len(1) - orig_len)), 0x90
> +.L\@_orig_p:
>  
>  .pushsection .altinstructions, "a", @progbits
>  altinstruction_entry .L\@_orig_s, .L\@_repl_s1, \feature, \
> -orig_len, repl_len(1)
> +orig_len, repl_len(1), pad_len

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

[Andrew Cooper]

On 12/02/18 17:26, Roger Pau Monné wrote:
> On Mon, Feb 12, 2018 at 11:23:03AM +, Andrew Cooper wrote:
>>  * On the C side, switch to using local lables rather than hardcoded numbers.
>   ^ labels
>>  * Rename parameters and lables to be consistent with alt_instr names, and
>^ labels
>>consistent between the the C and asm versions.
>>  * On the asm side, factor some expressions out into macros to aid clarity.
>>  * Consistently declare section attributes.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
>
> Just one nit...
>
>> ---
>> CC: Jan Beulich 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Roger Pau Monné 
>> CC: Wei Liu 
>> ---
>>  xen/include/asm-x86/alternative-asm.h | 57 +--
>>  xen/include/asm-x86/alternative.h | 64 
>> +++
>>  2 files changed, 67 insertions(+), 54 deletions(-)
>>
>> diff --git a/xen/include/asm-x86/alternative-asm.h 
>> b/xen/include/asm-x86/alternative-asm.h
>> index 6640e85..150bd1a 100644
>> --- a/xen/include/asm-x86/alternative-asm.h
>> +++ b/xen/include/asm-x86/alternative-asm.h
>> @@ -9,60 +9,67 @@
>>   * enough information for the alternatives patching code to patch an
>>   * instruction. See apply_alternatives().
>>   */
>> -.macro altinstruction_entry orig alt feature orig_len alt_len
>> +.macro altinstruction_entry orig repl feature orig_len repl_len
>>  .long \orig - .
>> -.long \alt - .
>> +.long \repl - .
>>  .word \feature
>>  .byte \orig_len
>> -.byte \alt_len
>> +.byte \repl_len
>>  .endm
>>  
>> +#define orig_len   (.L\@_orig_e   - .L\@_orig_s)
>> +#define repl_len(nr)   (.L\@_repl_e\()nr  - .L\@_repl_s\()nr)
>> +#define decl_repl(insn, nr) .L\@_repl_s\()nr: insn; .L\@_repl_e\()nr:
> I would also introduce a decl_orig(insn), seeing that ".L\@_orig_s" is
> already used in two different places (ALTERNATIVE and ALTERNATIVE_2).

Actually, in combination with patch 5, that makes things less clear.  (I
already did as you suggested, then took it out.)

~Andrew

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

Re: [Xen-devel] [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ

[Andre Przywara]

Hi,

On 12/02/18 13:55, Julien Grall wrote:
> Hi Andre,
> 
> On 09/02/18 14:39, Andre Przywara wrote:
>> When playing around with hardware mapped, level triggered virtual IRQs,
>> there is the need to explicitly set the active state of an interrupt at
>> some point in time.
>> To prepare the GIC for that, we introduce a set_active_state() function
>> to let the VGIC manipulate the state of an associated hardware IRQ.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>   xen/arch/arm/gic-v2.c |  9 +
>>   xen/arch/arm/gic-v3.c | 16 
>>   xen/arch/arm/gic.c    |  5 +
>>   xen/include/asm-arm/gic.h |  5 +
>>   4 files changed, 35 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
>> index 2e35892881..5339f69fbc 100644
>> --- a/xen/arch/arm/gic-v2.c
>> +++ b/xen/arch/arm/gic-v2.c
>> @@ -235,6 +235,14 @@ static unsigned int gicv2_read_irq(void)
>>   return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
>>   }
>>   +static void gicv2_set_active_state(int irq, bool active)
> 
> I would much prefer to have an irq_desc in parameter. This is matching
> the other interface 

... and that's why I had it just like this in my first version. However
this proved to be nasty because I now need to get this irq_desc pointer
first, as the caller doesn't have it already. Since all we have and need
is the actual hardware IRQ number, I found it more straight-forward to
just use that number directly instead of going via the pointer and back
(h/w intid => irq_desc => irq).

> and you could update the flags such as
> _IRQ_INPROGRESS which you don't do at the moment.

Mmh, interesting point. I guess I should also clear this bit in the new
VGIC. At least once I wrapped my head around what this flag is
*actually* for (in conjunction with _IRQ_GUEST).
Anyway I guess this bit would still be set in our case.

> Also, who is preventing two CPUs to clear the active bit at the same time?

A certain hardware IRQ is assigned to one virtual IRQ on one VCPU at one
time only. Besides, GICD_ICACTIVERn has wired NAND semantics, so that's
naturally race free (as it was designed to be).
Unless I miss something here (happy to be pointed to an example where it
causes problems).

>> +{
>> +    if (active)
>> +    writel_gicd(1U << (irq % 32), GICD_ISACTIVER + (irq / 32) * 4);
>> +    else
>> +    writel_gicd(1U << (irq % 32), GICD_ICACTIVER + (irq / 32) * 4);
> 
> You will have a few places in the code usually similar construct. It
> would make sense to introduce a helper poke as we have in the GICv3 code.

Sure.

>> +}
>> +
>>   static void gicv2_set_irq_type(struct irq_desc *desc, unsigned int
>> type)
>>   {
>>   uint32_t cfg, actual, edgebit;
>> @@ -1241,6 +1249,7 @@ const static struct gic_hw_operations gicv2_ops = {
>>   .eoi_irq = gicv2_eoi_irq,
>>   .deactivate_irq  = gicv2_dir_irq,
>>   .read_irq    = gicv2_read_irq,
>> +    .set_active_state    = gicv2_set_active_state,
>>   .set_irq_type    = gicv2_set_irq_type,
>>   .set_irq_priority    = gicv2_set_irq_priority,
>>   .send_SGI    = gicv2_send_SGI,
>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>> index 08d4703687..595eaef43a 100644
>> --- a/xen/arch/arm/gic-v3.c
>> +++ b/xen/arch/arm/gic-v3.c
>> @@ -475,6 +475,21 @@ static unsigned int gicv3_read_irq(void)
>>   return irq;
>>   }
>>   +static void gicv3_set_active_state(int irq, bool active)
>> +{
>> +    void __iomem *base;
>> +
>> +    if ( irq >= NR_GIC_LOCAL_IRQS)
>> +    base = GICD + (irq / 32) * 4;
>> +    else
>> +    base = GICD_RDIST_SGI_BASE;
>> +
>> +    if ( active )
>> +    writel(1U << (irq % 32), base + GICD_ISACTIVER);
>> +    else
>> +    writel(1U << (irq % 32), base + GICD_ICACTIVER);
> 
> Shouldn't you wait until RWP bits is cleared here?

I don't see why. I think this action has some posted semantics anyway,
so no need for any synchronisation. And also RWP does not track
I[SC]ACTIVER, only ICENABLER and some CTLR bits (ARM IHI 0069D, 8.9.4:
RWP[31]).

> 
>> +}
> 
> Why don't you use the function poke?

Ah, I didn't see this. But then this now does this quite costly RWP
dance now. We could add a check in there to only do this if we change
the affected registers or pass an explicit "bool wait_for_rwp" in there.

Thanks for staying awake on this ;-)

Cheers,
Andre.

>> +
>>   static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
>>   {
>>    uint64_t mpidr = cpu_logical_map(cpu);
>> @@ -1722,6 +1737,7 @@ static const struct gic_hw_operations gicv3_ops = {
>>   .eoi_irq = gicv3_eoi_irq,
>>   .deactivate_irq  = gicv3_dir_irq,
>>   .read_irq    = gicv3_read_irq,
>> +    .set_active_state    = gicv3_set_active_state,
>>   .set_irq_type    = gicv3_set_irq_type,
>>   .set_irq_priority    = gicv3_set_irq_priority,
>>   .send_SGI    = gicv3_send_sgi,
>> diff --git 

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

[Andrew Cooper]

On 12/02/18 17:18, Wei Liu wrote:
> On Mon, Feb 12, 2018 at 04:52:21PM +, Roger Pau Monné wrote:
>> On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote:
>>>  * Rename some fields for consistency and clarity, and use standard types.
>>>  * Don't opencode the use of ALT_{ORIG,REPL}_PTR().
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper 
>> Reviewed-by: Roger Pau Monné 
>>
>>> ---
>>> CC: Jan Beulich 
>>> CC: Konrad Rzeszutek Wilk 
>>> CC: Roger Pau Monné 
>>> CC: Wei Liu 
>>> ---
>>>  xen/arch/x86/alternative.c| 24 
>>>  xen/include/asm-x86/alternative.h | 12 ++--
>>>  2 files changed, 18 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
>>> index 5c8b6f6..f8ddab5 100644
>>> --- a/xen/arch/x86/alternative.c
>>> +++ b/xen/arch/x86/alternative.c
>>> @@ -163,8 +163,6 @@ void init_or_livepatch apply_alternatives(const struct 
>>> alt_instr *start,
>>>const struct alt_instr *end)
>>>  {
>>>  const struct alt_instr *a;
>>> -u8 *instr, *replacement;
>>> -u8 insnbuf[MAX_PATCH_LEN];
>>>  
>>>  printk(KERN_INFO "alt table %p -> %p\n", start, end);
>>>  
>>> @@ -179,23 +177,25 @@ void init_or_livepatch apply_alternatives(const 
>>> struct alt_instr *start,
>>>   */
>>>  for ( a = start; a < end; a++ )
>>>  {
>>> -instr = (u8 *)>instr_offset + a->instr_offset;
>>> -replacement = (u8 *)>repl_offset + a->repl_offset;
>>> -BUG_ON(a->replacementlen > a->instrlen);
>>> -BUG_ON(a->instrlen > sizeof(insnbuf));
>>> +uint8_t *orig = ALT_ORIG_PTR(a);
>>> +uint8_t *repl = ALT_REPL_PTR(a);
>>> +uint8_t buf[MAX_PATCH_LEN];
>>> +
>>> +BUG_ON(a->repl_len > a->orig_len);
>>> +BUG_ON(a->orig_len > sizeof(buf));
>> Would be nice to have an assembly BUILD_BUG_ON equivalent so that this
>> could be turned into a compile time check and added to ALTINSTR_ENTRY.
>  This function is also used to livepatch the hypervisor.
>
>  I would actually suggest not use BUG_ON here instead but I didn't want
>  to add noise to the problem at hand. :-)

We've got some assembler time checks already, and I've introduced more
in patch 5 which include this sizeof(buf) one.

As for BUG_ON()s, I considered dropping them as well, but the only thing
which will happen if these are skipped is that we will crash in less
obvious ways in the patch points.

~Andrew

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

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
> With future changes, altinstruction_entry is going to become more complicated
> to use.  Furthermore, there are already ALTERNATIVE* macros which can be used
> to avoid opencoding the creation of replacement information.
> 
> For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all
> hardocded label numbers.  For the cr4_pv32 alternatives, this means hardcoding
> the extra space required in the original patch site, but the hardcoding will
> be removed by a later patch.
> 
> No change to any functionality, but the handling of nops inside the original
> patch sites are a bit different.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

In general I try to align the line breaks '\' of macros, but I don't
think that's used consistently across the code at all.

Again just one nit below.

> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index 58f652d..bd3819a 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -557,23 +557,9 @@ handle_exception_saved:
>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>  jzexception_with_ints_disabled
>  
> -.Lcr4_pv32_orig:
> -jmp   .Lcr4_pv32_done
> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - .Lcr4_pv32_orig), 
> 0xcc
> -.pushsection .altinstr_replacement, "ax"
> -.Lcr4_pv32_alt:
> -mov   VCPU_domain(%rbx),%rax
> -.Lcr4_pv32_alt_end:
> -.section .altinstructions, "a"
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMEP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMAP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -.popsection
> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
> +__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMEP, \
> +__stringify(mov VCPU_domain(%rbx), %rax), X86_FEATURE_XEN_SMAP

What's the point of using __stringify here, isn't it clearer to just
use "mov ..."?

Thanks, Roger.

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

Re: [Xen-devel] [RFC PATCH 21/49] ARM: new VGIC: Add acccessor to new struct vgic_irq instance

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

The new VGIC implementation centers around a struct vgic_irq instance
per virtual IRQ.
Provide a function to retrieve the right instance for a given IRQ
number and (in case of private interrupts) the right VCPU.
This also includes the corresponding put function, which does nothing
for private interrupts and SPIs, but handles the ref-counting for LPIs.

This is based on Linux commit 64a959d66e47, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/vgic/vgic.c | 107 +++
  xen/arch/arm/vgic/vgic.h |  32 ++
  2 files changed, 139 insertions(+)
  create mode 100644 xen/arch/arm/vgic/vgic.c
  create mode 100644 xen/arch/arm/vgic/vgic.h

diff --git a/xen/arch/arm/vgic/vgic.c b/xen/arch/arm/vgic/vgic.c
new file mode 100644
index 00..3075091caa
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 "vgic.h"


Please order the include alphabetically.


+
+/*
+ * Iterate over the VM's list of mapped LPIs to find the one with a
+ * matching interrupt ID and return a reference to the IRQ structure.
+ */
+static struct vgic_irq *vgic_get_lpi(struct domain *d, u32 intid)
+{
+struct vgic_dist *dist = >arch.vgic;
+struct vgic_irq *irq = NULL;
+
+spin_lock(>lpi_list_lock);
+
+list_for_each_entry( irq, >lpi_list_head, lpi_list )


I think it would be worth thinking of a different data structure here. 
The number of LPIs can be quite high for the hardware domain.



+{
+if ( irq->intid != intid )
+continue;
+
+/*
+ * This increases the refcount, the caller is expected to
+ * call vgic_put_irq() later once it's finished with the IRQ.
+ */
+vgic_get_irq_kref(irq);
+goto out_unlock;
+}
+irq = NULL;
+
+out_unlock:
+spin_unlock(>lpi_list_lock);
+
+return irq;
+}
+
+/*
+ * This looks up the virtual interrupt ID to get the corresponding
+ * struct vgic_irq. It also increases the refcount, so any caller is expected
+ * to call vgic_put_irq() once it's finished with this IRQ.
+ */
+struct vgic_irq *vgic_get_irq(struct domain *d, struct vcpu *vcpu,
+  u32 intid)


Indentation.


+{
+/* SGIs and PPIs */
+if ( intid <= VGIC_MAX_PRIVATE )
+return >arch.vgic_cpu.private_irqs[intid];
+
+/* SPIs */
+if ( intid <= VGIC_MAX_SPI )
+return >arch.vgic.spis[intid - VGIC_NR_PRIVATE_IRQS];
+
+/* LPIs */
+if ( intid >= VGIC_MIN_LPI )
+return vgic_get_lpi(d, intid);
+
+WARN();


Newline here please.

I would turn into an ASSERT_UNREACHABLE() so it is only happening in 
debug build and avoid to worry about a guest exploiting that :).



+return NULL;
+}
+
+void vgic_put_irq(struct domain *d, struct vgic_irq *irq)
+{
+struct vgic_dist *dist = >arch.vgic;
+
+if ( irq->intid < VGIC_MIN_LPI )
+return;
+
+spin_lock(>lpi_list_lock);
+if ( !atomic_dec_and_test(>refcount) )
+{
+spin_unlock(>lpi_list_lock);
+return;
+};
+
+list_del(>lpi_list);


I would add

ASSERT(lpi_list_count >= 1);

But it is a bit hard to know whether this code is valid given you don't 
have any implementation of ITS so far.



+dist->lpi_list_count--;
+spin_unlock(>lpi_list_lock);
+
+xfree(irq);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/vgic/vgic.h b/xen/arch/arm/vgic/vgic.h
new file mode 100644
index 00..7a15cfdd79
--- /dev/null
+++ b/xen/arch/arm/vgic/vgic.h


To be honest, I am not a big fan of headers defined in the code bits. So 
I would need a reason for that to be there and not in the include you 
defined in the previous patch.



@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ * Imported from Linux ("new" KVM VGIC) and heavily adapted to Xen.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it 

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:03AM +, Andrew Cooper wrote:
>  * On the C side, switch to using local lables rather than hardcoded numbers.
  ^ labels
>  * Rename parameters and lables to be consistent with alt_instr names, and
   ^ labels
>consistent between the the C and asm versions.
>  * On the asm side, factor some expressions out into macros to aid clarity.
>  * Consistently declare section attributes.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

Just one nit...

> ---
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> ---
>  xen/include/asm-x86/alternative-asm.h | 57 +--
>  xen/include/asm-x86/alternative.h | 64 
> +++
>  2 files changed, 67 insertions(+), 54 deletions(-)
> 
> diff --git a/xen/include/asm-x86/alternative-asm.h 
> b/xen/include/asm-x86/alternative-asm.h
> index 6640e85..150bd1a 100644
> --- a/xen/include/asm-x86/alternative-asm.h
> +++ b/xen/include/asm-x86/alternative-asm.h
> @@ -9,60 +9,67 @@
>   * enough information for the alternatives patching code to patch an
>   * instruction. See apply_alternatives().
>   */
> -.macro altinstruction_entry orig alt feature orig_len alt_len
> +.macro altinstruction_entry orig repl feature orig_len repl_len
>  .long \orig - .
> -.long \alt - .
> +.long \repl - .
>  .word \feature
>  .byte \orig_len
> -.byte \alt_len
> +.byte \repl_len
>  .endm
>  
> +#define orig_len   (.L\@_orig_e   - .L\@_orig_s)
> +#define repl_len(nr)   (.L\@_repl_e\()nr  - .L\@_repl_s\()nr)
> +#define decl_repl(insn, nr) .L\@_repl_s\()nr: insn; .L\@_repl_e\()nr:

I would also introduce a decl_orig(insn), seeing that ".L\@_orig_s" is
already used in two different places (ALTERNATIVE and ALTERNATIVE_2).

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2 11/15] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Julien Grall]

On 12/02/18 17:20, Volodymyr Babchuk wrote:

Julien,


Hi,


On 12.02.18 19:12, Julien Grall wrote:

On 12/02/18 16:55, Volodymyr Babchuk wrote:

Hi Julien,


Hi Volodymyr,


On 08.02.18 21:21, Julien Grall wrote:

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Patch added
---
  xen/arch/arm/arm64/bpi.S    | 12 
  xen/arch/arm/cpuerrata.c    | 32 +++-
  xen/include/asm-arm/smccc.h |  1 +
  3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..ef237de7bd 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
   * along with this program.  If not, see 
.

   */
+#include 
+
  .macro ventry target
  .rept 31
  nop
@@ -81,6 +83,16 @@ ENTRY(__psci_hyp_bp_inval_start)
  add sp, sp, #(8 * 18)
  ENTRY(__psci_hyp_bp_inval_end)
+ENTRY(__smccc_workaround_1_smc_start)
+    sub sp, sp, #(8 * 4)
+    stp x2, x3, [sp, #(8 * 0)]
+    stp x0, x1, [sp, #(8 * 2)]
+    mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+    ldp x2, x3, [sp, #(8 * 0)]
+    ldp x0, x1, [sp, #(8 * 2)]
+    add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+


This code confuses me. You allocate 32 bytes on stack, save x0-x4 
there, then you load ARM_SMCCC_ARCH_WORKAROUND_1_FID into w0 and 
restore values of x0-x4, overwriting value written into w0. Am I 
missing something?


The call to ARM_SMCCC_ARCH_WORKAROUND_1 does not return any value. 
Even if it were, this code is executed on exception entry before 
jumping into the trap helper. So you want to restore all the registers 
saved.



I believe you missed smc instruction in the code above.


Whoops yes. I will fix it.





Btw, you can use something like stp    x0, x1, [sp, #-16]! to avoid 
manual adjustment of sp. This will save you two instructions.


It was pointed out on Linux Arm that updating sp once *might* be 
faster on some uarch.


So is this code is targeted for that some specific uarch? Then I would 
like to see a comment describing why you choose this approach.


I can't confirm whether this will improve uarch A, B, C or Z. I just 
followed suggestion on Linux Arm (see [1]) and a personal choice on how 
to write assembly code. It is quite similar that why would I choose the 
other way around?


Cheers,

[1] https://www.spinics.net/lists/arm-kernel/msg626659.html

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 11/15] xen/arm64: Add ARM_SMCCC_ARCH_WORKAROUND_1 BP hardening support

[Volodymyr Babchuk]

Julien,

On 12.02.18 19:12, Julien Grall wrote:

On 12/02/18 16:55, Volodymyr Babchuk wrote:

Hi Julien,


Hi Volodymyr,


On 08.02.18 21:21, Julien Grall wrote:

Add the detection and runtime code for ARM_SMCCC_ARCH_WORKAROUND_1.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Patch added
---
  xen/arch/arm/arm64/bpi.S    | 12 
  xen/arch/arm/cpuerrata.c    | 32 +++-
  xen/include/asm-arm/smccc.h |  1 +
  3 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/arm64/bpi.S b/xen/arch/arm/arm64/bpi.S
index 4b7f1dc21f..ef237de7bd 100644
--- a/xen/arch/arm/arm64/bpi.S
+++ b/xen/arch/arm/arm64/bpi.S
@@ -16,6 +16,8 @@
   * along with this program.  If not, see 
.

   */
+#include 
+
  .macro ventry target
  .rept 31
  nop
@@ -81,6 +83,16 @@ ENTRY(__psci_hyp_bp_inval_start)
  add sp, sp, #(8 * 18)
  ENTRY(__psci_hyp_bp_inval_end)
+ENTRY(__smccc_workaround_1_smc_start)
+    sub sp, sp, #(8 * 4)
+    stp x2, x3, [sp, #(8 * 0)]
+    stp x0, x1, [sp, #(8 * 2)]
+    mov w0, #ARM_SMCCC_ARCH_WORKAROUND_1_FID
+    ldp x2, x3, [sp, #(8 * 0)]
+    ldp x0, x1, [sp, #(8 * 2)]
+    add sp, sp, #(8 * 4)
+ENTRY(__smccc_workaround_1_smc_end)
+


This code confuses me. You allocate 32 bytes on stack, save x0-x4 
there, then you load ARM_SMCCC_ARCH_WORKAROUND_1_FID into w0 and 
restore values of x0-x4, overwriting value written into w0. Am I 
missing something?


The call to ARM_SMCCC_ARCH_WORKAROUND_1 does not return any value. Even 
if it were, this code is executed on exception entry before jumping into 
the trap helper. So you want to restore all the registers saved.



I believe you missed smc instruction in the code above.



Btw, you can use something like stp    x0, x1, [sp, #-16]! to avoid 
manual adjustment of sp. This will save you two instructions.


It was pointed out on Linux Arm that updating sp once *might* be faster 
on some uarch.


So is this code is targeted for that some specific uarch? Then I would 
like to see a comment describing why you choose this approach.


[...]

--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

[Wei Liu]

On Mon, Feb 12, 2018 at 04:52:21PM +, Roger Pau Monné wrote:
> On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote:
> >  * Rename some fields for consistency and clarity, and use standard types.
> >  * Don't opencode the use of ALT_{ORIG,REPL}_PTR().
> > 
> > No functional change.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Roger Pau Monné 
> 
> > ---
> > CC: Jan Beulich 
> > CC: Konrad Rzeszutek Wilk 
> > CC: Roger Pau Monné 
> > CC: Wei Liu 
> > ---
> >  xen/arch/x86/alternative.c| 24 
> >  xen/include/asm-x86/alternative.h | 12 ++--
> >  2 files changed, 18 insertions(+), 18 deletions(-)
> > 
> > diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
> > index 5c8b6f6..f8ddab5 100644
> > --- a/xen/arch/x86/alternative.c
> > +++ b/xen/arch/x86/alternative.c
> > @@ -163,8 +163,6 @@ void init_or_livepatch apply_alternatives(const struct 
> > alt_instr *start,
> >const struct alt_instr *end)
> >  {
> >  const struct alt_instr *a;
> > -u8 *instr, *replacement;
> > -u8 insnbuf[MAX_PATCH_LEN];
> >  
> >  printk(KERN_INFO "alt table %p -> %p\n", start, end);
> >  
> > @@ -179,23 +177,25 @@ void init_or_livepatch apply_alternatives(const 
> > struct alt_instr *start,
> >   */
> >  for ( a = start; a < end; a++ )
> >  {
> > -instr = (u8 *)>instr_offset + a->instr_offset;
> > -replacement = (u8 *)>repl_offset + a->repl_offset;
> > -BUG_ON(a->replacementlen > a->instrlen);
> > -BUG_ON(a->instrlen > sizeof(insnbuf));
> > +uint8_t *orig = ALT_ORIG_PTR(a);
> > +uint8_t *repl = ALT_REPL_PTR(a);
> > +uint8_t buf[MAX_PATCH_LEN];
> > +
> > +BUG_ON(a->repl_len > a->orig_len);
> > +BUG_ON(a->orig_len > sizeof(buf));
> 
> Would be nice to have an assembly BUILD_BUG_ON equivalent so that this
> could be turned into a compile time check and added to ALTINSTR_ENTRY.

 This function is also used to livepatch the hypervisor.

 I would actually suggest not use BUG_ON here instead but I didn't want
 to add noise to the problem at hand. :-)

 Wei.

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

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote:
>  * Rename some fields for consistency and clarity, and use standard types.
>  * Don't opencode the use of ALT_{ORIG,REPL}_PTR().
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

> ---
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> ---
>  xen/arch/x86/alternative.c| 24 
>  xen/include/asm-x86/alternative.h | 12 ++--
>  2 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
> index 5c8b6f6..f8ddab5 100644
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -163,8 +163,6 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>const struct alt_instr *end)
>  {
>  const struct alt_instr *a;
> -u8 *instr, *replacement;
> -u8 insnbuf[MAX_PATCH_LEN];
>  
>  printk(KERN_INFO "alt table %p -> %p\n", start, end);
>  
> @@ -179,23 +177,25 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>   */
>  for ( a = start; a < end; a++ )
>  {
> -instr = (u8 *)>instr_offset + a->instr_offset;
> -replacement = (u8 *)>repl_offset + a->repl_offset;
> -BUG_ON(a->replacementlen > a->instrlen);
> -BUG_ON(a->instrlen > sizeof(insnbuf));
> +uint8_t *orig = ALT_ORIG_PTR(a);
> +uint8_t *repl = ALT_REPL_PTR(a);
> +uint8_t buf[MAX_PATCH_LEN];
> +
> +BUG_ON(a->repl_len > a->orig_len);
> +BUG_ON(a->orig_len > sizeof(buf));

Would be nice to have an assembly BUILD_BUG_ON equivalent so that this
could be turned into a compile time check and added to ALTINSTR_ENTRY.

>  BUG_ON(a->cpuid >= NCAPINTS * 32);
> +
>  if ( !boot_cpu_has(a->cpuid) )
>  continue;
>  
> -memcpy(insnbuf, replacement, a->replacementlen);
> +memcpy(buf, repl, a->repl_len);
>  
>  /* 0xe8/0xe9 are relative branches; fix the offset. */
> -if ( a->replacementlen >= 5 && (*insnbuf & 0xfe) == 0xe8 )
> -*(s32 *)(insnbuf + 1) += replacement - instr;
> +if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
> +*(s32 *)(buf + 1) += repl - orig;

(int32_t *)

>  
> -add_nops(insnbuf + a->replacementlen,
> - a->instrlen - a->replacementlen);
> -text_poke(instr, insnbuf, a->instrlen);
> +add_nops(buf + a->repl_len, a->orig_len - a->repl_len);
> +text_poke(orig, buf, a->orig_len);
>  }
>  }
>  
> diff --git a/xen/include/asm-x86/alternative.h 
> b/xen/include/asm-x86/alternative.h
> index 13ac104..fefa87d 100644
> --- a/xen/include/asm-x86/alternative.h
> +++ b/xen/include/asm-x86/alternative.h
> @@ -9,15 +9,15 @@
>  #include 
>  
>  struct alt_instr {
> -s32 instr_offset;   /* original instruction */
> -s32 repl_offset;/* offset to replacement instruction */
> -u16 cpuid;  /* cpuid bit set for replacement */
> -u8  instrlen;   /* length of original instruction */
> -u8  replacementlen; /* length of new instruction, <= instrlen */
> +int32_t  orig_offset;   /* original instruction */
> +int32_t  repl_offset;   /* offset to replacement instruction */
> +uint16_t cpuid; /* cpuid bit set for replacement */
> +uint8_t  orig_len;  /* length of original instruction */
> +uint8_t  repl_len;  /* length of new instruction, <= instrlen */
>  };
>  
>  #define __ALT_PTR(a,f)  ((u8 *)((void *)&(a)->f + (a)->f))

While there maybe you could also change the above to uint8_t...

> -#define ALT_ORIG_PTR(a) __ALT_PTR(a, instr_offset)
> +#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
>  #define ALT_REPL_PTR(a) __ALT_PTR(a, repl_offset)
>  
>  extern void add_nops(void *insns, unsigned int len);
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [RFC PATCH 20/49] ARM: new VGIC: Add data structure definitions

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

Add a new header file for the new and improved GIC implementation.
The big change is that we now have a struct vgic_irq per IRQ instead
of spreading all the information over various bitmaps in the ranks.

We include this new header conditionally from within the old header
file for the time being to avoid touching all the users.

This is based on Linux commit b18b57787f5e, written by Christoffer Dall.

Signed-off-by: Andre Przywara 
---
  xen/include/asm-arm/arm_vgic.h | 269 +
  xen/include/asm-arm/domain.h   |   4 +
  xen/include/asm-arm/vgic.h |   6 +
  3 files changed, 279 insertions(+)
  create mode 100644 xen/include/asm-arm/arm_vgic.h

diff --git a/xen/include/asm-arm/arm_vgic.h b/xen/include/asm-arm/arm_vgic.h
new file mode 100644
index 00..865e9ee5bc
--- /dev/null
+++ b/xen/include/asm-arm/arm_vgic.h


arm_vgic.h is a confusing name. Can we name it vgic-new.h?


@@ -0,0 +1,269 @@
+/*
+ * Copyright (C) 2015, 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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 .
+ */
+#ifndef __KVM_ARM_VGIC_H
+#define __KVM_ARM_VGIC_H


Please modify the guards based on the file name.


+
+#include 
+#include 
+#include 
+#include 
+
+#define VGIC_V3_MAX_CPUS255
+#define VGIC_V2_MAX_CPUS8
+#define VGIC_NR_IRQS_LEGACY 256
+#define VGIC_NR_SGIS16
+#define VGIC_NR_PPIS16
+#define VGIC_NR_PRIVATE_IRQS(VGIC_NR_SGIS + VGIC_NR_PPIS)
+#define VGIC_MAX_PRIVATE(VGIC_NR_PRIVATE_IRQS - 1)
+#define VGIC_MAX_SPI1019
+#define VGIC_MAX_RESERVED   1023
+#define VGIC_MIN_LPI8192
+
+#define irq_is_ppi(irq) ((irq) >= VGIC_NR_SGIS && (irq) < VGIC_NR_PRIVATE_IRQS)
+#define irq_is_spi(irq) ((irq) >= VGIC_NR_PRIVATE_IRQS && \
+ (irq) <= VGIC_MAX_SPI)
+
+enum vgic_type {
+VGIC_V2,/* Good ol' GICv2 */
+VGIC_V3,/* New fancy GICv3 */
+};
+
+#define VGIC_V2_MAX_LRS (1 << 6)
+#define VGIC_V3_MAX_LRS 16
+#define VGIC_V3_LR_INDEX(lr)(VGIC_V3_MAX_LRS - 1 - lr)
+
+enum vgic_irq_config {
+VGIC_CONFIG_EDGE = 0,


I don't think it is necessary to set 0 here as IIRC an enum always start 
at 0 if not specified.



+VGIC_CONFIG_LEVEL
+};
+
+struct vgic_irq {
+spinlock_t irq_lock;/* Protects the content of the struct */
+struct list_head lpi_list;  /* Used to link all LPIs together */
+struct list_head ap_list;
+
+struct vcpu *vcpu;  /*
+ * SGIs and PPIs: The VCPU
+ * SPIs and LPIs: The VCPU whose ap_list
+ * this is queued on.
+ */
+
+struct vcpu *target_vcpu;   /*
+ * The VCPU that this interrupt should
+ * be sent to, as a result of the
+ * targets reg (v2) or the affinity reg (v3).
+ */
+
+u32 intid;  /* Guest visible INTID */


As we are using Xen coding style, please replace all u* with uint_*.


+bool line_level;/* Level only */
+bool pending_latch; /*
+ * The pending latch state used to
+ * calculate the pending state for both
+ * level and edge triggered IRQs.
+ */
+bool active;/* not used for LPIs */
+bool enabled;
+bool hw;/* Tied to HW IRQ */
+atomic_t refcount;  /* Used for LPIs */
+u32 hwintid;/* HW INTID number */
+union
+{
+u8 targets; /* GICv2 target VCPUs mask */
+u32 mpidr;  /* GICv3 target VCPU */
+};
+u8 source;  /* GICv2 SGIs only */
+u8 priority;
+enum vgic_irq_config config;/* Level or edge */
+};
+
+struct vgic_register_region;


Do we really need the forward declaration here?


+struct vgic_its;
+
+enum iodev_type {
+IODEV_CPUIF,


I don't think this one is necessary.


+IODEV_DIST,
+IODEV_REDIST,
+IODEV_ITS
+};
+
+struct vgic_io_device {
+paddr_t base_addr;
+union
+{
+struct vcpu *redist_vcpu;
+struct vgic_its *its;
+};
+const 

[Xen-devel] [linux-linus test] 118968: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 118324
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Tamas K Lengyel]

On Mon, Feb 12, 2018 at 8:54 AM, Andrew Cooper
 wrote:
> On 12/02/18 15:08, Alexandru Isaila wrote:
>> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>>  break;
>>
>>  case VMEXIT_EXCEPTION_BP:
>> -if ( !v->domain->debugger_attached )
>> -goto unexpected_exit_type;
>> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
>> */
>> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
>> +inst_len = __get_instruction_length(v, INSTR_INT3);
>
> There are multiple ways of ending up with this vmexit, and INT3 is not
> the only way.
>
> The old code was somewhat broken (but only in the case that a debugger
> was attached), but now with  this introspection hook active, executing
> `0xcd 0x03` will end up crashing the domain because of a length mismatch
> looking for 0xcc.
>
> You need to inspect EXITINTINFO to work out what went on here, and
> distinguish INT3 from INT $3.
>
> Can I suggest that you run this unit test
> http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug
> introspection an check that you get all expected events?  Every time we
> touch this code, we seem to break it :(
>

+1, this used to be an issue under vmx as well

Tamas

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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Andrew Cooper]

On 12/02/18 15:56, Roger Pau Monné wrote:
> On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote:
>> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to
>> calculating extra padding length, and we have no need for the complexity.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
>
> I guess you also don't foresee any new features requiring this
> functionality?
>
> I assume this was added because the alternatives framework was picked
> wholesale from Linux, but we have diverged enough that we don't plan
> to sync anymore with Linux?

Linux has dropped it as well.  If we find a usecase, we can reintroduce
it, but someone is going to have some "fun" with max() handling.

~Andrew

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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Roger Pau Monné]

On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote:
> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to
> calculating extra padding length, and we have no need for the complexity.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

I guess you also don't foresee any new features requiring this
functionality?

I assume this was added because the alternatives framework was picked
wholesale from Linux, but we have diverged enough that we don't plan
to sync anymore with Linux?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Andrew Cooper]

On 12/02/18 15:08, Alexandru Isaila wrote:
> @@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
>  break;
>  
>  case VMEXIT_EXCEPTION_BP:
> -if ( !v->domain->debugger_attached )
> -goto unexpected_exit_type;
> -/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. 
> */
> -if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
> +inst_len = __get_instruction_length(v, INSTR_INT3);

There are multiple ways of ending up with this vmexit, and INT3 is not
the only way.

The old code was somewhat broken (but only in the case that a debugger
was attached), but now with  this introspection hook active, executing
`0xcd 0x03` will end up crashing the domain because of a length mismatch
looking for 0xcc.

You need to inspect EXITINTINFO to work out what went on here, and
distinguish INT3 from INT $3.

Can I suggest that you run this unit test
http://xenbits.xen.org/docs/xtf/test-swint-emulation.html under debug
introspection an check that you get all expected events?  Every time we
touch this code, we seem to break it :(

~Andrew

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

Re: [Xen-devel] [PATCH v4 21/28] vvtd: update hvm_gmsi_info when binding guest msi with pirq or

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:28PM +0800, Chao Gao wrote:
> ... handlding guest's invalidation request.
> 
> To support pirq migration optimization and using VT-d posted interrupt to
> inject msi from assigned devices, each time guest programs msi information
> (affinity, vector), the struct hvm_gmsi_info should be updated accordingly.
> But after introducing vvtd, guest only needs to update an IRTE, which is in
> guest memory, to program msi information.  vvtd doesn't trap r/w to the memory
> range. Instead, it traps the queue invalidation, which is a method used to
> notify VT-d hardware that an IRTE has changed.
> 
> This patch updates hvm_gmsi_info structure and programs physical IRTEs to use
> VT-d posted interrupt if possible when binding guest msi with pirq or handling
> guest's invalidation request. For the latter, all physical interrupts bound
> with the domain are gone through to find the ones matching with the IRTE.
> 
> Notes: calling vvtd_process_iq() in vvtd_read() rather than in
> vvtd_handle_irq_request() is to avoid ABBA deadlock of d->event_lock and
> vvtd->ie_lock.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
> v4:
>  - new
> ---
>  xen/arch/x86/hvm/hvm.c |  2 +-
>  xen/drivers/passthrough/io.c   | 89 
> --
>  xen/drivers/passthrough/vtd/vvtd.c | 70 --
>  xen/include/asm-x86/hvm/hvm.h  |  2 +
>  xen/include/asm-x86/hvm/irq.h  |  1 +
>  xen/include/asm-x86/viommu.h   | 11 +
>  6 files changed, 147 insertions(+), 28 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 964418a..d2c1372 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -462,7 +462,7 @@ void hvm_migrate_timers(struct vcpu *v)
>  pt_migrate(v);
>  }
>  
> -static int hvm_migrate_pirq(struct domain *d, struct hvm_pirq_dpci 
> *pirq_dpci,
> +int hvm_migrate_pirq(struct domain *d, struct hvm_pirq_dpci *pirq_dpci,
>  void *arg)
>  {
>  struct vcpu *v = arg;
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index d8c66bf..9198ef5 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -275,6 +276,61 @@ static struct vcpu *vector_hashing_dest(const struct 
> domain *d,
>  return dest;
>  }
>  
> +void pt_update_gmsi(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
> +{
> +uint8_t dest, delivery_mode;
> +bool dest_mode;
> +int dest_vcpu_id;
> +const struct vcpu *vcpu;
> +struct arch_irq_remapping_request request;
> +struct arch_irq_remapping_info remap_info;
> +
> +ASSERT(spin_is_locked(>event_lock));
> +
> +/* Calculate dest_vcpu_id for MSI-type pirq migration. */
> +irq_request_msi_fill(, pirq_dpci->gmsi.addr, 
> pirq_dpci->gmsi.data);
> +if ( viommu_check_irq_remapping(d, ) )
> +{
> +/* An error in IRTE, don't perform the optimization */
> +if ( viommu_get_irq_info(d, , _info) )
> +{
> +pirq_dpci->gmsi.posted = false;
> +pirq_dpci->gmsi.dest_vcpu_id = -1;
> +pirq_dpci->gmsi.gvec = 0;
> +return;
> +}
> +
> +dest = remap_info.dest;
> +dest_mode = remap_info.dest_mode;
> +delivery_mode = remap_info.delivery_mode;
> +pirq_dpci->gmsi.gvec = remap_info.vector;
> +}
> +else
> +{
> +dest = MASK_EXTR(pirq_dpci->gmsi.addr, MSI_ADDR_DEST_ID_MASK);
> +dest_mode = pirq_dpci->gmsi.addr & MSI_ADDR_DESTMODE_MASK;
> +delivery_mode = MASK_EXTR(pirq_dpci->gmsi.data,
> +  MSI_DATA_DELIVERY_MODE_MASK);
> +pirq_dpci->gmsi.gvec = pirq_dpci->gmsi.data & MSI_DATA_VECTOR_MASK;
> +}
> +
> +dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
> +pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
> +
> +pirq_dpci->gmsi.posted = false;
> +vcpu = (dest_vcpu_id >= 0) ? d->vcpu[dest_vcpu_id] : NULL;

So you use dest_vcpu_id to get the vcpu here...

> +if ( iommu_intpost )
> +{
> +if ( delivery_mode == dest_LowestPrio )
> +vcpu = vector_hashing_dest(d, dest, dest_mode, 
> pirq_dpci->gmsi.gvec);
> +if ( vcpu )
> +{
> +pirq_dpci->gmsi.posted = true;
> +pirq_dpci->gmsi.dest_vcpu_id = vcpu->vcpu_id;

... which is only used here in order to get the dest_vcpu_id back. Is
this really needed? Can't you just use dest_vcpu_id?

I would rather do:

if ( iommu_intpost && delivery_mode == dest_LowestPrio )
{
const struct vcpu *vcpu = vector_hashing_dest(d, dest, dest_mode,
  pirq_dpci->gmsi.gvec);

if ( vcpu )
{

}
}

> +}
> +}
> +}
> +
>  int 

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

[Julien Grall]

On 12/02/18 15:17, Zhongze Liu wrote:

Hi Julien,


Hi,



2018-02-12 23:09 GMT+08:00 Julien Grall :

Hi,

On 12/02/18 14:52, Zhongze Liu wrote:


2018-02-08 0:54 GMT+08:00 Julien Grall :


On 07/02/18 16:27, Zhongze Liu wrote:


It seems that I mistakenly use transaction as a global lock. Now I don't
have
any reasons not putting the unmap out of the transaction, but this will
break
the original transaction into two, and I do think that we need some
explicit
locking here.



Can you explain why you need specific locking here? What are you trying to
protect? Are you trying to protect against two process doing the unmap?



Yes.


I don't think you have to worry about the locking here. With the current 
interface, the regions cannot be modified after the guest has booted. So 
the addresses will always stay valid.


This code path should never be called concurrently, as a lot of code in 
libxl, so I think someone else will take care about that for you (I will 
let Wei confirm here).


In any case, the worst that could happen is the unmap is called twice on 
the same region. So you would get spurious error message. Not that bad.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 17/49] ARM: timer: Handle level triggered IRQs correctly

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

The ARM Generic Timer uses a level-sensitive interrupt semantic. We
easily catch when the line goes high, as this triggers the hardware IRQ.
However we have to sync the state of the interrupt condition at certain
points to catch when the line goes low and we can remove the vtimer vIRQ
from the vGIC (and the LR).
The VGIC in Xen so far only implemented edge triggered vIRQs, really, so
we need to add new functionality to re-sample the interrupt state.


You might want to make a summary of the discussion we had with Marc Z. 
today here. This would help the other to understand why sample the 
interrupt state is necessary :).


Also do we need to do that for the emulated physical timer?



Signed-off-by: Andre Przywara 
---
  xen/arch/arm/time.c | 34 ++
  xen/arch/arm/traps.c|  1 +
  xen/include/xen/timer.h |  2 ++
  3 files changed, 37 insertions(+)

diff --git a/xen/arch/arm/time.c b/xen/arch/arm/time.c
index c11fcfeadd..98ebb4305d 100644
--- a/xen/arch/arm/time.c
+++ b/xen/arch/arm/time.c
@@ -263,6 +263,40 @@ static void vtimer_interrupt(int irq, void *dev_id, struct 
cpu_user_regs *regs)
  vgic_inject_irq(current->domain, current, current->arch.virt_timer.irq, 
true);
  }
  
+/**


One * is enough.


+ * vtimer_sync() - update the state of the virtual timer after a guest run
+ * @vcpu: The VCPU to sync the arch timer state
+ *
+ * After returning from a guest, update the state of the virtual interrupt
+ * line, to model the level triggered interrupt correctly.
+ * If the guest has handled a timer interrupt, the virtual interrupt line
+ * needs to be lowered explicitly. vgic_inject_irq() takes care of that.
+ */
+void vtimer_sync(struct vcpu *vcpu)
+{
+struct vtimer *vtimer = >arch.virt_timer;
+bool level;
+
+vtimer->ctl = READ_SYSREG32(CNTV_CTL_EL0);
+vtimer->cval = READ_SYSREG64(CNTV_CVAL_EL0);


Why do you need to save cval?


+
+/*
+ * Technically we should mask with 0x7 here, to catch if the timer
+ * interrupt is masked. However Xen always masks the timer upon entering
+ * the hypervisor, leaving it up to the guest to un-mask it.
+ * So we would always read a "low" level, despite the condition being
+ * actually "high". Igoring the mask bit solves this (for now).


s/Igoring/Ignoring/


+ * Another possible check would be to compare the value of CNTVCT_EL0
+ * against vtimer->cval and derive the interrupt state from that.
+ *
+ * TODO: The proper fix for this is to make vtimer vIRQ hardware mapped,
+ * but this requires reworking the arch timer to implement this.


That something we should look at it once the vGIC is done :).


+ */
+level = (vtimer->ctl & 0x5) == (CNTx_CTL_ENABLE | CNTx_CTL_PENDING);


Can you please use the proper define rather than plain value?


+
+vgic_inject_irq(vcpu->domain, vcpu, vtimer->irq, level);
+}
+
  /*
   * Arch timer interrupt really ought to be level triggered, since the
   * design of the timer/comparator mechanism is based around that
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 1cba7e584d..2d770a14a5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2024,6 +2024,7 @@ static void enter_hypervisor_head(struct cpu_user_regs 
*regs)
  if ( current->arch.hcr_el2 & HCR_VA )
  current->arch.hcr_el2 = READ_SYSREG(HCR_EL2);
  


You need to sample the virtual timer before clearing the LRs, right? If 
so, you likely want to add a comment here to avoid reshuffling the code.



+vtimer_sync(current);


I am a bit worry about re-sampling the virtual interrupt state at every 
traps. It might be worth thinking to do the re-sample when syncing the 
LRs (as you do for HW level interrupt in patch #25). Probably once we 
get the new vGIC merged.



  gic_clear_lrs(current);
  }
  }
diff --git a/xen/include/xen/timer.h b/xen/include/xen/timer.h
index 4513260b0d..eddbbf3903 100644
--- a/xen/include/xen/timer.h
+++ b/xen/include/xen/timer.h
@@ -94,6 +94,8 @@ DECLARE_PER_CPU(s_time_t, timer_deadline);
  /* Arch-defined function to reprogram timer hardware for new deadline. */
  int reprogram_timer(s_time_t timeout);
  
+void vtimer_sync(struct vcpu *vcpu);

+
  /* Calculate the aligned first tick time for a given periodic timer. */
  s_time_t align_timer(s_time_t firsttick, uint64_t period);
  



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 20/28] xen/pt: when binding guest msi, accept the whole msi message

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:27PM +0800, Chao Gao wrote:
> ... rather than a filtered one. Previously, some fields (reserved or
> unalterable) are filtered by QEMU. These fields are useless for the
> legacy interrupt format (i.e. non remappable format). However, these
> fields are meaningful to remappable format. Accepting the whole msi
> message will significantly reduce the efforts to support binding
> remappable format msi.

This should be sent as a separate patch series, together with the
required QEMU change. Batching it in this series it's going to make it
harder to commit IMO.

Also note that the QEMU side needs to be committed and backported to
the qemu-xen tree before applying the Xen side.

> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
> v4:
>  - new
> ---
>  tools/libxc/include/xenctrl.h |  7 ---
>  tools/libxc/xc_domain.c   | 14 --
>  xen/arch/x86/hvm/vmsi.c   | 12 ++--
>  xen/drivers/passthrough/io.c  | 36 +---
>  xen/include/asm-x86/hvm/irq.h |  5 +++--
>  xen/include/public/domctl.h   |  8 ++--
>  6 files changed, 40 insertions(+), 42 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 666db0b..8ade90c 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1756,16 +1756,17 @@ int xc_domain_ioport_mapping(xc_interface *xch,
>  int xc_domain_update_msi_irq(
>  xc_interface *xch,
>  uint32_t domid,
> -uint32_t gvec,
>  uint32_t pirq,
> +uint64_t addr,
> +uint32_t data,
>  uint32_t gflags,

If you pass addr and data, do you really need to also pass gflags?

> diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
> index 7126de7..5edb0e7 100644
> --- a/xen/arch/x86/hvm/vmsi.c
> +++ b/xen/arch/x86/hvm/vmsi.c
> @@ -101,12 +101,12 @@ int vmsi_deliver(
>  
>  void vmsi_deliver_pirq(struct domain *d, const struct hvm_pirq_dpci 
> *pirq_dpci)
>  {
> -uint32_t flags = pirq_dpci->gmsi.gflags;
> -int vector = pirq_dpci->gmsi.gvec;
> -uint8_t dest = (uint8_t)flags;
> -bool dest_mode = flags & XEN_DOMCTL_VMSI_X86_DM_MASK;
> -uint8_t delivery_mode = MASK_EXTR(flags, XEN_DOMCTL_VMSI_X86_DELIV_MASK);
> -bool trig_mode = flags & XEN_DOMCTL_VMSI_X86_TRIG_MASK;
> +uint8_t vector = pirq_dpci->gmsi.data & MSI_DATA_VECTOR_MASK;

MASK_EXTR please (here and elsewhere).

> +uint8_t dest = MASK_EXTR(pirq_dpci->gmsi.addr, MSI_ADDR_DEST_ID_MASK);
> +bool dest_mode = pirq_dpci->gmsi.addr & MSI_ADDR_DESTMODE_MASK;
> +uint8_t delivery_mode = MASK_EXTR(pirq_dpci->gmsi.data,
> +  MSI_DATA_DELIVERY_MODE_MASK);
> +bool trig_mode = pirq_dpci->gmsi.data & MSI_DATA_TRIGGER_MASK;
>  
>  HVM_DBG_LOG(DBG_LEVEL_IOAPIC,
>  "msi: dest=%x dest_mode=%x delivery_mode=%x "
> diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
> index 8f16e6c..d8c66bf 100644
> --- a/xen/drivers/passthrough/io.c
> +++ b/xen/drivers/passthrough/io.c
> @@ -339,19 +339,17 @@ int pt_irq_create_bind(
>  {
>  case PT_IRQ_TYPE_MSI:
>  {
> -uint8_t dest, delivery_mode;
> +uint8_t dest, delivery_mode, gvec;

I'm not sure you really need the gvec local variable, AFAICT it's used
only once.

> diff --git a/xen/include/asm-x86/hvm/irq.h b/xen/include/asm-x86/hvm/irq.h
> index 3b6b4bd..3a8832c 100644
> --- a/xen/include/asm-x86/hvm/irq.h
> +++ b/xen/include/asm-x86/hvm/irq.h
> @@ -132,9 +132,10 @@ struct dev_intx_gsi_link {
>  #define HVM_IRQ_DPCI_TRANSLATE   (1u << _HVM_IRQ_DPCI_TRANSLATE_SHIFT)
>  
>  struct hvm_gmsi_info {
> -uint32_t gvec;
> -uint32_t gflags;
> +uint32_t data;
>  int dest_vcpu_id; /* -1 :multi-dest, non-negative: dest_vcpu_id */
> +uint64_t addr;
> +uint8_t gvec;

Can't you just obtain the guest vector from addr and flags?

>  bool posted; /* directly deliver to guest via VT-d PI? */
>  };
>  
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 9f6f0aa..2717c68 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -536,15 +536,11 @@ struct xen_domctl_bind_pt_irq {
>  uint8_t intx;
>  } pci;
>  struct {
> -uint8_t gvec;
>  uint32_t gflags;
> -#define XEN_DOMCTL_VMSI_X86_DEST_ID_MASK 0xff
> -#define XEN_DOMCTL_VMSI_X86_RH_MASK  0x000100
> -#define XEN_DOMCTL_VMSI_X86_DM_MASK  0x000200
> -#define XEN_DOMCTL_VMSI_X86_DELIV_MASK   0x007000
> -#define XEN_DOMCTL_VMSI_X86_TRIG_MASK0x008000
>  #define XEN_DOMCTL_VMSI_X86_UNMASKED 0x01

Oh, I see, you need gflags for the unmask thing only.

>  
> +uint32_t data;
> +uint64_t addr;
>  uint64_aligned_t gtable;
>  } msi;
>  struct {
> -- 
> 1.8.3.1
> 

___
Xen-devel 

Re: [Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

[Andrew Cooper]

On 12/02/18 15:08, Alexandru Isaila wrote:
> No monitor features are available on AMD and all
> capabilities are passed only to the Intel processor architecture.
> This means that the arch_monitor_get_capabilities returns
> capabilities = 0.
>
> This patch is separating out features which are implemented on both
> systems from those implemented only on Intel, so that we advertize the
> working capabilities on AMD.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V2:
>   - Moved the common part of capabilities after the
> !is_hvm_domain(d) test
>   - Modified the comment in arch_monitor_get_capabilities
> ---
>  xen/include/asm-x86/monitor.h | 34 +++---
>  1 file changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
> index a0444d1..c339324 100644
> --- a/xen/include/asm-x86/monitor.h
> +++ b/xen/include/asm-x86/monitor.h
> @@ -71,24 +71,28 @@ static inline uint32_t 
> arch_monitor_get_capabilities(struct domain *d)
>  uint32_t capabilities = 0;
>  
>  /*
> - * At the moment only Intel HVM domains are supported. However, event
> - * delivery could be extended to AMD and PV domains.
> + * At the moment only Intel and AMD HVM domains are supported. However, 
> event
> + * delivery could be extended to PV domains.
>   */
> -if ( !is_hvm_domain(d) || !cpu_has_vmx )
> +if ( !is_hvm_domain(d) )
>  return capabilities;
>  
> -capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> -   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
> -
> -/* Since we know this is on VMX, we can just call the hvm func */
> -if ( hvm_is_singlestep_supported() )
> -capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
> +capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
> +
> +if( cpu_has_vmx )

Missing space.

> +{
> +capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
> +   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);

With an extra set of brackes around the entire expression, editors will
indent this properly.

I can fix these issues on commit if there are no other objections. 
Acked-by: Andrew Cooper 

> +
> +/* Since we know this is on VMX, we can just call the hvm func */
> +if ( hvm_is_singlestep_supported() )
> +capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
> +}
>  
>  if ( hvm_funcs.set_descriptor_access_exiting )
>  capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);


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

[Xen-devel] [PATCH v3 3/4] hvm/svm: Enable MSR events

[Alexandru Isaila]

At this moment there is no function to enable msr interception on svm.

This patch implements this function and moves the mov to msr monitor event
form the Intel arch side to the common capabilities.

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
Reviewed-by: Boris Ostrovsky 
---
 xen/arch/x86/hvm/svm/svm.c| 9 +
 xen/include/asm-x86/monitor.h | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 0d9baf8..5092b12 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -163,6 +163,14 @@ void svm_intercept_msr(struct vcpu *v, uint32_t msr, int 
flags)
 __clear_bit(msr * 2 + 1, msr_bit);
 }
 
+static void svm_enable_msr_interception(struct domain *d, uint32_t msr)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+svm_intercept_msr(v, msr, MSR_INTERCEPT_WRITE);
+}
+
 static void svm_save_dr(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
@@ -2460,6 +2468,7 @@ static struct hvm_function_table __initdata 
svm_function_table = {
 .fpu_dirty_intercept  = svm_fpu_dirty_intercept,
 .msr_read_intercept   = svm_msr_read_intercept,
 .msr_write_intercept  = svm_msr_write_intercept,
+.enable_msr_interception = svm_enable_msr_interception,
 .set_rdtsc_exiting= svm_set_rdtsc_exiting,
 .set_descriptor_access_exiting = svm_set_descriptor_access_exiting,
 .get_insn_bytes   = svm_get_insn_bytes,
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 11a0cae..6b886af 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -78,12 +78,12 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 return capabilities;
 
 capabilities = ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT));
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
 
 if( cpu_has_vmx )
 {
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
(1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
(1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
(1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
-- 
2.7.4


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

[Xen-devel] [PATCH v3 1/4] asm-x86/monitor: Fix monitor capability reporting on SVM systems

[Alexandru Isaila]

No monitor features are available on AMD and all
capabilities are passed only to the Intel processor architecture.
This means that the arch_monitor_get_capabilities returns
capabilities = 0.

This patch is separating out features which are implemented on both
systems from those implemented only on Intel, so that we advertize the
working capabilities on AMD.

Signed-off-by: Alexandru Isaila 

---
Changes since V2:
- Moved the common part of capabilities after the
  !is_hvm_domain(d) test
- Modified the comment in arch_monitor_get_capabilities
---
 xen/include/asm-x86/monitor.h | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index a0444d1..c339324 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -71,24 +71,28 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 uint32_t capabilities = 0;
 
 /*
- * At the moment only Intel HVM domains are supported. However, event
- * delivery could be extended to AMD and PV domains.
+ * At the moment only Intel and AMD HVM domains are supported. However, 
event
+ * delivery could be extended to PV domains.
  */
-if ( !is_hvm_domain(d) || !cpu_has_vmx )
+if ( !is_hvm_domain(d) )
 return capabilities;
 
-capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
-
-/* Since we know this is on VMX, we can just call the hvm func */
-if ( hvm_is_singlestep_supported() )
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+capabilities = (1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST);
+
+if( cpu_has_vmx )
+{
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
+
+/* Since we know this is on VMX, we can just call the hvm func */
+if ( hvm_is_singlestep_supported() )
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_SINGLESTEP);
+}
 
 if ( hvm_funcs.set_descriptor_access_exiting )
 capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DESC_ACCESS);
-- 
2.7.4


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

[Xen-devel] [PATCH v3 4/4] hvm/svm: Enable CR events

[Alexandru Isaila]

The CR_INTERCEPT_CR3_WRITE intercept is out of the vmcb->_cr_intercepts
so the AMD arch can't intercept CR events.

This patch implements the CR intercept by adding the flag on a
write_ctrlreg event. The monitor write ctrlreg event is moved from the
Intel side to the common capabilities side.

We just need to enable the SVM intercept and then hvm_mov_to_cr() will
forward the event on to the monitor when appropriate.

Signed-off-by: Alexandru Isaila 
Acked-by: Tamas K Lengyel 
---
 xen/arch/x86/hvm/svm/svm.c| 11 +++
 xen/include/asm-x86/monitor.h |  6 +++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 5092b12..89c628e 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -560,6 +561,16 @@ void svm_update_guest_cr(struct vcpu *v, unsigned int cr)
 svm_fpu_enter(v);
 }
 
+if ( paging_mode_hap(v->domain) )
+{
+uint32_t intercepts = vmcb_get_cr_intercepts(vmcb);
+
+/* Trap CR3 updates if CR3 memory events are enabled. */
+if ( v->domain->arch.monitor.write_ctrlreg_enabled &
+ monitor_ctrlreg_bitmask(VM_EVENT_X86_CR3) )
+   vmcb_set_cr_intercepts(vmcb, intercepts | 
CR_INTERCEPT_CR3_WRITE);
+}
+
 value = v->arch.hvm_vcpu.guest_cr[0] | hw_cr0_mask;
 if ( !paging_mode_hap(v->domain) )
 value |= X86_CR0_PG | X86_CR0_WP;
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index 6b886af..217f3d4 100644
--- a/xen/include/asm-x86/monitor.h
+++ b/xen/include/asm-x86/monitor.h
@@ -79,12 +79,12 @@ static inline uint32_t arch_monitor_get_capabilities(struct 
domain *d)
 
 capabilities = ((1U << XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST) |
(1U << XEN_DOMCTL_MONITOR_EVENT_SOFTWARE_BREAKPOINT) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR));
+   (1U << XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR) |
+   (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG));
 
 if( cpu_has_vmx )
 {
-capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG) |
-   (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
+capabilities |= (1U << XEN_DOMCTL_MONITOR_EVENT_DEBUG_EXCEPTION) |
(1U << XEN_DOMCTL_MONITOR_EVENT_CPUID) |
(1U << XEN_DOMCTL_MONITOR_EVENT_INTERRUPT) |
(1U << XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED);
-- 
2.7.4


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

[Xen-devel] [PATCH v3 0/4] hvm/svm: Enable vm events for SVM

[Alexandru Isaila]

Hi all,

This series provides a skeleton for enabling vm_events on SVM. For the
first step, the MSR, CR, Breakpoint and GuestRequest have been tested
and added to the capabilities list.

Cheers,

Alexandru Isaila

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

[Xen-devel] [PATCH v3 2/4] hvm/svm: Enable Breakpoint events

[Alexandru Isaila]

This commit implements the breakpoint events for svm.
At the moment, the Breakpoint vmexit is not forwarded to the monitor layer.
This patch adds the hvm_monitor_debug call to the VMEXIT_EXCEPTION_BP.
Also, the Software Breakpoint cap is moved from the Intel arch to the
common part of the code.

Signed-off-by: Alexandru Isaila 

---
Changes since V2:
- Moved the comment from vmx_vmexit_handler to
  hvm_monitor_debug
- Moved the AMD comment up.
---
 xen/arch/x86/hvm/monitor.c|  5 +
 xen/arch/x86/hvm/svm/svm.c| 48 +++
 xen/arch/x86/hvm/vmx/vmx.c|  5 -
 xen/include/asm-x86/monitor.h |  4 ++--
 4 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 131b852..60cb68d 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -133,6 +133,11 @@ static inline unsigned long gfn_of_rip(unsigned long rip)
 int hvm_monitor_debug(unsigned long rip, enum hvm_monitor_debug_type type,
   unsigned long trap_type, unsigned long insn_length)
 {
+/*
+ * rc < 0 error in monitor/vm_event, crash
+ * !rccontinue normally
+ * rc > 0 paused waiting for response, work here is done
+ */
 struct vcpu *curr = current;
 struct arch_domain *ad = >domain->arch;
 vm_event_request_t req = {};
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index dcbd550..0d9baf8 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -59,6 +59,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 void svm_asm_do_resume(void);
@@ -1079,7 +1080,8 @@ static void svm_ctxt_switch_to(struct vcpu *v)
 static void noreturn svm_do_resume(struct vcpu *v)
 {
 struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
-bool_t debug_state = v->domain->debugger_attached;
+bool debug_state = v->domain->debugger_attached
+|| v->domain->arch.monitor.software_breakpoint_enabled;
 bool_t vcpu_guestmode = 0;
 struct vlapic *vlapic = vcpu_vlapic(v);
 
@@ -2407,6 +2409,19 @@ static bool svm_get_pending_event(struct vcpu *v, struct 
x86_event *info)
 return true;
 }
 
+static void svm_propagate_intr(struct vcpu *v, unsigned long insn_len)
+{
+struct vmcb_struct *vmcb = v->arch.hvm_svm.vmcb;
+struct x86_event event = {
+.vector = vmcb->eventinj.fields.type,
+.type = vmcb->eventinj.fields.type,
+.error_code = vmcb->exitinfo1,
+};
+
+event.insn_len = insn_len;
+hvm_inject_event();
+}
+
 static struct hvm_function_table __initdata svm_function_table = {
 .name = "SVM",
 .cpu_up_prepare   = svm_cpu_up_prepare,
@@ -2619,14 +2634,31 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
 break;
 
 case VMEXIT_EXCEPTION_BP:
-if ( !v->domain->debugger_attached )
-goto unexpected_exit_type;
-/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update RIP. */
-if ( (inst_len = __get_instruction_length(v, INSTR_INT3)) == 0 )
+inst_len = __get_instruction_length(v, INSTR_INT3);
+
+if ( inst_len == 0 )
 break;
-__update_guest_eip(regs, inst_len);
-current->arch.gdbsx_vcpu_event = TRAP_int3;
-domain_pause_for_debugger();
+
+if ( v->domain->debugger_attached )
+{
+/* AMD Vol2, 15.11: INT3, INTO, BOUND intercepts do not update 
RIP. */
+__update_guest_eip(regs, inst_len);
+current->arch.gdbsx_vcpu_event = TRAP_int3;
+domain_pause_for_debugger();
+}
+else
+{
+   int rc;
+
+   rc = hvm_monitor_debug(regs->rip,
+  HVM_MONITOR_SOFTWARE_BREAKPOINT,
+  X86_EVENTTYPE_SW_EXCEPTION,
+  inst_len);
+   if ( rc < 0 )
+   goto unexpected_exit_type;
+   if ( !rc )
+   svm_propagate_intr(v, inst_len);
+}
 break;
 
 case VMEXIT_EXCEPTION_NM:
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 3dc6a6d..c89b4b6 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -3709,11 +3709,6 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
HVM_MONITOR_DEBUG_EXCEPTION,
trap_type, insn_len);
 
-/*
- * rc < 0 error in monitor/vm_event, crash
- * !rccontinue normally
- * rc > 0 paused waiting for response, work here is done
- */
 if ( rc < 0 )
 goto exit_and_crash;
 if ( !rc )
diff --git a/xen/include/asm-x86/monitor.h b/xen/include/asm-x86/monitor.h
index c339324..11a0cae 100644
--- 

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

[Zhongze Liu]

Hi Wei and Julien,

2018-02-07 1:47 GMT+08:00 Wei Liu :
> On Tue, Feb 06, 2018 at 05:30:50PM +, Julien Grall wrote:
>>
>>
>> On 02/06/2018 03:59 PM, Zhongze Liu wrote:
>> > Hi Julien,
>>
>> Hi,
>>
>>
>> > 2018-02-06 21:07 GMT+08:00 Julien Grall :
>> > > Hi,
>> > >
>> > > On 01/30/2018 05:50 PM, Zhongze Liu wrote:
>> > > >
>> > > > Add libxl__sshm_add to map shared pages from one DomU to another, The
>> > > > mapping
>> > > > process involves the follwing steps:
>> >
>> > [...]
>> >
>> > > > +
>> > > > +/* Set default values for libxl_static_shm */
>> > > > +int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
>> > > > +   libxl_static_shm *sshm)
>> > > > +{
>> > > > +int rc;
>> > > > +
>> > > > +if (sshm->role == LIBXL_SSHM_ROLE_UNKNOWN)
>> > > > +sshm->role = LIBXL_SSHM_ROLE_SLAVE;
>> > > > +if (sshm->prot == LIBXL_SSHM_PROT_UNKNOWN)
>> > > > +sshm->prot = LIBXL_SSHM_PROT_RW;
>> > >
>> > >
>> > > What is the purpose of {ROLE,PROT}_UNKNOWN if you default it resp. to
>> > > ROLE_SLAVE and PROT_RW.  Would not it be easier to just drop them?
>> >
>> > The *_UNKNOWN values are used by the libxlu code to check whether a 
>> > specific
>> > option was set more than once.
>>
>> AFAIK, a toolstack is free to not use libxlu. Someone may implement their
>> own toolstack on top of libxl and may use ROLE_UNKNOWN by mistake.
>
> Yes.
>
>>
>> > Without the default *_UNKNOWN value, I will not
>> > be able to judge if, say, role is set to 'slave' by the user or not,
>> > and therefore, if I
>> > see the user setting role to 'master', I won't be able to tell if role
>> > is specified twice
>> > or not.
>> >
>> > I think treating re-specification of options as errors will be good
>> > for the users.
>>
>> In that case, you should treat that as an error for everyone and not only
>> xl. This would avoid confusion on other toolstack.
>>
>> >
>> > [...]
>> >
>> > > > +
>> > > > +/*   libxl__sshm_do_map -- map pages into slave's physmap
>> > > > + *
>> > > > + *   This functions maps
>> > > > + * master gfn: [@msshm->begin + @sshm->offset, @msshm->end +
>> > > > @sshm->offset)
>> > > > + *   into
>> > > > + * slave gfn: [@sshm->begin, @sshm->end)
>> > > > + *
>> > > > + *   The gfns of the pages that are successfully mapped will be stored
>> > > > + *   in @mapped, and the number of the gfns will be stored in 
>> > > > @nmapped.
>> > > > + *
>> > > > + *   The caller have to guarentee that sshm->begin < sshm->end and all
>> > > > the
>> > >
>> > >
>> > > s/have to/has to/ I think.
>> > > s/guarentee/guarantee/
>> > >
>> > > > + *   values are page-aligned.
>> > >
>> > >
>> > > Hmmm, I don't see the alignement check in libxl. So do you rely on the
>> > > toolstack to do it?
>> >
>> > Yes, This was done in libxlu_sshm.c.
>>
>> Same remark as above regarding libxlu. Note that I am maintaining the tools.
>> Ian and Wei may have a different opinion here.
>>
>
> Please move the check to libxl.

I agree that we should move the alignment check to libxl.

But I still think that re-specification checks could only be done in
libxlu, because
this could only be spotted in the parsing phase -- it shouldn't be
libxl's job. For
libxl, an *_UNKNOWN values just indicates that the user of libxl
didn't explicitly
assign a value to the option upon calling the constructor of the sshm struct,
and the code in libxl will set the option to its default value.
However, I do think
I failed to  handle the possibilities where an option value is not
not *_UNKNOWN and
not any valid values, which might occur if the user of libxl didn't
use the constructor
to initialize the sshm struct.

Cheers,

Zhongze Liu.

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

Re: [Xen-devel] [PATCH v2 09/15] xen/arm: psci: Detect SMCCC version

[Julien Grall]

On 12/02/18 14:43, Volodymyr Babchuk wrote:

Hi Julien,

On 09.02.18 19:09, Julien Grall wrote:



On 02/09/2018 05:04 PM, Volodymyr Babchuk wrote:

Julien,


On 08.02.18 21:21, Julien Grall wrote:

PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
earlier) and the function return an error, then we considered SMCCC 1.0
is implemented.

Signed-off-by: Julien Grall 
---
 Changes in v2:
 - Patch added
---
  xen/arch/arm/psci.c | 34 +-
  xen/include/asm-arm/smccc.h |  5 -
  2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c


I find it strange to determine SMCCC version in PSCI code. psci.c is 
not the first place, where I will look for SMCCC version discovery.

I think it is better to add smccc.c, where such functions can reside.


SMCCC version discovery is based on PSCI, hence it is in the PSCI 
code. I can't see a good reason to create a file with 3 lines at the 
moment.


SMCCC version discovery is a Arm Architecture Service function. PSCI 
used to discover if this function is supported at all. Dubious 
architectural solution from my point of view. But it is already done...


We had similar discussions about introducing new files earlier, so you 
know  my point. I would like to see clean codebase where one can 
navigate without grep/cscope. I see no point, why function that calls 
Arm architecture service to identify SMCCC version should reside in PSCI 
code.


Good luck for navigating without grep/cscope in a such a big code base.



Besides, that file will have more than 3 lines at the moment. Your 
current psci_init_smccc is longer right now :)


You got my point with "3 lines"... It is one function in one file. There 
limited reason to create a file for that, more that I clearly don't want 
to expose psci_features() outside of psci.c for now.


We can revisit this in the future if we need to discover SMCCC in a 
different way.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

[Andrew Cooper]

On 12/02/18 14:39, Wei Liu wrote:
> On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote:
>> The correct amount of padding in an origin patch site can be calculated
>> automatically, based on the relative lengths of the replacements.
>>
>> This requires a bit of trickery to calculate correctly, especially in the
>> ALTENRATIVE_2 case where a branchless max() calculation in needed.  The
>> calculation is further complicated because GAS's idea of true is -1 rather
>> than 1, which is why the extra negations are required.
>>
>> Additionally, have apply_alternatives() attempt to optimise the padding nops.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Roger Pau Monné 
>> CC: Wei Liu 
>> ---
>>  xen/arch/x86/alternative.c| 32 
>>  xen/include/asm-x86/alternative-asm.h | 40 
>> +++
>>  xen/include/asm-x86/alternative.h | 39 
>> ++
>>  3 files changed, 89 insertions(+), 22 deletions(-)
>>
>> diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
>> index f8ddab5..ec87ff4 100644
>> --- a/xen/arch/x86/alternative.c
>> +++ b/xen/arch/x86/alternative.c
>> @@ -180,13 +180,37 @@ void init_or_livepatch apply_alternatives(const struct 
>> alt_instr *start,
>>  uint8_t *orig = ALT_ORIG_PTR(a);
>>  uint8_t *repl = ALT_REPL_PTR(a);
>>  uint8_t buf[MAX_PATCH_LEN];
>> +unsigned int total_len = a->orig_len + a->pad_len;
>>  
>> -BUG_ON(a->repl_len > a->orig_len);
>> -BUG_ON(a->orig_len > sizeof(buf));
>> +BUG_ON(a->repl_len > total_len);
>> +BUG_ON(total_len > sizeof(buf));
>>  BUG_ON(a->cpuid >= NCAPINTS * 32);
>>  
>>  if ( !boot_cpu_has(a->cpuid) )
>> +{
>> +unsigned int i;
>> +
>> +/* No replacement to make, but try to optimise any padding. */
>> +if ( a->pad_len <= 1 )
>> +continue;
>> +
>> +/* Search the padding area for any byte which isn't a nop. */
>> +for ( i = a->orig_len; i < total_len; ++i )
>> +if ( orig[i] != 0x90 )
>> +break;
>> +
>> +/*
>> + * Only make any changes if all padding bytes are unoptimised
>> + * nops.  With multiple alternatives over the same origin site, 
>> we
>> + * may have already made a replacement, or optimised the nops.
>> + */
>> +if ( i != total_len )
>> +continue;
>> +
>> +add_nops(buf, a->pad_len);
>> +text_poke(orig + a->orig_len, buf, a->pad_len);
>>  continue;
>> +}
> Is the expectation here the alternative instructions already contain
> optimised paddings (including live patches)? Otherwise why is the same
> optimisation no needed when later?

The problem is that we don't store the actual original bytes, so can't
trivially detect whether we've already patched this site before.  We've
a number of cases which are an ALTERNATIVE_2 based on SMEP and SMAP, so
on a fair chunk of hardware, we first make a replacement because of
SMEP, then fail the SMAP check and don't make the second replacement.

Later, we are discarding everything in orig+pad, and replacing it with
repl+any necessary padding, which is made of optimised nops.

>
>>  
>>  memcpy(buf, repl, a->repl_len);
>>  
>> @@ -194,8 +218,8 @@ void init_or_livepatch apply_alternatives(const struct 
>> alt_instr *start,
>>  if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
>>  *(s32 *)(buf + 1) += repl - orig;
>>  
>> -add_nops(buf + a->repl_len, a->orig_len - a->repl_len);
>> -text_poke(orig, buf, a->orig_len);
>> +add_nops(buf + a->repl_len, total_len - a->repl_len);
>> +text_poke(orig, buf, total_len);
>>  }
>>  }
>>  
>> diff --git a/xen/include/asm-x86/alternative-asm.h 
>> b/xen/include/asm-x86/alternative-asm.h
>> index 150bd1a..f7e37cb 100644
>> --- a/xen/include/asm-x86/alternative-asm.h
>> +++ b/xen/include/asm-x86/alternative-asm.h
>> @@ -9,30 +9,41 @@
>>   * enough information for the alternatives patching code to patch an
>>   * instruction. See apply_alternatives().
>>   */
>> -.macro altinstruction_entry orig repl feature orig_len repl_len
>> +.macro altinstruction_entry orig repl feature orig_len repl_len pad_len
>>  .long \orig - .
>>  .long \repl - .
>>  .word \feature
>>  .byte \orig_len
>>  .byte \repl_len
>> +.byte \pad_len
>>  .endm
>>  
>>  #define orig_len   (.L\@_orig_e   - .L\@_orig_s)
>> +#define pad_len(.L\@_orig_p   - .L\@_orig_e)
>> +#define total_len  (.L\@_orig_p   - .L\@_orig_s)
>>  #define repl_len(nr)   (.L\@_repl_e\()nr  - 

Re: [Xen-devel] [PATCH v4 19/28] x86/vioapic: extend vioapic_get_vector() to support remapping format RTE

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:26PM +0800, Chao Gao wrote:
> When IOAPIC RTE is in remapping format, it doesn't contain the vector of
> interrupt. For this case, the RTE contains an index of interrupt remapping
> table where the vector of interrupt is stored. This patchs gets the vector
> through a vIOMMU interface.

I think this should be merged with the previous patch.

> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/arch/x86/hvm/vioapic.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
> index 0f20e3f..8b34b21 100644
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -560,11 +560,23 @@ int vioapic_get_vector(const struct domain *d, unsigned 
> int gsi)
>  {
>  unsigned int pin;
>  const struct hvm_vioapic *vioapic = gsi_vioapic(d, gsi, );
> +struct arch_irq_remapping_request request;
>  
>  if ( !vioapic )
>  return -EINVAL;
>  
> -return vioapic->redirtbl[pin].fields.vector;
> +irq_request_ioapic_fill(, vioapic->id, 
> vioapic->redirtbl[pin].bits);
> +if ( viommu_check_irq_remapping(vioapic->domain, ) )
> +{
> +struct arch_irq_remapping_info info;
> +
> +return unlikely(viommu_get_irq_info(vioapic->domain, , 
> ))
> +   ? : info.vector;
> +}
> +else
> +{
> +return vioapic->redirtbl[pin].fields.vector;
> +}

Unneeded braces.

Thanks, Roger.

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

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

[Wei Liu]

On Fri, Feb 09, 2018 at 09:20:33AM +, Christian Lindig wrote:
> 
> 
> > On 8. Feb 2018, at 18:24, Wei Liu  wrote:
> > 
> > Christian, do you have any idea when you can look into fixing the
> > safe-string patch?
> 
> Sorry, I can’t make a promise because of my other obligations. I do wonder, 
> though: this patch did not come out of nowhere but supposedly was working - 
> what is different here?
> 

No worries. I have reverted some patches in xen.git to get things going
again.

Wei.

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

Re: [Xen-devel] [PATCH v4 18/28] x86/vioapic: Hook interrupt delivery of vIOAPIC

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:25PM +0800, Chao Gao wrote:
> When irq remapping is enabled, IOAPIC Redirection Entry may be in remapping
> format. If that, generate an irq_remapping_request and call the common

"If that's the case, ..."

> VIOMMU abstraction's callback to handle this interrupt request. Device
> model is responsible for checking the request's validity.

What does this exactly mean? Device model is not involved in what the
guest writes to the vIOAPIC RTE, so it's impossible for the device
model to validate this in any way.

> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> 
> ---
> v3:
>  - use the new interface to check remapping format.
> ---
>  xen/arch/x86/hvm/vioapic.c   | 9 +
>  xen/include/asm-x86/viommu.h | 9 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vioapic.c b/xen/arch/x86/hvm/vioapic.c
> index 97b419f..0f20e3f 100644
> --- a/xen/arch/x86/hvm/vioapic.c
> +++ b/xen/arch/x86/hvm/vioapic.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -387,9 +388,17 @@ static void vioapic_deliver(struct hvm_vioapic *vioapic, 
> unsigned int pin)
>  struct vlapic *target;
>  struct vcpu *v;
>  unsigned int irq = vioapic->base_gsi + pin;
> +struct arch_irq_remapping_request request;
>  
>  ASSERT(spin_is_locked(>arch.hvm_domain.irq_lock));
>  
> +irq_request_ioapic_fill(, vioapic->id, 
> vioapic->redirtbl[pin].bits);
> +if ( viommu_check_irq_remapping(d, ) )
> +{
> +viommu_handle_irq_request(d, );
> +return;
> +}

Will this compile if you disable vIOMMU in Kconfig?

Roger.

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

Re: [Xen-devel] RTDS with extra time issue

[Meng Xu]

On Mon, Feb 12, 2018 at 6:08 AM, Andrii Anisov  wrote:
>
> Dario, Meng,
>
>
> On 12.02.18 12:17, Dario Faggioli wrote:
>>
>> Well, I'll let Andrii reply, but honestly, I don't think it is.
>>
>> See, for instance, the fact that DomR has only 1 vCPU, so I find it
>> unlikely that the only thing that run there is *just* *one* real-time
>> task. :-/
>
> While I'm focused mainly on the topic discussed here [1], a RT domain will 
> have some RTOS with its set tasks (RT as well as non-RT), also it would 
> communicate with other domains. Likely it would be one RT domain per system.
> So I'm trying to estimate somehow if RTDS has its practical usage or 
> dedicated cpupool with null scheduler will do the job.
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/automotive-discussions/2018-January/005590.html

I see. This is interesting. I'm also interested in the practical use
case of both RTDS and null scheduler.

Best,

Meng

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

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

[Zhongze Liu]

Hi Julien an Wei,

2018-02-08 0:54 GMT+08:00 Julien Grall :
> On 07/02/18 16:27, Zhongze Liu wrote:
>>
>> Hi Wei and Julien,
>
>
> Hi,
>
>
>> 2018-02-07 2:06 GMT+08:00 Wei Liu :
>>>
>>> On Tue, Feb 06, 2018 at 01:24:30PM +, Julien Grall wrote:
>
>if (libxl__device_pci_destroy_all(gc, domid) < 0)
>LOGD(ERROR, domid, "Pci shutdown failed");
>rc = xc_domain_pause(ctx->xch, domid);
> diff --git a/tools/libxl/libxl_internal.h
> b/tools/libxl/libxl_internal.h
> index 2cfe4c08a7..c398b6a6b8 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -4424,6 +4424,8 @@ static inline bool libxl__string_is_default(char
> **s)
>_hidden int libxl__sshm_add(libxl__gc *gc, uint32_t domid,
>libxl_static_shm *sshm, int len);
> +_hidden int libxl__sshm_del(libxl__gc *gc, uint32_t domid);
> +
>_hidden int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
>  libxl_static_shm *sshms, int
> len);
>_hidden int libxl__sshm_setdefault(libxl__gc *gc, uint32_t domid,
> diff --git a/tools/libxl/libxl_sshm.c b/tools/libxl/libxl_sshm.c
> index 562f46f299..1bf4d4c2dc 100644
> --- a/tools/libxl/libxl_sshm.c
> +++ b/tools/libxl/libxl_sshm.c
> @@ -86,6 +86,112 @@ int libxl__sshm_check_overlap(libxl__gc *gc,
> uint32_t domid,
>return 0;
>}
> +/* Decrease the refcount of an sshm. When refcount reaches 0,


 NIT: Libxl coding style regarding the comment seems to be uncleared
 (Ian,
 Wei?). But I feel keep /* and */ in separate line is nicer.
>>>
>>>
>>> I don't have an opinion here.
>>>

> + * clean up the whole sshm path.
> + */
> +static void libxl__sshm_decref(libxl__gc *gc, xs_transaction_t xt,
> +   const char *sshm_path)
> +static void libxl__sshm_del_slave(libxl__gc *gc, xs_transaction_t xt,
> +  uint32_t domid, const char *id, bool
> isretry)
> +{
> +const char *slave_path, *begin_str, *end_str;
> +uint64_t begin, end;
> +
> +slave_path = GCSPRINTF("%s/slaves/%"PRIu32, SSHM_PATH(id), domid);
> +
> +begin_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/begin",
> slave_path));
> +end_str = libxl__xs_read(gc, xt, GCSPRINTF("%s/end", slave_path));
> +begin = strtoull(begin_str, NULL, 16);
> +end = strtoull(end_str, NULL, 16);
> +
> +/* Avoid calling do_unmap many times in case of xs transaction
> retry */
> +if (!isretry)
> +libxl__sshm_do_unmap(gc, domid, id, begin, end);


 IHMO, by unmapping the regions in middle of the transaction, you
 increase
 the potential failure of it. I would move that out of the transaction
 path.

 I would be interested to hear the opinion of the tools maintainers here.

>>>
>>> If you move the unmap after the loop you create a window in which
>>> the pages are still mapped but the toolstack thinks they are unmapped.
>>>
>>> While the code as-is now makes sure (assuming no error in unmap) the
>>> pages are unmapped no later than the transaction is committed. I think
>>> this can be done by moving unmap before the transaction.
>>>
>>> Zhongze, do you think the unmap must be done inside the loop? What kind
>>> of invariants do you have in mind?
>>>
>>> Then there is the question of "what do we do if unmap fails". Honestly I
>>> don't have an answer. It seems rather screwed up in that case and I
>>> doubt there is much libxl can do to rectify things.
>>>
>>
>> I put the unmap inside the transaction because I want to make the whole
>> read_mapping_info->unmap->update_mapping_info process atomic. If
>> I put unmap outside the transaction:  after I read out the information
>> that I need to do the unmap, and before I do the unmap and decrease the
>> refcnt, there could be another instance of this code trying to do the same
>> thing, which might lead to race condition.
>
>
> AFAIU, the transaction is not a "global" lock. You will just not see the the
> change from the others during the transactions. Your changes will be only be
> visible at the end. So two transaction can be happily started concurrently,
> and try to do the unmap together. Not even your code will protect against
> that.
>
> So can you give a bit more details here?
>

It seems that I mistakenly use transaction as a global lock. Now I don't have
any reasons not putting the unmap out of the transaction, but this will break
the original transaction into two, and I do think that we need some explicit
locking here.

@Wei. Do you have any suggestions here?

Cheers,

Zhongze Liu

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

Re: [Xen-devel] libx[lc]: Improve error reporting for invalid kernel images

[Wei Liu]

On Thu, Feb 08, 2018 at 10:49:07PM +0100, Simon Gaiser wrote:
> Simon Gaiser (3):
>   libxc: Cleanup xc_dom_parse_elf_kernel()'s return value
>   libxl: Improve logging in libxl__build_dom()
>   libxc: xc_dom_parse_elf_kernel: Return error for invalid kernel images

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/7] Port WARN_ON_ONCE() from Linux

[Wei Liu]

On Thu, Feb 08, 2018 at 08:10:49PM -0700, Sameer Goel wrote:
>  
> +#define WARN_ON_ONCE(p) \
> +({  \
> +static bool __section(".data.unlikely") __warned; \
> +int __ret_warn_once = !!(p);\
> +\
> +if ( unlikely(__ret_warn_once && !__warned) ) \
> +{   \
> +__warned = true;\

Please don't mix bool and int type.

Wei.

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

Re: [Xen-devel] [PATCH v4 17/28] x86/vvtd: save and restore emulated VT-d

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:24PM +0800, Chao Gao wrote:
> Provide a save-restore pair to save/restore registers and non-register
> status.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
> v3:
>  - use one entry to save both vvtd registers and other intermediate
>  state
> ---
>  xen/drivers/passthrough/vtd/vvtd.c | 57 
> +++---
>  xen/include/public/arch-x86/hvm/save.h | 18 ++-
>  2 files changed, 56 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index 81170ec..f6bde69 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -27,8 +27,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  
>  #include "iommu.h"
>  #include "vtd.h"
> @@ -38,20 +40,6 @@
>  
>  #define VVTD_FRCD_NUM   1ULL
>  #define VVTD_FRCD_START (DMAR_IRTA_REG + 8)
> -#define VVTD_FRCD_END   (VVTD_FRCD_START + VVTD_FRCD_NUM * 16)
> -#define VVTD_MAX_OFFSET VVTD_FRCD_END
> -
> -struct hvm_hw_vvtd {
> -bool eim_enabled;
> -bool intremap_enabled;
> -uint32_t fault_index;
> -
> -/* Interrupt remapping table base gfn and the max of entries */
> -uint16_t irt_max_entry;
> -gfn_t irt;

You are changing gfn_t to uint64_t, is gfn_t not working with the
migration stream?

Also I think this duplication of fields (having all registers in
'regs' and some cached in miscellaneous top level fields is not a good
approach.

> -
> -uint32_t regs[VVTD_MAX_OFFSET/sizeof(uint32_t)];
> -};
>  
>  struct vvtd {
>  /* Base address of remapping hardware register-set */
> @@ -776,7 +764,7 @@ static void write_gcmd_sirtp(struct vvtd *vvtd, uint32_t 
> val)
>  if ( vvtd->hw.intremap_enabled )
>  vvtd_info("Update Interrupt Remapping Table when active\n");
>  
> -if ( gfn_x(vvtd->hw.irt) != PFN_DOWN(DMA_IRTA_ADDR(irta)) ||
> +if ( vvtd->hw.irt != PFN_DOWN(DMA_IRTA_ADDR(irta)) ||
>   vvtd->hw.irt_max_entry != DMA_IRTA_SIZE(irta) )
>  {
>  if ( vvtd->irt_base )
> @@ -786,14 +774,14 @@ static void write_gcmd_sirtp(struct vvtd *vvtd, 
> uint32_t val)
>   sizeof(struct iremap_entry)));
>  vvtd->irt_base = NULL;
>  }
> -vvtd->hw.irt = _gfn(PFN_DOWN(DMA_IRTA_ADDR(irta)));
> +vvtd->hw.irt = PFN_DOWN(DMA_IRTA_ADDR(irta));
>  vvtd->hw.irt_max_entry = DMA_IRTA_SIZE(irta);
>  vvtd->hw.eim_enabled = !!(irta & IRTA_EIME);
>  vvtd_info("Update IR info (addr=%lx eim=%d size=%d)\n",
> -  gfn_x(vvtd->hw.irt), vvtd->hw.eim_enabled,
> +  vvtd->hw.irt, vvtd->hw.eim_enabled,
>vvtd->hw.irt_max_entry);
>  
> -vvtd->irt_base = map_guest_pages(vvtd->domain, gfn_x(vvtd->hw.irt),
> +vvtd->irt_base = map_guest_pages(vvtd->domain, vvtd->hw.irt,
>   PFN_UP(vvtd->hw.irt_max_entry *
>  sizeof(struct 
> iremap_entry)));
>  }
> @@ -1138,6 +1126,39 @@ static bool vvtd_is_remapping(const struct domain *d,
>  return !irq_remapping_request_index(irq, );
>  }
>  
> +static int vvtd_load(struct domain *d, hvm_domain_context_t *h)
> +{
> +struct vvtd *vvtd = domain_vvtd(d);
> +uint64_t iqa;
> +
> +if ( !vvtd )
> +return -ENODEV;
> +
> +if ( hvm_load_entry(VVTD, h, >hw) )
> +return -EINVAL;
> +
> +iqa = vvtd_get_reg_quad(vvtd, DMAR_IQA_REG);
> +vvtd->irt_base = map_guest_pages(vvtd->domain, vvtd->hw.irt,
> + PFN_UP(vvtd->hw.irt_max_entry *
> +sizeof(struct iremap_entry)));
> +vvtd->inv_queue_base = map_guest_pages(vvtd->domain,
> +   PFN_DOWN(DMA_IQA_ADDR(iqa)),
> +   1 << DMA_IQA_QS(iqa));

Why are you unconditionally mapping those pages? Shouldn't you check
that the relevant features are enabled?

Both could be 0 or simply point to garbage.

> +return 0;
> +}
> +
> +static int vvtd_save(struct domain *d, hvm_domain_context_t *h)
> +{
> +struct vvtd *vvtd = domain_vvtd(d);
> +
> +if ( !vvtd )
> +return 0;
> +
> +return hvm_save_entry(VVTD, 0, h, >hw);
> +}
> +
> +HVM_REGISTER_SAVE_RESTORE(VVTD, vvtd_save, vvtd_load, 1, HVMSR_PER_DOM);
> +
>  static void vvtd_reset(struct vvtd *vvtd)
>  {
>  uint64_t cap = cap_set_num_fault_regs(VVTD_FRCD_NUM)
> diff --git a/xen/include/public/arch-x86/hvm/save.h 
> b/xen/include/public/arch-x86/hvm/save.h
> index fd7bf3f..24a513b 100644
> --- a/xen/include/public/arch-x86/hvm/save.h
> +++ b/xen/include/public/arch-x86/hvm/save.h
> @@ -639,10 +639,26 @@ struct hvm_msr {
>  
>  #define CPU_MSR_CODE  20
>  
> +#define VVTD_MAX_OFFSET 0xd0

You used to have some 

Re: [Xen-devel] [PATCH 2/7] xen/bitops: Rename LOG_2 to ilog2

[Wei Liu]

On Thu, Feb 08, 2018 at 08:10:50PM -0700, Sameer Goel wrote:
> Changing the name of the macro from LOG_2 to ilog2.This makes the function 
> name
> similar to its Linux counterpart. Since, this is not used in multiple places,
> the code churn is minimal.
> 
> This change helps in porting unchanged code from Linux.
> 
> Signed-off-by: Sameer Goel 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 09/15] xen/arm: psci: Detect SMCCC version

[Volodymyr Babchuk]

Hi Julien,

On 09.02.18 19:09, Julien Grall wrote:



On 02/09/2018 05:04 PM, Volodymyr Babchuk wrote:

Julien,


On 08.02.18 21:21, Julien Grall wrote:

PSCI 1.0 and later allows the SMCCC version to be (indirectly) probed
via PSCI_FEATURES. If the PSCI_FEATURES does not exist (PSCI 0.2 or
earlier) and the function return an error, then we considered SMCCC 1.0
is implemented.

Signed-off-by: Julien Grall 
---
 Changes in v2:
 - Patch added
---
  xen/arch/arm/psci.c | 34 +-
  xen/include/asm-arm/smccc.h |  5 -
  2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c


I find it strange to determine SMCCC version in PSCI code. psci.c is 
not the first place, where I will look for SMCCC version discovery.

I think it is better to add smccc.c, where such functions can reside.


SMCCC version discovery is based on PSCI, hence it is in the PSCI code. 
I can't see a good reason to create a file with 3 lines at the moment.


SMCCC version discovery is a Arm Architecture Service function. PSCI 
used to discover if this function is supported at all. Dubious 
architectural solution from my point of view. But it is already done...


We had similar discussions about introducing new files earlier, so you 
know  my point. I would like to see clean codebase where one can 
navigate without grep/cscope. I see no point, why function that calls 
Arm architecture service to identify SMCCC version should reside in PSCI 
code.


Besides, that file will have more than 3 lines at the moment. Your 
current psci_init_smccc is longer right now :)





index 5dda35cd7c..bc7b2260e8 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -37,6 +37,7 @@
  #endif
  uint32_t psci_ver;
+uint32_t smccc_ver;


And this variable actually is not related to PSCI.


See my comment above. I am not going to create a file just for 3 lines.



See my comments above :)

--
Volodymyr Babchuk

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

Re: [Xen-devel] [PATCH v2 02/15] xen/arm: vpsci: Add support for PSCI 1.1

[Wei Liu]

On Thu, Feb 08, 2018 at 07:21:50PM +, Julien Grall wrote:
> At the moment, Xen provides virtual PSCI interface compliant with 0.1
> and 0.2. Since them, the specification has been updated and the latest
> version is 1.1 (see ARM DEN 0022D).
> 
> From an implementation point of view, only PSCI_FEATURES is mandatory.
> The rest is optional and can be left unimplemented for now.
> 
> At the same time, the compatible for PSCI node have been updated to
> expose "arm,psci-1.0".
> 
> Signed-off-by: Julien Grall 


Acked-by: Wei Liu 

I will leave this patch to ARM committers.

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

Re: [Xen-devel] Slow HVM boot time, was "HVM boot time optimization"

[Wei Liu]

On Mon, Feb 12, 2018 at 09:27:25AM +0100, Yessine Daoud wrote:
>  Hello,
> 
> Thank you for your quick response.
> Any hints how can I "fix" this "issue"? *Any workaround?
> 

Honestly I have no idea why it is slow unless there is more logging
available.

Wei.

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

Re: [Xen-devel] [PATCH 7/7] x86/build: Use new .nop directive when available

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:07AM +, Andrew Cooper wrote:
> Newer versions of binutils are capable of emitting an exact number bytes worth
> of optimised nops.  Use this in preference to .skip when available.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 6/7] x86/alt: Drop explicit padding of origin sites

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:06AM +, Andrew Cooper wrote:
> Now that the alternatives infrastructure can calculate the required padding
> automatically, there is no need to hard code it.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 5/7] x86/alt: Support for automatic padding calculations

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:05AM +, Andrew Cooper wrote:
> The correct amount of padding in an origin patch site can be calculated
> automatically, based on the relative lengths of the replacements.
> 
> This requires a bit of trickery to calculate correctly, especially in the
> ALTENRATIVE_2 case where a branchless max() calculation in needed.  The
> calculation is further complicated because GAS's idea of true is -1 rather
> than 1, which is why the extra negations are required.
> 
> Additionally, have apply_alternatives() attempt to optimise the padding nops.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> ---
>  xen/arch/x86/alternative.c| 32 
>  xen/include/asm-x86/alternative-asm.h | 40 
> +++
>  xen/include/asm-x86/alternative.h | 39 ++
>  3 files changed, 89 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
> index f8ddab5..ec87ff4 100644
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -180,13 +180,37 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>  uint8_t *orig = ALT_ORIG_PTR(a);
>  uint8_t *repl = ALT_REPL_PTR(a);
>  uint8_t buf[MAX_PATCH_LEN];
> +unsigned int total_len = a->orig_len + a->pad_len;
>  
> -BUG_ON(a->repl_len > a->orig_len);
> -BUG_ON(a->orig_len > sizeof(buf));
> +BUG_ON(a->repl_len > total_len);
> +BUG_ON(total_len > sizeof(buf));
>  BUG_ON(a->cpuid >= NCAPINTS * 32);
>  
>  if ( !boot_cpu_has(a->cpuid) )
> +{
> +unsigned int i;
> +
> +/* No replacement to make, but try to optimise any padding. */
> +if ( a->pad_len <= 1 )
> +continue;
> +
> +/* Search the padding area for any byte which isn't a nop. */
> +for ( i = a->orig_len; i < total_len; ++i )
> +if ( orig[i] != 0x90 )
> +break;
> +
> +/*
> + * Only make any changes if all padding bytes are unoptimised
> + * nops.  With multiple alternatives over the same origin site, 
> we
> + * may have already made a replacement, or optimised the nops.
> + */
> +if ( i != total_len )
> +continue;
> +
> +add_nops(buf, a->pad_len);
> +text_poke(orig + a->orig_len, buf, a->pad_len);
>  continue;
> +}

Is the expectation here the alternative instructions already contain
optimised paddings (including live patches)? Otherwise why is the same
optimisation no needed when later?

>  
>  memcpy(buf, repl, a->repl_len);
>  
> @@ -194,8 +218,8 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>  if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
>  *(s32 *)(buf + 1) += repl - orig;
>  
> -add_nops(buf + a->repl_len, a->orig_len - a->repl_len);
> -text_poke(orig, buf, a->orig_len);
> +add_nops(buf + a->repl_len, total_len - a->repl_len);
> +text_poke(orig, buf, total_len);
>  }
>  }
>  
> diff --git a/xen/include/asm-x86/alternative-asm.h 
> b/xen/include/asm-x86/alternative-asm.h
> index 150bd1a..f7e37cb 100644
> --- a/xen/include/asm-x86/alternative-asm.h
> +++ b/xen/include/asm-x86/alternative-asm.h
> @@ -9,30 +9,41 @@
>   * enough information for the alternatives patching code to patch an
>   * instruction. See apply_alternatives().
>   */
> -.macro altinstruction_entry orig repl feature orig_len repl_len
> +.macro altinstruction_entry orig repl feature orig_len repl_len pad_len
>  .long \orig - .
>  .long \repl - .
>  .word \feature
>  .byte \orig_len
>  .byte \repl_len
> +.byte \pad_len
>  .endm
>  
>  #define orig_len   (.L\@_orig_e   - .L\@_orig_s)
> +#define pad_len(.L\@_orig_p   - .L\@_orig_e)
> +#define total_len  (.L\@_orig_p   - .L\@_orig_s)
>  #define repl_len(nr)   (.L\@_repl_e\()nr  - .L\@_repl_s\()nr)
>  #define decl_repl(insn, nr) .L\@_repl_s\()nr: insn; .L\@_repl_e\()nr:
> +#define gas_max(a, b)  ((a) ^ (((a) ^ (b)) & -(-((a) < (b)

What about clang's assembler? At least give it a stub to cause
compilation error?

>  
>  .macro ALTERNATIVE oldinstr, newinstr, feature
>  .L\@_orig_s:
>  \oldinstr
>  .L\@_orig_e:
> + .skip (-((repl_len(1) - orig_len) > 0) * (repl_len(1) - orig_len)), 0x90

Seeing the negation at the beginning, I suppose this should also be a
gas specific macro?

The rest looks good.

Wei.

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v4 16/28] x86/vvtd: Add queued invalidation (QI) support

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:23PM +0800, Chao Gao wrote:
> Queued Invalidation Interface is an expanded invalidation interface with
> extended capabilities. Hardware implementations report support for queued
> invalidation interface through the Extended Capability Register. The queued
> invalidation interface uses an Invalidation Queue (IQ), which is a circular
> buffer in system memory. Software submits commands by writing Invalidation
> Descriptors to the IQ.
> 
> In this patch, a new function viommu_process_iq() is used for emulating how
> hardware handles invalidation requests through QI.

You should mention that QI is mandatory in order to support interrupt
remapping.

I was about to ask whether QI could be deferred to a later stage, but
AFAICT this is not an option.

> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> 
> ---
> v4:
>  - Introduce a lock to protect invalidation related registers.
> ---
>  xen/drivers/passthrough/vtd/iommu.h |  24 +++-
>  xen/drivers/passthrough/vtd/vvtd.c  | 271 
> +++-
>  2 files changed, 293 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.h 
> b/xen/drivers/passthrough/vtd/iommu.h
> index b71dab8..de9188b 100644
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -47,7 +47,12 @@
>  #define DMAR_IQH_REG0x80 /* invalidation queue head */
>  #define DMAR_IQT_REG0x88 /* invalidation queue tail */
>  #define DMAR_IQA_REG0x90 /* invalidation queue addr */
> +#define DMAR_IQUA_REG   0x94 /* invalidation queue upper addr */
> +#define DMAR_ICS_REG0x9c /* invalidation completion status */
>  #define DMAR_IECTL_REG  0xa0 /* invalidation event control register 
> */
> +#define DMAR_IEDATA_REG 0xa4 /* invalidation event data register */
> +#define DMAR_IEADDR_REG 0xa8 /* invalidation event address register 
> */
> +#define DMAR_IEUADDR_REG0xac /* upper address register */
>  #define DMAR_IRTA_REG   0xb8 /* base address of intr remap table */
>  #define DMAR_IRTUA_REG  0xbc /* upper address of intr remap table */
>  
> @@ -175,6 +180,21 @@
>  #define DMA_IRTA_S(val) (val & 0xf)
>  #define DMA_IRTA_SIZE(val)  (1UL << (DMA_IRTA_S(val) + 1))
>  
> +/* IQA_REG */
> +#define DMA_IQA_ADDR(val)   (val & ~0xfffULL)
> +#define DMA_IQA_QS(val) (val & 0x7)
> +#define DMA_IQA_RSVD0xff8ULL
> +
> +/* IECTL_REG */
> +#define DMA_IECTL_IM_SHIFT 31
> +#define DMA_IECTL_IM(1U << DMA_IECTL_IM_SHIFT)
> +#define DMA_IECTL_IP_SHIFT 30
> +#define DMA_IECTL_IP(1U << DMA_IECTL_IP_SHIFT)
> +
> +/* ICS_REG */
> +#define DMA_ICS_IWC_SHIFT   0
> +#define DMA_ICS_IWC (1U << DMA_ICS_IWC_SHIFT)
> +
>  /* PMEN_REG */
>  #define DMA_PMEN_EPM(((u32)1) << 31)
>  #define DMA_PMEN_PRS(((u32)1) << 0)
> @@ -205,13 +225,14 @@
>  /* FSTS_REG */
>  #define DMA_FSTS_PFO_SHIFT  0
>  #define DMA_FSTS_PPF_SHIFT  1
> +#define DMA_FSTS_IQE_SHIFT  4
>  #define DMA_FSTS_PRO_SHIFT  7
>  
>  #define DMA_FSTS_PFO((uint32_t)1 << DMA_FSTS_PFO_SHIFT)
>  #define DMA_FSTS_PPF((uint32_t)1 << DMA_FSTS_PPF_SHIFT)
>  #define DMA_FSTS_AFO((uint32_t)1 << 2)
>  #define DMA_FSTS_APF((uint32_t)1 << 3)
> -#define DMA_FSTS_IQE((uint32_t)1 << 4)
> +#define DMA_FSTS_IQE((uint32_t)1 << DMA_FSTS_IQE_SHIFT)
>  #define DMA_FSTS_ICE((uint32_t)1 << 5)
>  #define DMA_FSTS_ITE((uint32_t)1 << 6)
>  #define DMA_FSTS_PRO((uint32_t)1 << DMA_FSTS_PRO_SHIFT)
> @@ -555,6 +576,7 @@ struct qinval_entry {
>  
>  /* Queue invalidation head/tail shift */
>  #define QINVAL_INDEX_SHIFT 4
> +#define QINVAL_INDEX_MASK  0x7fff0ULL
>  
>  #define qinval_present(v) ((v).lo & 1)
>  #define qinval_fault_disable(v) (((v).lo >> 1) & 1)
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index a2fa64a..81170ec 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "iommu.h"
> @@ -68,6 +69,9 @@ struct vvtd {
>  
>  struct hvm_hw_vvtd hw;
>  void *irt_base;
> +void *inv_queue_base;

Why not declare this as:

struct qinval_entry *

> +/* This lock protects invalidation related registers */
> +spinlock_t ie_lock;

As noted in another patch, I think the first approach should be to use
a single lock that serializes access to the whole vIOMMU register
space. Later we can see about more fine grained locking.

>  };
>  
>  /* Setting viommu_verbose enables debugging messages of vIOMMU */
> @@ -284,6 +288,12 @@ static void vvtd_notify_fault(const struct vvtd *vvtd)
>  vvtd_get_reg(vvtd, DMAR_FEDATA_REG));
>  }
>  
> +static void 

Re: [Xen-devel] [PATCH v4 15/28] x86/vvtd: Enable Queued Invalidation through GCMD

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:22PM +0800, Chao Gao wrote:
> Software writes to QIE field of GCMD to enable or disable queued
> invalidations. This patch emulates QIE field of GCMD.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
>  xen/drivers/passthrough/vtd/iommu.h |  3 ++-
>  xen/drivers/passthrough/vtd/vvtd.c  | 18 ++
>  2 files changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.h 
> b/xen/drivers/passthrough/vtd/iommu.h
> index dc2df75..b71dab8 100644
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -160,7 +160,8 @@
>  #define DMA_GSTS_FLS(((u64)1) << 29)
>  #define DMA_GSTS_AFLS   (((u64)1) << 28)
>  #define DMA_GSTS_WBFS   (((u64)1) << 27)
> -#define DMA_GSTS_QIES   (((u64)1) <<26)
> +#define DMA_GSTS_QIES_SHIFT 26
> +#define DMA_GSTS_QIES   (((u64)1) << DMA_GSTS_QIES_SHIFT)
>  #define DMA_GSTS_IRES_SHIFT 25
>  #define DMA_GSTS_IRES   (((u64)1) << DMA_GSTS_IRES_SHIFT)
>  #define DMA_GSTS_SIRTPS_SHIFT   24
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index 83805d1..a2fa64a 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -539,6 +539,20 @@ static void write_gcmd_ire(struct vvtd *vvtd, uint32_t 
> val)
>  (vvtd, DMAR_GSTS_REG, DMA_GSTS_IRES_SHIFT);
>  }
>  
> +static void write_gcmd_qie(struct vvtd *vvtd, uint32_t val)
> +{
> +bool set = val & DMA_GCMD_QIE;
> +
> +vvtd_info("%sable Queue Invalidation\n", set ? "En" : "Dis");
> +
> +if ( set )
> +vvtd_set_reg_quad(vvtd, DMAR_IQH_REG, 0);

If QIE is already enabled and the user writes to GCMD with the QIE bit
set won't this wrongly clear the invalidation queue?

> +
> +(set ? vvtd_set_bit : vvtd_clear_bit)
> +(vvtd, DMAR_GSTS_REG, DMA_GSTS_QIES_SHIFT);
> +
> +}
> +
>  static void write_gcmd_sirtp(struct vvtd *vvtd, uint32_t val)
>  {
>  uint64_t irta = vvtd_get_reg_quad(vvtd, DMAR_IRTA_REG);
> @@ -598,6 +612,10 @@ static void vvtd_write_gcmd(struct vvtd *vvtd, uint32_t 
> val)
>  write_gcmd_sirtp(vvtd, val);
>  if ( changed & DMA_GCMD_IRE )
>  write_gcmd_ire(vvtd, val);
> +if ( changed & DMA_GCMD_QIE )
> +write_gcmd_qie(vvtd, val);
> +if ( changed & ~(DMA_GCMD_SIRTP | DMA_GCMD_IRE | DMA_GCMD_QIE) )
> +vvtd_info("Only SIRTP, IRE, QIE in GCMD are handled");

This seems quite likely to go out of sync. I would rather do:

if ( changed & DMA_GCMD_QIE )
{
write_gcmd_qie(vvtd, val);
changed &= ~DMA_GCMD_QIE;
}
...
if ( changed )
vvtd_info("Unhandled bit detected: %...");

It seems also quite likely this can be simplified with a macro:

#define HANDLE_GCMD_BIT(bit)\
if ( changed & DMA_GCMD_ ## bit )   \
{   \
write_gcmd_ ## bit (vvtd, val); \
changed &= ~DMA_GCMD_ ## bit;   \
}

So that you can write:

HANDLE_GCMD_BIT(IRE);
HANDLE_GCMD_BIT(QIE);
...

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8b1a5268daf0ff1ddca49d2e683e5bfabf6b9988
baseline version:
 xen  c9d46c6fba9496478fa9f42c4bbebce8a191527d

Last test of basis   118713  2018-02-09 01:02:02 Z3 days
Testing same since   118995  2018-02-12 12:02:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 
  Kevin Tian 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   c9d46c6fba..8b1a5268da  8b1a5268daf0ff1ddca49d2e683e5bfabf6b9988 -> smoke

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

Re: [Xen-devel] [RFC PATCH 16/49] ARM: GIC: allow reading pending state of a hardware IRQ

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

To synchronize level triggered interrupts which are mapped into a guest,
we need to update the virtual line level at certain points in time.
For a hardware mapped interrupt the GIC is the only place where we can
easily access this information.
Implement a gic_hw_operations member to return the pending state of a
particular interrupt. Due to hardware limitations this only works for
private interrupts of the current CPU, so there is not CPU field in the
prototype.

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/gic-v2.c |  6 ++
  xen/arch/arm/gic-v3.c | 13 +
  xen/arch/arm/gic.c|  5 +
  xen/include/asm-arm/gic.h |  5 +
  4 files changed, 29 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 5339f69fbc..30081640ac 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -514,6 +514,11 @@ static unsigned int gicv2_read_apr(int apr_reg)
 return readl_gich(GICH_APR);
  }
  
+bool gicv2_read_pending_state(int irq)


static

Also, I would like to see the irq turned into irq_desc to match the 
other interface.



+{
+return readl_gicd(GICD_ISPENDR + (irq / 32) * 4) & (1U << (irq % 32));


See my remark in the previous patch. You might want to introduce an 
helper peek.



+}
+
  static void gicv2_irq_enable(struct irq_desc *desc)
  {
  unsigned long flags;
@@ -1261,6 +1266,7 @@ const static struct gic_hw_operations gicv2_ops = {
  .write_lr= gicv2_write_lr,
  .read_vmcr_priority  = gicv2_read_vmcr_priority,
  .read_apr= gicv2_read_apr,
+.read_pending_state  = gicv2_read_pending_state,
  .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
  .make_hwdom_madt = gicv2_make_hwdom_madt,
  .get_hwdom_extra_madt_size = gicv2_get_hwdom_extra_madt_size,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 595eaef43a..2cbfeb8e03 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1081,6 +1081,18 @@ static unsigned int gicv3_read_apr(int apr_reg)
  }
  }
  
+static bool gicv3_read_pending_state(int irq)

+{
+void __iomem *base;
+
+if ( irq >= NR_GIC_LOCAL_IRQS)
+base = GICD + (irq / 32) * 4;
+else
+base = GICD_RDIST_SGI_BASE;
+
+return readl(base + GICD_ISPENDR) & (1U << (irq % 32));


Looking at the GICv3 code we don't have a peek helper. It is probably 
worth to add one.



+}
+
  static void gicv3_irq_enable(struct irq_desc *desc)
  {
  unsigned long flags;
@@ -1749,6 +1761,7 @@ static const struct gic_hw_operations gicv3_ops = {
  .write_lr= gicv3_write_lr,
  .read_vmcr_priority  = gicv3_read_vmcr_priority,
  .read_apr= gicv3_read_apr,
+.read_pending_state  = gicv3_read_pending_state,
  .secondary_init  = gicv3_secondary_cpu_init,
  .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
  .make_hwdom_madt = gicv3_make_hwdom_madt,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index dfc2108c4d..ce9ab2367e 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -116,6 +116,11 @@ static void gic_set_irq_priority(struct irq_desc *desc, 
unsigned int priority)
  gic_hw_ops->set_irq_priority(desc, priority);
  }
  
+bool gic_read_pending_state(int irq)

+{
+return gic_hw_ops->read_pending_state(irq);
+}
+
  /* Program the GIC to route an interrupt to the host (i.e. Xen)
   * - needs to be called with desc.lock held
   */
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index d330860580..d7fd18fd47 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -244,6 +244,9 @@ void gic_set_active_state(int irq, bool state);
  /* Program the IRQ type into the GIC */
  void gic_set_irq_type(struct irq_desc *desc, unsigned int type);
  
+/* Read the pending state of an interrupt from the distributor. */

+bool gic_read_pending_state(int irq);
+
  /* Program the GIC to route an interrupt */
  extern void gic_route_irq_to_xen(struct irq_desc *desc, unsigned int 
priority);
  extern int gic_route_irq_to_guest(struct domain *, unsigned int virq,
@@ -376,6 +379,8 @@ struct gic_hw_operations {
  unsigned int (*read_vmcr_priority)(void);
  /* Read APRn register */
  unsigned int (*read_apr)(int apr_reg);
+/* Query the pending state of an interrupt at the distributor level. */
+bool (*read_pending_state)(int irq);
  /* Secondary CPU init */
  int (*secondary_init)(void);
  /* Create GIC node for the hardware domain */



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 15/49] ARM: GIC: Allow tweaking the active state of an IRQ

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active state of an interrupt at
some point in time.
To prepare the GIC for that, we introduce a set_active_state() function
to let the VGIC manipulate the state of an associated hardware IRQ.

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/gic-v2.c |  9 +
  xen/arch/arm/gic-v3.c | 16 
  xen/arch/arm/gic.c|  5 +
  xen/include/asm-arm/gic.h |  5 +
  4 files changed, 35 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2e35892881..5339f69fbc 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -235,6 +235,14 @@ static unsigned int gicv2_read_irq(void)
  return (readl_gicc(GICC_IAR) & GICC_IA_IRQ);
  }
  
+static void gicv2_set_active_state(int irq, bool active)


I would much prefer to have an irq_desc in parameter. This is matching 
the other interface and you could update the flags such as 
_IRQ_INPROGRESS which you don't do at the moment.


Also, who is preventing two CPUs to clear the active bit at the same time?


+{
+if (active)
+writel_gicd(1U << (irq % 32), GICD_ISACTIVER + (irq / 32) * 4);
+else
+writel_gicd(1U << (irq % 32), GICD_ICACTIVER + (irq / 32) * 4);


You will have a few places in the code usually similar construct. It 
would make sense to introduce a helper poke as we have in the GICv3 code.



+}
+
  static void gicv2_set_irq_type(struct irq_desc *desc, unsigned int type)
  {
  uint32_t cfg, actual, edgebit;
@@ -1241,6 +1249,7 @@ const static struct gic_hw_operations gicv2_ops = {
  .eoi_irq = gicv2_eoi_irq,
  .deactivate_irq  = gicv2_dir_irq,
  .read_irq= gicv2_read_irq,
+.set_active_state= gicv2_set_active_state,
  .set_irq_type= gicv2_set_irq_type,
  .set_irq_priority= gicv2_set_irq_priority,
  .send_SGI= gicv2_send_SGI,
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index 08d4703687..595eaef43a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -475,6 +475,21 @@ static unsigned int gicv3_read_irq(void)
  return irq;
  }
  
+static void gicv3_set_active_state(int irq, bool active)

+{
+void __iomem *base;
+
+if ( irq >= NR_GIC_LOCAL_IRQS)
+base = GICD + (irq / 32) * 4;
+else
+base = GICD_RDIST_SGI_BASE;
+
+if ( active )
+writel(1U << (irq % 32), base + GICD_ISACTIVER);
+else
+writel(1U << (irq % 32), base + GICD_ICACTIVER);


Shouldn't you wait until RWP bits is cleared here?


+}


Why don't you use the function poke?


+
  static inline uint64_t gicv3_mpidr_to_affinity(int cpu)
  {
   uint64_t mpidr = cpu_logical_map(cpu);
@@ -1722,6 +1737,7 @@ static const struct gic_hw_operations gicv3_ops = {
  .eoi_irq = gicv3_eoi_irq,
  .deactivate_irq  = gicv3_dir_irq,
  .read_irq= gicv3_read_irq,
+.set_active_state= gicv3_set_active_state,
  .set_irq_type= gicv3_set_irq_type,
  .set_irq_priority= gicv3_set_irq_priority,
  .send_SGI= gicv3_send_sgi,
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 89873c1df4..dfc2108c4d 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -92,6 +92,11 @@ void gic_restore_state(struct vcpu *v)
  isb();
  }
  
+void gic_set_active_state(int irq, bool state)

+{
+gic_hw_ops->set_active_state(irq, state);
+}
+
  /* desc->irq needs to be disabled before calling this function */
  void gic_set_irq_type(struct irq_desc *desc, unsigned int type)
  {
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index c4c68c7770..d330860580 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -238,6 +238,9 @@ DECLARE_PER_CPU(uint64_t, lr_mask);
  extern enum gic_version gic_hw_version(void);
  extern int gic_get_nr_lrs(void);
  
+/* Force the state of an IRQ to active. */

+void gic_set_active_state(int irq, bool state);
+
  /* Program the IRQ type into the GIC */
  void gic_set_irq_type(struct irq_desc *desc, unsigned int type);
  
@@ -347,6 +350,8 @@ struct gic_hw_operations {

  void (*deactivate_irq)(struct irq_desc *irqd);
  /* Read IRQ id and Ack */
  unsigned int (*read_irq)(void);
+/* Force the state of an IRQ to active */
+void (*set_active_state)(int irq, bool state);
  /* Set IRQ type */
  void (*set_irq_type)(struct irq_desc *desc, unsigned int type);
  /* Set IRQ priority */



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

[Juergen Gross]

On 08/02/18 00:49, Prarit Bhargava wrote:
> The kernel panics on PV domains because native_smp_cpus_done() is
> only called for HVM domains.
> 
> Calculate __max_logical_packages for PV domains.
> 
> Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
> Signed-off-by: Prarit Bhargava 
> Tested-and-reported-by: Simon Gaiser 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Cc: Dou Liyang 
> Cc: Prarit Bhargava 
> Cc: Kate Stewart 
> Cc: Greg Kroah-Hartman 
> Cc: Andy Lutomirski 
> Cc: Andi Kleen 
> Cc: Vitaly Kuznetsov 
> Cc: xen-devel@lists.xenproject.org

Committed to xen.tip for-linus-4.16


Juergen

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

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

[Juergen Gross]

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

Committed to xen.tip for-linus-4.16


Juergen

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

Re: [Xen-devel] [PATCH 2/2] pvcalls-front: wait for other operations to return when release passive sockets

[Juergen Gross]

On 05/02/18 23:51, Stefano Stabellini wrote:
> Passive sockets can have ongoing operations on them, specifically, we
> have two wait_event_interruptable calls in pvcalls_front_accept.
> 
> Add two wake_up calls in pvcalls_front_release, then wait for the
> potential waiters to return and release the sock_mapping refcount.
> 
> Signed-off-by: Stefano Stabellini 

Acked-by: Juergen Gross 


Juergen

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

Re: [Xen-devel] [PATCH 1/2] pvcalls-front: introduce a per sock_mapping refcount

[Juergen Gross]

On 05/02/18 23:51, Stefano Stabellini wrote:
> Introduce a per sock_mapping refcount, in addition to the existing
> global refcount. Thanks to the sock_mapping refcount, we can safely wait
> for it to be 1 in pvcalls_front_release before freeing an active socket,
> instead of waiting for the global refcount to be 1.
> 
> Signed-off-by: Stefano Stabellini 
> ---
>  drivers/xen/pvcalls-front.c | 190 
> ++--
>  1 file changed, 78 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/xen/pvcalls-front.c b/drivers/xen/pvcalls-front.c
> index 4c789e6..164d3ad 100644
> --- a/drivers/xen/pvcalls-front.c
> +++ b/drivers/xen/pvcalls-front.c
> @@ -60,6 +60,7 @@ struct sock_mapping {
>   bool active_socket;
>   struct list_head list;
>   struct socket *sock;
> + atomic_t refcount;
>   union {
>   struct {
>   int irq;
> @@ -93,6 +94,33 @@ struct sock_mapping {
>   };
>  };
>  
> +static inline struct sock_mapping *pvcalls_enter_sock(struct socket *sock)
> +{
> + struct sock_mapping *map = NULL;
> +
> + if (!pvcalls_front_dev || _front_dev->dev == NULL)

Did you mean:
if (!pvcalls_front_dev || !pvcalls_front_dev->dev)

> + return ERR_PTR(-ENOTCONN);
> +
> + pvcalls_enter();
> + map = (struct sock_mapping *) sock->sk->sk_send_head;

Style: no blank after the cast, please (multiple times).

> + if (map == NULL) {
> + pvcalls_exit()
> + return ERR_PTR(-ENOTSOCK);
> + }
> +
> + atomic_inc(>refcount);
> + return map;
> +}
> +
> +static inline void pvcalls_exit_sock(struct socket *sock)
> +{
> + struct sock_mapping *map = NULL;
> +
> + map = (struct sock_mapping *) sock->sk->sk_send_head;
> + atomic_dec(>refcount);
> + pvcalls_exit();
> +}
> +
>  static inline int get_request(struct pvcalls_bedata *bedata, int *req_id)
>  {
>   *req_id = bedata->ring.req_prod_pvt & (RING_SIZE(>ring) - 1);
> @@ -369,31 +397,23 @@ int pvcalls_front_connect(struct socket *sock, struct 
> sockaddr *addr,
>   if (addr->sa_family != AF_INET || sock->type != SOCK_STREAM)
>   return -EOPNOTSUPP;
>  
> - pvcalls_enter();
> - if (!pvcalls_front_dev) {
> - pvcalls_exit();
> - return -ENOTCONN;
> - }
> + map = pvcalls_enter_sock(sock);
> + if (IS_ERR(map))
> + return PTR_ERR(map);
>  
>   bedata = dev_get_drvdata(_front_dev->dev);
>  
> - map = (struct sock_mapping *)sock->sk->sk_send_head;
> - if (!map) {
> - pvcalls_exit();
> - return -ENOTSOCK;
> - }
> -
>   spin_lock(>socket_lock);
>   ret = get_request(bedata, _id);
>   if (ret < 0) {
>   spin_unlock(>socket_lock);
> - pvcalls_exit();
> + pvcalls_exit_sock(sock);
>   return ret;
>   }
>   ret = create_active(map, );
>   if (ret < 0) {
>   spin_unlock(>socket_lock);
> - pvcalls_exit();
> + pvcalls_exit_sock(sock);
>   return ret;
>   }
>  
> @@ -423,7 +443,7 @@ int pvcalls_front_connect(struct socket *sock, struct 
> sockaddr *addr,
>   smp_rmb();
>   ret = bedata->rsp[req_id].ret;
>   bedata->rsp[req_id].req_id = PVCALLS_INVALID_ID;
> - pvcalls_exit();
> + pvcalls_exit_sock(sock);
>   return ret;
>  }
>  
> @@ -488,23 +508,15 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
> msghdr *msg,
>   if (flags & (MSG_CONFIRM|MSG_DONTROUTE|MSG_EOR|MSG_OOB))
>   return -EOPNOTSUPP;
>  
> - pvcalls_enter();
> - if (!pvcalls_front_dev) {
> - pvcalls_exit();
> - return -ENOTCONN;
> - }
> + map = pvcalls_enter_sock(sock);
> + if (IS_ERR(map))
> + return PTR_ERR(map);
>   bedata = dev_get_drvdata(_front_dev->dev);
>  
> - map = (struct sock_mapping *) sock->sk->sk_send_head;
> - if (!map) {
> - pvcalls_exit();
> - return -ENOTSOCK;
> - }
> -
>   mutex_lock(>active.out_mutex);
>   if ((flags & MSG_DONTWAIT) && !pvcalls_front_write_todo(map)) {
>   mutex_unlock(>active.out_mutex);
> - pvcalls_exit();
> + pvcalls_exit_sock(sock);
>   return -EAGAIN;
>   }
>   if (len > INT_MAX)
> @@ -526,7 +538,7 @@ int pvcalls_front_sendmsg(struct socket *sock, struct 
> msghdr *msg,
>   tot_sent = sent;
>  
>   mutex_unlock(>active.out_mutex);
> - pvcalls_exit();
> + pvcalls_exit_sock(sock);
>   return tot_sent;
>  }
>  
> @@ -591,19 +603,11 @@ int pvcalls_front_recvmsg(struct socket *sock, struct 
> msghdr *msg, size_t len,
>   if (flags & (MSG_CMSG_CLOEXEC|MSG_ERRQUEUE|MSG_OOB|MSG_TRUNC))
>   return -EOPNOTSUPP;
>  
> - pvcalls_enter();
> - if (!pvcalls_front_dev) {
> - pvcalls_exit();
> - return 

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-xl-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-xsm
testid xen-boot

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  d48fcbd864a008802a90c58a9ceddd9436d11a49
  Bug not present: 993ca2068b043dc3c933a8a4fe1052b77fe63f10
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/118996/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-xsm.xen-boot
 --summary-out=tmp/118996.bisection-summary --basis-template=118324 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-xsm xen-boot
Searching for failure / basis pass:
 118893 fail [host=huxelrebe1] / 118629 [host=baroque0] 118598 [host=italia0] 
118586 [host=elbling0] 118576 [host=pinot0] 118566 [host=fiano0] 118556 
[host=chardonnay1] 118538 [host=chardonnay0] 118501 [host=elbling1] 118464 
[host=rimava0] 118445 [host=huxelrebe0] 118428 [host=italia1] 118401 
[host=fiano0] 118362 ok.
Failure / basis pass flights: 118893 / 118362
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest d48fcbd864a008802a90c58a9ceddd9436d11a49 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
Basis pass 993ca2068b043dc3c933a8a4fe1052b77fe63f10 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#993ca2068b043dc3c933a8a4fe1052b77fe63f10-d48fcbd864a008802a90c58a9ceddd9436d11a49
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#2b033e396f4fa0981bae1213cdacd15775655a97-2b033e396f4fa0981bae1213cdacd15775655a97
 
git://xenbits.xen.org/xen.git#e871e80c38547d9faefc6604532ba3e985e65873-c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
adhoc-revtuple-generator: tree discontiguous: linux-2.6
Loaded 1002 nodes in revision graph
Searching for test results:
 118112 [host=rimava0]
 118215 [host=huxelrebe0]
 118250 [host=rimava1]
 118276 [host=baroque0]
 118283 [host=baroque1]
 118324 [host=pinot1]
 118445 [host=huxelrebe0]
 118362 pass 993ca2068b043dc3c933a8a4fe1052b77fe63f10 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118401 [host=fiano0]
 118428 [host=italia1]
 118464 [host=rimava0]
 118538 [host=chardonnay0]
 118501 [host=elbling1]
 118556 [host=chardonnay1]
 118566 [host=fiano0]
 118576 [host=pinot0]
 118586 [host=elbling0]
 118629 [host=baroque0]
 118598 [host=italia0]
 118638 fail irrelevant
 118672 fail irrelevant
 118775 fail irrelevant
 118927 pass 993ca2068b043dc3c933a8a4fe1052b77fe63f10 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
e871e80c38547d9faefc6604532ba3e985e65873
 118939 fail irrelevant
 118945 pass 993ca2068b043dc3c933a8a4fe1052b77fe63f10 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
78aca253029b4e51e49f4ed5d802c4a16bf6e89b
 118893 fail d48fcbd864a008802a90c58a9ceddd9436d11a49 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
c93014ad3aa6aa88dfa5e96f66e8adb561483b8d
 118947 pass 993ca2068b043dc3c933a8a4fe1052b77fe63f10 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
2b033e396f4fa0981bae1213cdacd15775655a97 
2713715305ca516f698d58cec5e0b322c3b2c4eb
 118953 pass 

Re: [Xen-devel] [PATCH v4 14/28] x86/vvtd: Handle interrupt translation faults

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:21PM +0800, Chao Gao wrote:
> Interrupt translation faults are non-recoverable fault. When faults
> are triggered, it needs to populate fault info to Fault Recording
> Registers and inject msi interrupt to notify guest IOMMU driver
> to deal with faults.
> 
> This patch emulates hardware's handling interrupt translation
> faults (more information about the process can be found in VT-d spec,
> chipter "Translation Faults", section "Non-Recoverable Fault
> Reporting" and section "Non-Recoverable Logging").
> Specifically, viommu_record_fault() records the fault information and
> viommu_report_non_recoverable_fault() reports faults to software.
> Currently, only Primary Fault Logging is supported and the Number of
> Fault-recording Registers is 1.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> 
> ---
> v4:
>  - introduce a lock to protect fault-event related regs
> ---
>  xen/drivers/passthrough/vtd/iommu.h |  51 ++-
>  xen/drivers/passthrough/vtd/vvtd.c  | 288 
> +++-
>  2 files changed, 333 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.h 
> b/xen/drivers/passthrough/vtd/iommu.h
> index 82edd2a..dc2df75 100644
> --- a/xen/drivers/passthrough/vtd/iommu.h
> +++ b/xen/drivers/passthrough/vtd/iommu.h
> @@ -196,26 +196,67 @@
>  #define DMA_CCMD_CAIG_MASK(x) (((u64)x) & ((u64) 0x3 << 59))
>  
>  /* FECTL_REG */
> -#define DMA_FECTL_IM((uint32_t)1 << 31)
> +#define DMA_FECTL_IM_SHIFT  31
> +#define DMA_FECTL_IP_SHIFT  30
> +#define DMA_FECTL_IM((uint32_t)1 << DMA_FECTL_IM_SHIFT)
> +#define DMA_FECTL_IP((uint32_t)1 << DMA_FECTL_IP_SHIFT)
>  
>  /* FSTS_REG */
> -#define DMA_FSTS_PFO((uint32_t)1 << 0)
> -#define DMA_FSTS_PPF((uint32_t)1 << 1)
> +#define DMA_FSTS_PFO_SHIFT  0
> +#define DMA_FSTS_PPF_SHIFT  1
> +#define DMA_FSTS_PRO_SHIFT  7
> +
> +#define DMA_FSTS_PFO((uint32_t)1 << DMA_FSTS_PFO_SHIFT)
> +#define DMA_FSTS_PPF((uint32_t)1 << DMA_FSTS_PPF_SHIFT)
>  #define DMA_FSTS_AFO((uint32_t)1 << 2)
>  #define DMA_FSTS_APF((uint32_t)1 << 3)
>  #define DMA_FSTS_IQE((uint32_t)1 << 4)
>  #define DMA_FSTS_ICE((uint32_t)1 << 5)
>  #define DMA_FSTS_ITE((uint32_t)1 << 6)
> -#define DMA_FSTS_FAULTSDMA_FSTS_PFO | DMA_FSTS_PPF | DMA_FSTS_AFO | 
> DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE
> +#define DMA_FSTS_PRO((uint32_t)1 << DMA_FSTS_PRO_SHIFT)
> +#define DMA_FSTS_FAULTS (DMA_FSTS_PFO | DMA_FSTS_PPF | DMA_FSTS_AFO | \
> + DMA_FSTS_APF | DMA_FSTS_IQE | DMA_FSTS_ICE | \
> + DMA_FSTS_ITE | DMA_FSTS_PRO)
> +#define DMA_FSTS_RW1CS  (DMA_FSTS_PFO | DMA_FSTS_AFO | DMA_FSTS_APF | \
> + DMA_FSTS_IQE | DMA_FSTS_ICE | DMA_FSTS_ITE | \
> + DMA_FSTS_PRO)
>  #define dma_fsts_fault_record_index(s) (((s) >> 8) & 0xff)
>  
>  /* FRCD_REG, 32 bits access */
> -#define DMA_FRCD_F (((u64)1) << 31)
> +#define DMA_FRCD_LEN0x10
> +#define DMA_FRCD2_OFFSET0x8
> +#define DMA_FRCD3_OFFSET0xc
> +#define DMA_FRCD_F_SHIFT31
> +#define DMA_FRCD_F ((u64)1 << DMA_FRCD_F_SHIFT)
>  #define dma_frcd_type(d) ((d >> 30) & 1)
>  #define dma_frcd_fault_reason(c) (c & 0xff)
>  #define dma_frcd_source_id(c) (c & 0x)
>  #define dma_frcd_page_addr(d) (d & (((u64)-1) << 12)) /* low 64 bit */
>  
> +struct vtd_fault_record_register
> +{
> +union {
> +struct {
> +uint64_t lo;
> +uint64_t hi;
> +} bits;
> +struct {
> +uint64_t rsvd0  :12,
> + fault_info :52;
> +uint64_t source_id  :16,
> + rsvd1  :9,
> + pmr:1,  /* Privilege Mode Requested */
> + exe:1,  /* Execute Permission Requested */
> + pasid_p:1,  /* PASID Present */
> + fault_reason   :8,  /* Fault Reason */
> + pasid_val  :20, /* PASID Value */
> + addr_type  :2,  /* Address Type */
> + type   :1,  /* Type. (0) Write (1) 
> Read/AtomicOp */
> + fault  :1;  /* Fault */
> +} fields;
> +};
> +};
> +
>  /* Interrupt remapping transition faults */
>  #define VTD_FR_IR_REQ_RSVD  0x20
>  #define VTD_FR_IR_INDEX_OVER0x21
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index d3dec01..83805d1 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -43,6 +43,7 @@
>  struct hvm_hw_vvtd {
>  bool eim_enabled;
>  bool intremap_enabled;
> +uint32_t fault_index;
>  
>  /* Interrupt remapping table base gfn and the max of 

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
> With future changes, altinstruction_entry is going to become more complicated
> to use.  Furthermore, there are already ALTERNATIVE* macros which can be used
> to avoid opencoding the creation of replacement information.
> 
> For ASM_STAC, ASM_CLAC and CR4_PV32_RESTORE, this means the removal of all
> hardocded label numbers.  For the cr4_pv32 alternatives, this means hardcoding
> the extra space required in the original patch site, but the hardcoding will
> be removed by a later patch.
> 
> No change to any functionality, but the handling of nops inside the original
> patch sites are a bit different.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

[Xen-devel] Realloc VM's memory while running

[cosmin]

Hi all,

I am working in a project in which we try to switch domain's underlying
machine memory(MFNs) for another "chunk" of the same size while the VM is
running. This can be useful for example when a domain running a memory
intensive load experiences performance penalties(e.g: lot of cache misses);
by switching domain's memory for a "chunk" of memory that is
allocated(assuming the allocator is able to take into account the relation
between memory address and the cache lines) such that the number of misses
decreases.

The implementation is mostly done, however we have some issues that we're
stuck on, so I'm asking for some help.

So, the implementation works in the following way:
S1. Pause domain

S2. Allocate new memory for domain

S3. Setup the 'new P2M' table for the newly allocated memory using 'old
P2M' table (based on a 1-to-1 mapping of oldP2M[i] and newP2M[i]).

For this purpose the pages a domain owns are split into 3 types: PT, WR and
P2M - which in fact ar also WR pages but they store the P2M(using the
pfn_to_mfn_frame_list_list field of the shared data between Xen and
domains). Accordingly, WR pages need only to be copied to the corresponding
new page while PT and P2M pages require for each entry/element in the page
to find their mapping in the new P2M and write it down at the same entry
location on the PT or P2M page in the "new" memory.

S4. For each page copy old page's metadata information(like count and type
info) to the matching new page.

S5. Update the fields of domain's data structures pointing to MFNs (i.e.:
domain.arch.pirq_eoi_map_mfn,
domain.shared.arch.pfn_to_mfn_frame_list_list, vcpu.arch.[guest_table,
guest_table_user], vcpu.vcpu_info_mfn)

S6.  Release domain's old memory by using relinquish_memory() in a loop, in
a similar manner like in relinquish_resources() but for memory(L4, L3, L2)
only.

S7. Update M2P table to reflect the changes

S8. Assign the new memory pages to domain.

S9. Unpause the domain.

The problems we face:

P1. It seems that translation of PTs and P2Ms works well - we wrote some
test scripts dumping and comparing domain's memory before and after the
memory switch(in order for this test to work we pause domain from console
at the beginning of the test - the unpause_doimain function called in
implementation should have no effect). However, for some RAW pages, ~ 1% of
the total number of pages of a 64MB domain, we can see some differences in
their content.

The question is, does somebody else touch a domain's memory once it is
paused ?
It is a 1VCPU domain.

P2. Some of the old pages(~ 2-3%) doesn't seem to be released. It looks
that this happens due to count/type info constraints, with the following
error:

d0v1 Error pfn 42b625: rd = 1, od = 32756 caf = 1c00
taf=7401

I guess it is in response to a page_get on a page that does not belong to a
domain anymore, but that shouldn't normally happen ... or am I wrong ?

P3. Trying to connect to a domain's console after it has been unpaused
doesn't work. We also run ping, but machine is not reachable. How can we
debug this issue ? Are there any changes to be done in the PV OS(Linux)
running on the domain ? Our assumptions were that as long as the domain has
direct memory access and uses  P2M and M2P tables, the changes will be
visible to the OS.

Thank you in advance.

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

Re: [Xen-devel] [PATCH] libxc: check for null size file mapping

[Wei Liu]

On Mon, Feb 12, 2018 at 01:09:15PM +0100, Paul Semel wrote:
> Changed the error message when trying to map a null size file.
> When doing `xl create` command, we get an Invalid Kernel error
> when the file size is greater than zero. For zero length files, we are
> falling in the mmap error, and we get an `Invalid parameter` error,
> which is not explicit. With this change, we get a `zero length file`
> error.
> 
> Signed-off-by: Paul Semel 

Acked-by: Wei Liu 

This can in fact be done right after lseek, but I don't think it is
important enough to ask you to rewrite your patch. :-)

> ---
>  tools/libxc/xc_dom_core.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 96e71dd2d9..9bd04cb2d5 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -225,6 +225,12 @@ void *xc_dom_malloc_filemap(struct xc_dom_image *dom,
>   "tried to map file which is too large");
>  goto err;
>  }
> +else if ( !*size )
> +{
> +xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
> + "'%s': zero length file", filename);
> +goto err;
> +}
>  
>  block = malloc(sizeof(*block));
>  if ( block == NULL ) {
> -- 
> 2.16.1
> 

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

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

[Andrew Cooper]

On 12/02/18 12:30, Wei Liu wrote:
> On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
>> index 58f652d..bd3819a 100644
>> --- a/xen/arch/x86/x86_64/entry.S
>> +++ b/xen/arch/x86/x86_64/entry.S
>> @@ -557,23 +557,9 @@ handle_exception_saved:
>>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>>  jzexception_with_ints_disabled
>>  
>> -.Lcr4_pv32_orig:
>> -jmp   .Lcr4_pv32_done
>> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - 
>> .Lcr4_pv32_orig), 0xcc
>> -.pushsection .altinstr_replacement, "ax"
>> -.Lcr4_pv32_alt:
>> -mov   VCPU_domain(%rbx),%rax
>> -.Lcr4_pv32_alt_end:
>> -.section .altinstructions, "a"
>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>> - X86_FEATURE_XEN_SMEP, \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
>> - X86_FEATURE_XEN_SMAP, \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
>> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
>> -.popsection
>> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \
> This changed 0xcc to 0x90 but since it is just padding following an
> unconditional jmp so it shouldn't matter.
>
> Mostly looks fine. I'm a bit hesitant to give my Rb because reviewing
> the diff to assembly is a bit more difficult to than diff to C source.
>
> Do you have a branch somewhere?

http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/alternatives-v1

~Andrew

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

Re: [Xen-devel] [RFC PATCH 14/49] ARM: VGIC: extend GIC CPU interface definitions

[Julien Grall]

Hi,

This patch seem to modify the GICv2 CPU interface definitions. If so, 
please make it clear in the commit message/title.


On 09/02/18 14:39, Andre Przywara wrote:

The new VGIC will shortly use more bits of the GICC_CTLR register, so
add the respective definitions from the manual.
Also add a missing definition for GICV_PMR_PRIORITY_MASK.

You also add GICC_ABPR here.



Signed-off-by: Andre Przywara 
---
  xen/arch/arm/gic-v2.c |  2 +-
  xen/include/asm-arm/gic.h | 18 --
  2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 7a18abecfa..2e35892881 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -358,7 +358,7 @@ static void gicv2_cpu_init(void)
  /* Finest granularity of priority */
  writel_gicc(0x0, GICC_BPR);
  /* Turn on delivery */
-writel_gicc(GICC_CTL_ENABLE|GICC_CTL_EOI, GICC_CTLR);
+writel_gicc(GICC_CTL_ENABLE0|GICC_CTL_EOI, GICC_CTLR);
  }
  
  static void gicv2_cpu_disable(void)

diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index c1f027d703..c4c68c7770 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -77,6 +77,7 @@
  #define GICC_EOIR   (0x0010)
  #define GICC_RPR(0x0014)
  #define GICC_HPPIR  (0x0018)
+#define GICC_ABPR   (0x001c)
  #define GICC_APR(0x00D0)
  #define GICC_NSAPR  (0x00E0)
  #define GICC_IIDR   (0x00FC)
@@ -102,8 +103,18 @@
  #define GICD_TYPE_SEC   0x400
  #define GICD_TYPER_DVIS (1U << 18)
  
-#define GICC_CTL_ENABLE 0x1

-#define GICC_CTL_EOI(0x1 << 9)
+#define GICC_CTL_ENABLE0_SHIFT  0
+#define GICC_CTL_ENABLE0(1U << GICC_CTL_ENABLE0_SHIFT)


I guess GICCC_CTLR_ENABLE is renamed to GICC_CTL_ENABLE0 to match the 
spec. If so, please mention it in the commit message.



+#define GICC_CTL_ENABLE1_SHIFT  1
+#define GICC_CTL_ENABLE1(1U << GICC_CTL_ENABLE1)
+#define GICC_CTL_AC_SHIFT   2
+#define GICC_CTL_AC (1U << GICC_CTL_AC_SHIFT)
+#define GICC_CTL_FIQEN_SHIFT3
+#define GICC_CTL_FIQEN  (1U << GICC_CTL_FIQEN_SHIFT)
+#define GICC_CTL_CBPR_SHIFT 4
+#define GICC_CTL_CBPR   (1U << GICC_CTL_CBPR_SHIFT)
+#define GICC_CTL_EOI_SHIFT  9
+#define GICC_CTL_EOI(1U << GICC_CTL_EOI_SHIFT)
  
  #define GICC_IA_IRQ   0x03ff

  #define GICC_IA_CPU_MASK  0x1c00
@@ -127,6 +138,9 @@
  #define GICH_MISR_VGRP1E  (1 << 6)
  #define GICH_MISR_VGRP1D  (1 << 7)
  
+#define GICV_PMR_PRIORITY_SHIFT		3

+#define GICV_PMR_PRIORITY_MASK (0x1f << GICV_PMR_PRIORITY_SHIFT)
+
  /*
   * The minimum GICC_BPR is required to be in the range 0-3. We set
   * GICC_BPR to 0 but we must expect that it might be 3. This means we



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/7] x86/alt: Drop unused alternative infrastructure

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:01AM +, Andrew Cooper wrote:
> ALTERNATIVE_3 is more complicated than ALTERNATIVE_2 when it comes to
> calculating extra padding length, and we have no need for the complexity.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/7] x86/alt: Clean up the assembly used to generate alternatives

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:03AM +, Andrew Cooper wrote:
>  * On the C side, switch to using local lables rather than hardcoded numbers.
>  * Rename parameters and lables to be consistent with alt_instr names, and
>consistent between the the C and asm versions.
>  * On the asm side, factor some expressions out into macros to aid clarity.
>  * Consistently declare section attributes.
> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 4/7] x86/asm: Remove opencoded uses of altinstruction_entry

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:04AM +, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
> index 58f652d..bd3819a 100644
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -557,23 +557,9 @@ handle_exception_saved:
>  testb $X86_EFLAGS_IF>>8,UREGS_eflags+1(%rsp)
>  jzexception_with_ints_disabled
>  
> -.Lcr4_pv32_orig:
> -jmp   .Lcr4_pv32_done
> -.skip (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt) - (. - .Lcr4_pv32_orig), 
> 0xcc
> -.pushsection .altinstr_replacement, "ax"
> -.Lcr4_pv32_alt:
> -mov   VCPU_domain(%rbx),%rax
> -.Lcr4_pv32_alt_end:
> -.section .altinstructions, "a"
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMEP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -altinstruction_entry .Lcr4_pv32_orig, .Lcr4_pv32_alt, \
> - X86_FEATURE_XEN_SMAP, \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt), \
> - (.Lcr4_pv32_alt_end - .Lcr4_pv32_alt)
> -.popsection
> +ALTERNATIVE_2 "jmp .Lcr4_pv32_done; .skip 2, 0x90", \

This changed 0xcc to 0x90 but since it is just padding following an
unconditional jmp so it shouldn't matter.

Mostly looks fine. I'm a bit hesitant to give my Rb because reviewing
the diff to assembly is a bit more difficult to than diff to C source.

Do you have a branch somewhere?

Wei.

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

Re: [Xen-devel] [PATCH 2/7] x86/alt: Clean up struct alt_instr and its users

[Wei Liu]

On Mon, Feb 12, 2018 at 11:23:02AM +, Andrew Cooper wrote:
>  * Rename some fields for consistency and clarity, and use standard types.
>  * Don't opencode the use of ALT_{ORIG,REPL}_PTR().

And change u8 etc.

> 
> No functional change.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Roger Pau Monné 
> CC: Wei Liu 
> ---
>  xen/arch/x86/alternative.c| 24 
>  xen/include/asm-x86/alternative.h | 12 ++--
>  2 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
> index 5c8b6f6..f8ddab5 100644
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -163,8 +163,6 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>const struct alt_instr *end)
>  {
>  const struct alt_instr *a;
> -u8 *instr, *replacement;
> -u8 insnbuf[MAX_PATCH_LEN];
>  
>  printk(KERN_INFO "alt table %p -> %p\n", start, end);
>  
> @@ -179,23 +177,25 @@ void init_or_livepatch apply_alternatives(const struct 
> alt_instr *start,
>   */
>  for ( a = start; a < end; a++ )
>  {
> -instr = (u8 *)>instr_offset + a->instr_offset;
> -replacement = (u8 *)>repl_offset + a->repl_offset;
> -BUG_ON(a->replacementlen > a->instrlen);
> -BUG_ON(a->instrlen > sizeof(insnbuf));
> +uint8_t *orig = ALT_ORIG_PTR(a);
> +uint8_t *repl = ALT_REPL_PTR(a);
> +uint8_t buf[MAX_PATCH_LEN];
> +
> +BUG_ON(a->repl_len > a->orig_len);
> +BUG_ON(a->orig_len > sizeof(buf));
>  BUG_ON(a->cpuid >= NCAPINTS * 32);
> +
>  if ( !boot_cpu_has(a->cpuid) )
>  continue;
>  
> -memcpy(insnbuf, replacement, a->replacementlen);
> +memcpy(buf, repl, a->repl_len);
>  
>  /* 0xe8/0xe9 are relative branches; fix the offset. */
> -if ( a->replacementlen >= 5 && (*insnbuf & 0xfe) == 0xe8 )
> -*(s32 *)(insnbuf + 1) += replacement - instr;
> +if ( a->repl_len >= 5 && (*buf & 0xfe) == 0xe8 )
> +*(s32 *)(buf + 1) += repl - orig;

Mind changing s32 to int32_t?

In any case:

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [RFC PATCH 09/49] ARM: VGIC: change to level-IRQ compatible IRQ injection interface

[Julien Grall]

On 12/02/18 11:59, Andre Przywara wrote:

Hi,


Hi Andre,


On 12/02/18 11:15, Julien Grall wrote:

Hi Andre,

On 09/02/18 14:38, Andre Przywara wrote:

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5f47aa84a9..2fc6e19625 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -285,7 +285,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct
vcpu *new, unsigned int irq)
   vgic_remove_irq_from_queues(old, p);
   irq_set_affinity(p->desc, cpumask_of(new->processor));
   spin_unlock_irqrestore(>arch.vgic.lock, flags);
-    vgic_vcpu_inject_irq(new, irq);
+    vgic_inject_irq(new->domain, new, irq, true);
   return true;
   }
   /* if the IRQ is in a GICH_LR register, set GIC_IRQ_GUEST_MIGRATING
@@ -444,7 +444,7 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir,
enum gic_sgi_mode irqmode,
   sgir, target->list);
   continue;
   }
-    vgic_vcpu_inject_irq(d->vcpu[vcpuid], virq);
+    vgic_inject_irq(d, d->vcpu[vcpuid], virq, true);
   }
   break;
   case SGI_TARGET_OTHERS:
@@ -453,12 +453,12 @@ bool vgic_to_sgi(struct vcpu *v, register_t
sgir, enum gic_sgi_mode irqmode,
   {
   if ( i != current->vcpu_id && d->vcpu[i] != NULL &&
    is_vcpu_online(d->vcpu[i]) )
-    vgic_vcpu_inject_irq(d->vcpu[i], virq);
+    vgic_inject_irq(d, d->vcpu[i], virq, true);
   }
   break;
   case SGI_TARGET_SELF:
   perfc_incr(vgic_sgi_self);
-    vgic_vcpu_inject_irq(d->vcpu[current->vcpu_id], virq);
+    vgic_inject_irq(d, current, virq, true);
   break;
   default:
   gprintk(XENLOG_WARNING,
@@ -518,13 +518,29 @@ void vgic_remove_irq_from_queues(struct vcpu *v,
struct pending_irq *p)
   gic_remove_from_lr_pending(v, p);
   }
   -void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
+int vgic_inject_irq(struct domain *d, struct vcpu *v, unsigned int virq,
+    bool level)


Looking at the code after the series has been applied, no one is caring
about the return value of vgic_inject_irq. So what is the rationale
behind changing the return type from void to int?


The KVM version returns an error value, in particular when:
- the VGIC has not been initialized yet
- we can't determine the VCPU for a private interrupt
- the interrupt ID is invalid (SPI beyond limit, not mapped LPI)
In the moment it's not very useful for Xen: the first two conditions
don't really happen, consequently I removed those checks. But the third
check may become interesting once we get LPIs. Also since Xen currently
uses a void prototype for injection, *this* patch *now* doesn't exploit
the newly gained possibility of properly handling errors. From briefly
checking all the users, all of them seem to be in void functions, so
indeed an error return is not very useful.
The reasons I kept it in was to allow introduction of checks later. I
think having a function returning an error where some users ignore this
is better than the other way round.


I don't think it is much better. This is a way to expose yet another 
security issue because the return is not correctly checked (see XSA-246 
for instance). Any return value should be checked or have a comment 
explaining why it is fine.




So of course I can easily make this void, but I wonder what we do in
those cases where the SPI is not valid, for instance? Shall we print
some (rate-limited) warning?


I can understand why KVM needs such interface as the interrupt 
controller may be emulated QEMU. But I can't see why a SPI would not be 
valid in Xen context (except programming error). So could give an example?


What would you expect the caller to do on error? Except printing an 
error message?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 13/28] x86/vvtd: add a helper function to decide the interrupt format

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:20PM +0800, Chao Gao wrote:
> Different platform may use different method to distinguish
> remapping format interrupt and normal format interrupt.
> 
> Intel uses one bit in IOAPIC RTE or MSI address register to
> indicate the interrupt is remapping format. vvtd should handle
> all the interrupts when .check_irq_remapping() return true.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> 
> ---
> v3:
>  - new
> ---
>  xen/drivers/passthrough/vtd/vvtd.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index 9890cc2..d3dec01 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -565,6 +565,15 @@ static int vvtd_get_irq_info(const struct domain *d,
>  return 0;
>  }
>  
> +/* check whether the interrupt request is remappable */
> +static bool vvtd_is_remapping(const struct domain *d,

irq_remapped or intr_remapped would be clearer.

And likewise the comment in the previous patch, it would be much
better to introduce this together with check_irq_remapping and an
actual user.

Thanks, Roger.

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

Re: [Xen-devel] [RFC PATCH 13/49] ARM: VGIC: Add hypervisor base address to vgic_v2_setup_hw()

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

The new VGIC will need to know the hypervisor base address at some
point, which is private to the hardware facing part of the VGIC so far.
Add a parameter to vgic_v2_setup_hw() to pass this address on, so a VGIC
implementation can make use of it.
The current VGIC ignores this new parameter.

TODO: add proper value for GICv2 on GICv3 emulation!

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/gic-v2.c  | 3 ++-
  xen/arch/arm/gic-v3.c  | 3 ++-
  xen/arch/arm/vgic-v2.c | 3 ++-
  xen/include/asm-arm/vgic.h | 3 ++-
  4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2b271ba322..7a18abecfa 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -1207,7 +1207,8 @@ static int __init gicv2_init(void)
  if ( !gicv2.map_hbase )
  panic("GICv2: Failed to ioremap for GIC Virtual interface\n");
  
-vgic_v2_setup_hw(dbase, cbase, csize, vbase, aliased_offset);

+vgic_v2_setup_hw(dbase, cbase, csize, vbase, gicv2.map_hbase,
+ aliased_offset);
  
  /* Global settings: interrupt distributor */

  spin_lock_init();
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index ea14ab4028..08d4703687 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1238,7 +1238,8 @@ static void __init gicv3_init_v2(void)
  printk("GICv3 compatible with GICv2 cbase %#"PRIpaddr" vbase 
%#"PRIpaddr"\n",
 cbase, vbase);
  
-vgic_v2_setup_hw(dbase, cbase, csize, vbase, 0);

+/* TODO: provide the proper HBASE address! */


Well, on GICv3 the hypervisor interface will be configured using system 
registers. So I am not sure how your new interface is going to work with 
GICv3.


But IHMO, this is breaking the spirit of this interface. The goal is to 
tell "we can support a virtual GICv2". How the LRs (or anything touching 
the hardware) should be done using gic_hw_ops.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 09/49] ARM: VGIC: change to level-IRQ compatible IRQ injection interface

[Andre Przywara]

Hi,

On 12/02/18 11:15, Julien Grall wrote:
> Hi Andre,
> 
> On 09/02/18 14:38, Andre Przywara wrote:
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 5f47aa84a9..2fc6e19625 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -285,7 +285,7 @@ bool vgic_migrate_irq(struct vcpu *old, struct
>> vcpu *new, unsigned int irq)
>>   vgic_remove_irq_from_queues(old, p);
>>   irq_set_affinity(p->desc, cpumask_of(new->processor));
>>   spin_unlock_irqrestore(>arch.vgic.lock, flags);
>> -    vgic_vcpu_inject_irq(new, irq);
>> +    vgic_inject_irq(new->domain, new, irq, true);
>>   return true;
>>   }
>>   /* if the IRQ is in a GICH_LR register, set GIC_IRQ_GUEST_MIGRATING
>> @@ -444,7 +444,7 @@ bool vgic_to_sgi(struct vcpu *v, register_t sgir,
>> enum gic_sgi_mode irqmode,
>>   sgir, target->list);
>>   continue;
>>   }
>> -    vgic_vcpu_inject_irq(d->vcpu[vcpuid], virq);
>> +    vgic_inject_irq(d, d->vcpu[vcpuid], virq, true);
>>   }
>>   break;
>>   case SGI_TARGET_OTHERS:
>> @@ -453,12 +453,12 @@ bool vgic_to_sgi(struct vcpu *v, register_t
>> sgir, enum gic_sgi_mode irqmode,
>>   {
>>   if ( i != current->vcpu_id && d->vcpu[i] != NULL &&
>>    is_vcpu_online(d->vcpu[i]) )
>> -    vgic_vcpu_inject_irq(d->vcpu[i], virq);
>> +    vgic_inject_irq(d, d->vcpu[i], virq, true);
>>   }
>>   break;
>>   case SGI_TARGET_SELF:
>>   perfc_incr(vgic_sgi_self);
>> -    vgic_vcpu_inject_irq(d->vcpu[current->vcpu_id], virq);
>> +    vgic_inject_irq(d, current, virq, true);
>>   break;
>>   default:
>>   gprintk(XENLOG_WARNING,
>> @@ -518,13 +518,29 @@ void vgic_remove_irq_from_queues(struct vcpu *v,
>> struct pending_irq *p)
>>   gic_remove_from_lr_pending(v, p);
>>   }
>>   -void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int virq)
>> +int vgic_inject_irq(struct domain *d, struct vcpu *v, unsigned int virq,
>> +    bool level)
> 
> Looking at the code after the series has been applied, no one is caring
> about the return value of vgic_inject_irq. So what is the rationale
> behind changing the return type from void to int?

The KVM version returns an error value, in particular when:
- the VGIC has not been initialized yet
- we can't determine the VCPU for a private interrupt
- the interrupt ID is invalid (SPI beyond limit, not mapped LPI)
In the moment it's not very useful for Xen: the first two conditions
don't really happen, consequently I removed those checks. But the third
check may become interesting once we get LPIs. Also since Xen currently
uses a void prototype for injection, *this* patch *now* doesn't exploit
the newly gained possibility of properly handling errors. From briefly
checking all the users, all of them seem to be in void functions, so
indeed an error return is not very useful.
The reasons I kept it in was to allow introduction of checks later. I
think having a function returning an error where some users ignore this
is better than the other way round.

So of course I can easily make this void, but I wonder what we do in
those cases where the SPI is not valid, for instance? Shall we print
some (rate-limited) warning?

Cheers,
Andre.

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

Re: [Xen-devel] [RFC PATCH 12/49] ARM: VGIC: introduce gic_get_nr_lrs()

[Julien Grall]

Hi Andre,

On 09/02/18 14:39, Andre Przywara wrote:

So far the number of list registers (LRs) a GIC implements is only
needed in the hardware facing side of the VGIC code (gic-vgic.c).
The new VGIC will need this information in more and multiple places, so
export a function that returns the number.

Signed-off-by: Andre Przywara 
---
  xen/arch/arm/gic-vgic.c   | 10 +-
  xen/arch/arm/gic.c|  5 +
  xen/include/asm-arm/gic.h |  1 +
  3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/gic-vgic.c b/xen/arch/arm/gic-vgic.c
index d273863556..c92626e4ee 100644
--- a/xen/arch/arm/gic-vgic.c
+++ b/xen/arch/arm/gic-vgic.c
@@ -25,7 +25,7 @@
  #include 
  #include 
  
-#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_hw_ops->info->nr_lrs) - 1))

+#define lr_all_full() (this_cpu(lr_mask) == ((1 << gic_get_nr_lrs()) - 1))
  
  #undef GIC_DEBUG
  
@@ -110,7 +110,7 @@ static unsigned int gic_find_unused_lr(struct vcpu *v,

 struct pending_irq *p,
 unsigned int lr)
  {
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
  unsigned long *lr_mask = (unsigned long *) _cpu(lr_mask);
  struct gic_lr lr_val;
  
@@ -137,7 +137,7 @@ void gic_raise_guest_irq(struct vcpu *v, unsigned int virtual_irq,

  unsigned int priority)
  {
  int i;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
  struct pending_irq *p = irq_to_pending(v, virtual_irq);
  
  ASSERT(spin_is_locked(>arch.vgic.lock));

@@ -251,7 +251,7 @@ void gic_clear_lrs(struct vcpu *v)
  {
  int i = 0;
  unsigned long flags;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
  
  /* The idle domain has no LRs to be cleared. Since gic_restore_state

   * doesn't write any LR registers for the idle domain they could be
@@ -278,7 +278,7 @@ static void gic_restore_pending_irqs(struct vcpu *v)
  struct pending_irq *p, *t, *p_r;
  struct list_head *inflight_r;
  unsigned long flags;
-unsigned int nr_lrs = gic_hw_ops->info->nr_lrs;
+unsigned int nr_lrs = gic_get_nr_lrs();
  int lrs = nr_lrs;
  
  spin_lock_irqsave(>arch.vgic.lock, flags);

diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 968e46fabb..89873c1df4 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -47,6 +47,11 @@ void register_gic_ops(const struct gic_hw_operations *ops)
  gic_hw_ops = ops;
  }
  
+int gic_get_nr_lrs(void)


unsigned int here please.

Also, given that gic_hw_ops is exported in gic.h, it would make sense to 
make that helper static inline in gic.h.



+{
+return gic_hw_ops->info->nr_lrs;
+}
+
  static void clear_cpu_lr_mask(void)
  {
  this_cpu(lr_mask) = 0ULL;
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index 1d382b0ade..c1f027d703 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -222,6 +222,7 @@ enum gic_version {
  DECLARE_PER_CPU(uint64_t, lr_mask);
  
  extern enum gic_version gic_hw_version(void);

+extern int gic_get_nr_lrs(void);
  
  /* Program the IRQ type into the GIC */

  void gic_set_irq_type(struct irq_desc *desc, unsigned int type);



Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 12/28] x86/vvtd: decode interrupt attribute from IRTE

[Roger Pau Monné]

On Fri, Nov 17, 2017 at 02:22:19PM +0800, Chao Gao wrote:
> Without interrupt remapping, interrupt attributes can be extracted from
> msi message or IOAPIC RTE. However, with interrupt remapping enabled,
> the attributes are enclosed in the associated IRTE. This callback is
> for cases in which the caller wants to acquire interrupt attributes, for
> example:
> 1. vioapic_get_vector(). With vIOMMU, the RTE may don't contain vector.
^ doesn't contain the vector.
> 2. perform EOI which is always based on the interrupt vector.
> 
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 
> ---
> v3:
>  - add example cases in which we will use this function.

I'm still missing the actual usage of vvtd_get_irq_info. This handler
is introduced without any user.

> ---
>  xen/drivers/passthrough/vtd/vvtd.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/xen/drivers/passthrough/vtd/vvtd.c 
> b/xen/drivers/passthrough/vtd/vvtd.c
> index 927e715..9890cc2 100644
> --- a/xen/drivers/passthrough/vtd/vvtd.c
> +++ b/xen/drivers/passthrough/vtd/vvtd.c
> @@ -541,6 +541,30 @@ static int vvtd_handle_irq_request(const struct domain 
> *d,
>  return ret;
>  }
>  
> +static int vvtd_get_irq_info(const struct domain *d,

IMO for internal (static) functions you can drop the vvtd_ prefix.

> + const struct arch_irq_remapping_request *irq,
> + struct arch_irq_remapping_info *info)
> +{
> +int ret;
> +struct iremap_entry irte;
> +struct vvtd *vvtd = domain_vvtd(d);
> +
> +if ( !vvtd )
> +return -ENODEV;
> +
> +ret = vvtd_get_entry(vvtd, irq, );
> +/* not in an interrupt delivery, don't report faults to guest */
> +if ( ret )
> +return ret;
> +
> +info->vector = irte.remap.vector;
> +info->dest = irte_dest(vvtd, irte.remap.dst);
> +info->dest_mode = irte.remap.dm;
> +info->delivery_mode = irte.remap.dlm;
> +
> +return 0;
> +}
> +
>  static void vvtd_reset(struct vvtd *vvtd)
>  {
>  uint64_t cap = cap_set_num_fault_regs(VVTD_FRCD_NUM)
> @@ -603,6 +627,7 @@ static const struct viommu_ops vvtd_hvm_vmx_ops = {
>  .create = vvtd_create,
>  .destroy = vvtd_destroy,
>  .handle_irq_request = vvtd_handle_irq_request,
> +.get_irq_info = vvtd_get_irq_info,

So the public helper to this arch specific hook is added in 4/28, yet
the arch specific code is added here, and I still have to figure out
where this will actually be hooked into the vIOAPIC or vMSI code.

Would it be possible to have a single patch, which contains 4/28, the
code in this patch and the glue that hooks this into the vIOAPIC and
vMSI code?

The above likely applies to quite a lot of patches in this series.
It's fine to try to reduce the size of patches as much as possible,
but at least in this series this is actually harming (at least my)
capability to review them.

Thanks, Roger.

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

Re: [Xen-devel] [RFC PATCH 11/49] ARM: VGIC: reorder prototypes in vgic.h

[Julien Grall]

Hi Andre,

On 09/02/18 14:38, Andre Przywara wrote:

  /*
- * Allocate a guest VIRQ
- *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
- *  - spi == 1 => allocate an SPI
+ * In the moment vgic_num_irqs() just covers SPIs and the private IRQs,
+ * as it's mostly used for allocating the pending_irq and irq_desc array,
+ * in which LPIs don't participate.
   */
-extern int vgic_allocate_virq(struct domain *d, bool spi);
+#define vgic_num_irqs(d)((d)->arch.vgic.nr_spis + 32)
  
+/*

+ * Allocate a guest VIRQ
+ *  - is_spi == 0 => allocate a PPI. It will be the same on every vCPU
+ *  - is_spi == 1 => allocate an SPI
+ */
+extern int vgic_allocate_virq(struct domain *d, bool is_spi);
+/* Reserve a specific guest vIRQ */
+extern bool vgic_reserve_virq(struct domain *d, unsigned int virq);
+extern void vgic_free_virq(struct domain *d, unsigned int virq);


newline here please.

Otherwise the split looks good:

Reviewed-by: Julien Grall 

Cheers,


  static inline int vgic_allocate_ppi(struct domain *d)
  {
  return vgic_allocate_virq(d, false /* ppi */);
@@ -340,18 +340,21 @@ static inline int vgic_allocate_spi(struct domain *d)
  return vgic_allocate_virq(d, true /* spi */);
  }
  
-extern void vgic_free_virq(struct domain *d, unsigned int virq);

+struct irq_desc *vgic_get_hw_irq_desc(struct domain *d, struct vcpu *v,
+  unsigned int virq);
+int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
+struct irq_desc *desc, bool connect);
  
-void vgic_v2_setup_hw(paddr_t dbase, paddr_t cbase, paddr_t csize,

-  paddr_t vbase, uint32_t aliased_offset);
+bool vgic_evtchn_irq_pending(struct vcpu *v);
  
-#ifdef CONFIG_HAS_GICV3

-struct rdist_region;
-void vgic_v3_setup_hw(paddr_t dbase,
-  unsigned int nr_rdist_regions,
-  const struct rdist_region *regions,
-  unsigned int intid_bits);
-#endif
+int domain_vgic_register(struct domain *d, int *mmio_count);
+int domain_vgic_init(struct domain *d, unsigned int nr_spis);
+void domain_vgic_free(struct domain *d);
+int vcpu_vgic_init(struct vcpu *vcpu);
+int vcpu_vgic_free(struct vcpu *vcpu);
+
+int vgic_inject_irq(struct domain *d, struct vcpu *v, unsigned int virq,
+bool level);
  
  #endif /* __ASM_ARM_VGIC_H__ */
  



--
Julien Grall

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

Re: [Xen-devel] [RFC PATCH 00/49] New VGIC(-v2) implementation

[Andre Przywara]

Hi,

On 12/02/18 11:48, Julien Grall wrote:
> 
> 
> On 09/02/18 15:06, Andre Przywara wrote:
>> Hi,
> 
> Hi Andre,
> 
>> On 09/02/18 14:38, Andre Przywara wrote:
>>> tl;dr: More preparatory patches from patch 07, actual new VGIC starting
>>> at patch 20.
>>> =
>>>
>>> During development of the Dom0 ITS MSI support last year we realised
>>> that the existing GIC interrupt controller emulation has some
>>> shortcomings.
>>> After some tries to fix those in the existing code, it was agreed upon
>>> that the problems are fundamental and a new implementation based on the
>>> "new VGIC" in KVM is the best choice.
>>> This is the first drop of this new VGIC implementation.
>>
>> Just in case you are *really* interested:
>> The code can also be found in the vgic-new/rfc branch here:
>> git://linux-arm.org/xen-ap.git
>> http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/rfc
>>
> 
> This branch seems to contain more than this series. Anything we should
> care in it?

Oh dear, this was my development branch. Thanks for the heads up! I just
trimmed it to match the series I posted.
Please, re-fetch it now and then go wash your hands in case you looked
at any of the top patches ;-)

Cheers,
Andre.

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

Re: [Xen-devel] [RFC PATCH 00/49] New VGIC(-v2) implementation

[Julien Grall]

On 09/02/18 15:06, Andre Przywara wrote:

Hi,


Hi Andre,


On 09/02/18 14:38, Andre Przywara wrote:

tl;dr: More preparatory patches from patch 07, actual new VGIC starting
at patch 20.
=

During development of the Dom0 ITS MSI support last year we realised
that the existing GIC interrupt controller emulation has some shortcomings.
After some tries to fix those in the existing code, it was agreed upon
that the problems are fundamental and a new implementation based on the
"new VGIC" in KVM is the best choice.
This is the first drop of this new VGIC implementation.


Just in case you are *really* interested:
The code can also be found in the vgic-new/rfc branch here:
git://linux-arm.org/xen-ap.git
http://www.linux-arm.org/git?p=xen-ap.git;a=shortlog;h=refs/heads/vgic-new/rfc


This branch seems to contain more than this series. Anything we should 
care in it?


Cheers,

--
Julien Grall

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