Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross]

On 07/12/16 18:10, Ian Jackson wrote:
> Juergen Gross writes ("Xenstore domains and XS_RESTRICT"):
>> In order to solve the problem I suggest the following change to the
>> Xenstore wire protocol:
>>
>>  struct xsd_sockmsg
>>  {
>> -uint32_t type;  /* XS_??? */
>> +uint16_t type;  /* XS_??? */
>> +uint16_t domid; /* Use privileges of this domain */
> 
> I don't think this is a particularly nice extension.  (Also the way
> you have written it has an endianness hazard.)  What if we decide, at
> some future point, to support domids >2^16 ?  That's hard right now
> but I don't want to make it harder.

Do we support any big endian systems? I don't think so. An endianess
problem could occur only if there are any big endian systems using the
old (current) struct xsd_sockmsg.

Regarding size of domid: this is true.

> 
> I suggest the following protocol extension instead:
> 
> Add to xenstore.txt (the list of xenstore commands):
> 
>   RESTRICTCMD 
> 
>   Here  is a domain id, and  is a command
> number; both of these are 32-bit integers in host byte order.

Hmm, normally parameters outside the command header are transferred
using ASCII representation. Do we really want to introduce the first
exception?

> 
>   This is an instruction to execute the command 
> with payload .  However, all permissions
> checking should be done as if the command had been issued by
> domain .
> 
> The req_id and tx_id, and (if the command affects watches) any
> watches that are manipulated, are those of the calling
> connection.  So the reply is sent to the xenstore client
> (usually, ring client) which sent the RESTRICTCMD command.
> 
> If RESTRICTCMD is used to invoke WATCH, the  from the
> RESTRICTCMD is attached to the watch, in xenstored.  Insofar
> as watch events are filtered by the permission system, the
>  from the RESTRICTCMD is used for watch events
> originating from such a watch.  But the actual watch events
> are sent to the connection that called RESTRICTCMD.
> 
>   This is similar in semantics to RESTRICT but applies to this
>   one particular command (and its effects), only.
> 
> RESTRICTCMD has no effect on, and is not visible through, the
> xenstore ring connection of domain  (if that domain
> has one).
> 
> What do you think ?
> 
> There is a command length limit implication but I don't think that's
> important.

That was the first problem coming to my mind. OTOH I'm not sure this
is really a problem as users of RESTRICTCMD should have no need to
use payloads of 4k.

In summary I see advantages for both solutions. IMO the needed changes
for my solution will be a little bit smaller, though.


Juergen

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

[Xen-devel] prebuilt binaries for arm-cortex a15 dom0 modules for xen

[George John]

Hi,
I am a newbie working on xen. I have brought up Dom0 in lager board. I want
to bring up Dom U in lager. I would like to know whether there are any
prebuilt binaries for xen dom0 modules for arm cortex a15 .
regards,
George
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross]

On 07/12/16 18:00, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: Xenstore domains and XS_RESTRICT"):
>> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
>>> There is no socket connection to xenstore domain.
>>
>> Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
>> with domid_id of zero? Or are you saying this is irrelevant becasue
>> what you are interested is for the Linux kernel to filter certain
>> xsd_sockmsg so it won't do something silly?
> 
> The latter.
> 
>> OK, so this all sounds like the OS needs to mediate access? Sorry for
>> being so dense this morning.
> 
> The OS already needs to mediate access for all xenstore commands.  The
> kernel xenbus driver has a list of the commands.  Some of them it will
> "simply" proxy, translating request id and transaction fields, as
> applicable.  Some of them it does something special for.  Unknown
> commands are rejected.

Sorry, this isn't true. There is special handling for watch/unwatch and
transaction start/end. There is no other command filtering involved,
especially no rejection of unknown commands.

> 
>> This would imply that the kernel driver would need to understand
>> the format and disallow the XS_RESTRICT under certain conditions?
> 
> There should be a way to tell the kernel driver that the connection
> should be restricted.  XS_RESTRICT is as good as any.
> 
> But the XS_RESTRICT command must not be forwarded by the kernel proxy
> to the real xenstore.  Rather, the driver must make an annotation in
> its client struct instead.
> 
> That annotation should result in _every_ proxied xenstore command,
> from that client, being decorated so as to specify the restriction
> domain.
> 
> There needs to be an extension to the xenstore protocol to support
> this.

Right.


Juergen


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  3651d9e5c0f90e94d41187a69f04df3647c61a82
baseline version:
 xen  779a0e15ca0d9d5dbcbdee29b1dad9faf73bfc77

Last test of basis   103045  2016-12-07 20:03:56 Z0 days
Testing same since   103052  2016-12-07 23:06:02 Z0 days2 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

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

Re: [Xen-devel] [PATCH] xen/pci: Bubble up error and fix description.

[Juergen Gross]

On 06/12/16 15:28, Konrad Rzeszutek Wilk wrote:
> The function is never called under PV guests, and only shows up
> when MSI (or MSI-X) cannot be allocated. Convert the message
> to include the error value.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 

Commited to xen/tip.git for-linus-4.10


Juergen


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

Re: [Xen-devel] [PATCH 1/1 v2] xen: xenbus: set error code on failure

[Juergen Gross]

On 05/12/16 09:22, Pan Bian wrote:
> Variable err is initialized with 0. As a result, the return value may 
> be 0 even if get_zeroed_page() fails to allocate memory. This patch fixes
> the bug, initializing err with "-ENOMEM".
> 
> v1 is reviewed by: Juergen Gross 
> 
> Signed-off-by: Pan Bian 

Commited to xen/tip.git for-linus-4.10


Juergen


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

Re: [Xen-devel] [PATCH 1/1 v2] xen: set error code on failures

[Juergen Gross]

On 05/12/16 09:23, Pan Bian wrote:
> Variable rc is reset in the loop, and its value will be non-negative
> during the second and after repeat of the loop. If it fails to allocate
> memory then, it may return a non-negative integer, which indicates no
> error. This patch fixes the bug, assigning "-ENOMEM" to rc when
> kzalloc() or alloc_page() returns NULL, and removing the initialization
> of rc outside of the loop.
> 
> v1 is reviewed by: Juergen Gross 
> 
> Signed-off-by: Pan Bian 

Commited to xen/tip.git for-linus-4.10


Juergen


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

Re: [Xen-devel] [PATCH v3 03/24] x86/emul: Simplfy emulation state setup

[George Dunlap]

> On Nov 30, 2016, at 9:50 PM, Andrew Cooper  wrote:
> 
> The current code to set up emulation state is ad-hoc and error prone.
> 
> * Consistently zero all emulation state structures.
> * Avoid explicitly initialising some state to 0.
> * Explicitly identify all input and output state in x86_emulate_ctxt.  This
>   involves rearanging some fields.
> * Have x86_decode() explicitly initalise all output state at its start.
> 
> While making the above changes, two minor tweaks:
> 
> * Move the calculation of hvmemul_ctxt->ctxt.swint_emulate from
>   _hvm_emulate_one() to hvm_emulate_init_once().  It doesn't need
>   recalculating for each instruction.
> * Change force_writeback to being a boolean, to match its use.
> 
> Signed-off-by: Andrew Cooper 
> Acked-by: Tim Deegan 
> Reviewed-by: Jan Beulich 
> Reviewed-by: Paul Durrant 

Not sure this is still needed, but just in case:

Acked-by: George Dunlap 

> ---
> CC: George Dunlap 
> 
> v2:
> * Split x86_emulate_ctxt into three sections
> ---
> xen/arch/x86/hvm/emulate.c | 28 +++-
> xen/arch/x86/mm.c  | 14 --
> xen/arch/x86/mm/shadow/common.c|  4 ++--
> xen/arch/x86/x86_emulate/x86_emulate.c |  1 +
> xen/arch/x86/x86_emulate/x86_emulate.h | 32 ++--
> 5 files changed, 48 insertions(+), 31 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index f1f6e2f..3efeead 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1770,13 +1770,6 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
> *hvmemul_ctxt,
> 
> vio->mmio_retry = 0;
> 
> -if ( cpu_has_vmx )
> -hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_none;
> -else if ( cpu_has_svm_nrips )
> -hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_icebp;
> -else
> -hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_all;
> -
> rc = x86_emulate(_ctxt->ctxt, ops);
> 
> if ( rc == X86EMUL_OKAY && vio->mmio_retry )
> @@ -1947,14 +1940,23 @@ void hvm_emulate_init_once(
> struct hvm_emulate_ctxt *hvmemul_ctxt,
> struct cpu_user_regs *regs)
> {
> -hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(current);
> -hvmemul_ctxt->ctxt.regs = regs;
> -hvmemul_ctxt->ctxt.force_writeback = 1;
> -hvmemul_ctxt->seg_reg_accessed = 0;
> -hvmemul_ctxt->seg_reg_dirty = 0;
> -hvmemul_ctxt->set_context = 0;
> +struct vcpu *curr = current;
> +
> +memset(hvmemul_ctxt, 0, sizeof(*hvmemul_ctxt));
> +
> +hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(curr);
> hvmemul_get_seg_reg(x86_seg_cs, hvmemul_ctxt);
> hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
> +
> +hvmemul_ctxt->ctxt.regs = regs;
> +hvmemul_ctxt->ctxt.force_writeback = true;
> +
> +if ( cpu_has_vmx )
> +hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_none;
> +else if ( cpu_has_svm_nrips )
> +hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_icebp;
> +else
> +hvmemul_ctxt->ctxt.swint_emulate = x86_swint_emulate_all;
> }
> 
> void hvm_emulate_init_per_insn(
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 5b0e9f3..d365f59 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -5337,7 +5337,14 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long 
> addr,
> struct domain *d = v->domain;
> struct page_info *page;
> l1_pgentry_t  pte;
> -struct ptwr_emulate_ctxt ptwr_ctxt;
> +struct ptwr_emulate_ctxt ptwr_ctxt = {
> +.ctxt = {
> +.regs = regs,
> +.addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
> +.sp_size   = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
> +.swint_emulate = x86_swint_emulate_none,
> +},
> +};
> int rc;
> 
> /* Attempt to read the PTE that maps the VA being accessed. */
> @@ -5363,11 +5370,6 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long 
> addr,
> goto bail;
> }
> 
> -ptwr_ctxt.ctxt.regs = regs;
> -ptwr_ctxt.ctxt.force_writeback = 0;
> -ptwr_ctxt.ctxt.addr_size = ptwr_ctxt.ctxt.sp_size =
> -is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG;
> -ptwr_ctxt.ctxt.swint_emulate = x86_swint_emulate_none;
> ptwr_ctxt.cr2 = addr;
> ptwr_ctxt.pte = pte;
> 
> diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
> index 7e5b8b0..a4a3c4b 100644
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -385,8 +385,9 @@ const struct x86_emulate_ops *shadow_init_emulation(
> struct vcpu *v = current;
> unsigned long addr;
> 
> +memset(sh_ctxt, 0, sizeof(*sh_ctxt));
> +
> sh_ctxt->ctxt.regs = regs;
> -sh_ctxt->ctxt.force_writeback = 

Re: [Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen

[Juergen Gross]

On 07/12/16 19:29, Dario Faggioli wrote:
> Setting and getting the CPU class of a vCPU will happen via two new
> hypercalls:
> 
> * `XEN_DOMCTL_setvcpuclass`
> * `XEN_DOMCTL_setvcpuclass`

XEN_DOMCTL_getvcpuclass

> ### Phase 2
> 
> Inside Xen, the various schedulers will be modified to deal internally with
> the fact that vCPUs can only run on pCPUs from the class(es) they are
> associated with. This allows for more efficient implementation, and paves
> the way for enabling more intelligent logic (e.g., for minimizing power
> consumption) in *phase 3*.
> 
> Calling `libxl_set_vcpuaffinity()` from `xl` / libxl is therefore no longer
> necessary and will be avoided (i.e., only `libxl_set_vcpuclass()` will be
> called).

Any idea how to avoid problems in the schedulers related to vcpus with
different weights? Remember, weights and pinning don't go well together,
that was the main reason for inventing cpupools. You should at least
name that problem. In case of vcpus being capable to run on pcpus of
more than one class this problem might surface again.


Juergen


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

[Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-xl-qemuu-ovmf-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid xen-boot

Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.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/stable/linux-stable.git
  Bug introduced:  24542192519d21719377d89f14654b3afd993a61
  Bug not present: c6f51aabaf400f357eebe8f8f17e8bb39fc033dc
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103066/


  commit 24542192519d21719377d89f14654b3afd993a61
  Author: Kashyap Desai 
  Date:   Fri Oct 21 06:33:32 2016 -0700
  
  scsi: megaraid_sas: Fix data integrity failure for JBOD (passthrough) 
devices
  
  [ Upstream commit 1e793f6fc0db920400574211c48f9157a37e3945 ]
  
  Commit 02b01e010afe ("megaraid_sas: return sync cache call with
  success") modified the driver to successfully complete SYNCHRONIZE_CACHE
  commands without passing them to the controller. Disk drive caches are
  only explicitly managed by controller firmware when operating in RAID
  mode. So this commit effectively disabled writeback cache flushing for
  any drives used in JBOD mode, leading to data integrity failures.
  
  [mkp: clarified patch description]
  
  Fixes: 02b01e010afeeb49328d35650d70721d2ca3fd59
  CC: sta...@vger.kernel.org
  Signed-off-by: Kashyap Desai 
  Signed-off-by: Sumit Saxena 
  Reviewed-by: Tomas Henzl 
  Reviewed-by: Hannes Reinecke 
  Reviewed-by: Ewan D. Milne 
  Signed-off-by: Martin K. Petersen 
  Signed-off-by: Sasha Levin 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-3.18/test-amd64-amd64-xl-qemuu-ovmf-amd64.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-3.18/test-amd64-amd64-xl-qemuu-ovmf-amd64.xen-boot
 --summary-out=tmp/103066.bisection-summary --basis-template=101675 
--blessings=real,real-bisect linux-3.18 test-amd64-amd64-xl-qemuu-ovmf-amd64 
xen-boot
Searching for failure / basis pass:
 102974 fail [host=elbling0] / 101675 [host=chardonnay1] 101662 [host=pinot1] 
101648 [host=merlot1] 101637 [host=chardonnay0] 101623 [host=huxelrebe1] 101603 
[host=italia0] 101584 [host=baroque1] 101570 [host=huxelrebe0] 101561 
[host=fiano1] 101552 [host=nocera0] 101541 [host=pinot0] 101532 ok.
Failure / basis pass flights: 102974 / 101532
(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/stable/linux-stable.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 ac3d826bef907afe35f80ecccbcdd57223df4b88 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
89c4cbe8d234049b0145e4dc5e5d19d626250b57 
4220231eb22235e757d269722b9f6a594fbcb70f 
8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf
Basis pass 3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
05e379bd279768495cdc516f17a120e30dfbcca5
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430-ac3d826bef907afe35f80ecccbcdd57223df4b88
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-89c4cbe8d234049b0145e4dc5e5d19d626250b57
 
git://xenbits.xen.org/qemu-xen.git#570117996772b762e9654e58e708943a4db68b4f-4220231eb22235e757d269722b9f6a594fbcb70f
 
git://xenbits.xen.org/xen.git#05e379bd279768495cdc516f17a120e30dfbcca5-8e4b2676685f50bc26f03b5f62d8b7aea8e69dbf
Loaded 7002 nodes in revision graph
Searching for test results:
 101493 [host=italia1]
 101532 pass 3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
05e379bd279768495cdc516f17a120e30dfbcca5
 101515 [host=elbling1]
 101497 [host=fiano0]
 101552 [host=nocera0]
 101541 [host=pinot0]
 101561 [host=fiano1]
 101570 [host=huxelrebe0]
 101584 [host=baroque1]
 101603 

Re: [Xen-devel] [RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

[Juergen Gross]

On 05/12/16 18:49, Alex Thorlton wrote:
> This is the third pass at my patchset to fix up our problems with
> XENMEM_machine_memory_map on large systems.  The only changes on this
> pass were to flesh out the comment above the E820_X_MAX definition, and
> to add Juergen's Reviewed-by to the second patch.
> 
> Let me know if anyone has any questions/comments!
> 
> Alex Thorlton (2):
>   x86: Make E820_X_MAX unconditionally larger than E820MAX
>   xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
> 
>  arch/x86/include/asm/e820.h | 12 
>  arch/x86/xen/setup.c|  6 +++---
>  2 files changed, 11 insertions(+), 7 deletions(-)
> 

Ingo, do you have any preferences through which tree those patches
should go? I'd like to have at least patch 2 in 4.10, so I could take
it through the Xen tree.


Juergen

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

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

[osstest service owner]

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

Failures and problems with tests :-(

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

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

version targeted for testing:
 xen  3651d9e5c0f90e94d41187a69f04df3647c61a82
baseline version:
 xen  779a0e15ca0d9d5dbcbdee29b1dad9faf73bfc77

Last test of basis   103045  2016-12-07 20:03:56 Z0 days
Testing same since   103052  2016-12-07 23:06:02 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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



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-step build-amd64 host-install(3)

Not pushing.


commit 3651d9e5c0f90e94d41187a69f04df3647c61a82
Author: Julien Grall 
Date:   Wed Dec 7 12:33:53 2016 +

xen/arm: vgic-v3: Allow AArch32 guest booting with GICv3

AArch32 guest will use co-processor registers to access the GICv3 (see
8.5 in IHI 0069C). Some of the registers have to be trapped and emulated
(e.g ICC_SGI1R), this is the purpose of this patch.

The rest of the emulation already supports access required for AArch32
so nothing has to be changed there.

Note this is only enabling 32-bit guest using GICv3 on Xen ARM64. Further
work would be required to compile GICv3 and vGICv3 for Xen ARM32.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 8c6feb177d1e17466aed2fda8784acb1f9d18d11
Author: Julien Grall 
Date:   Wed Dec 7 12:33:52 2016 +

xen/arm: vgic-v3: Move the emulation of ICC_SGI1R_EL1 in a separate helper

The emulation of the co-processor register ICC_SGI1R is the same as the
system register ICC_SGI1R_EL1. So move the emulation outside and use the
newly introduced helper vreg_emulate_sysreg64 to abstract the access.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 572190dbe5deb5ffce2231904b85231eb36e6c19
Author: Julien Grall 
Date:   Wed Dec 7 12:33:51 2016 +

xen/arm: vgic: Rename emulate_sysreg callback to emulate_reg

We will want to emulate co-processor registers access in a follow-up
patch.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit cc9e34d57a75c192bf4c6ebcd2e9055113093497
Author: Julien Grall 
Date:   Wed Dec 7 12:33:50 2016 +

xen/arm: vreg: Introduce vreg_emulate_cp{32,64}

Factorize the code to emulate 32-bit and 64-bit access to a co-processor
in specific helpers.

The new helpers will be used in different components to simplify the
emulation.

Finally, the prototypes for the callbacks to emulate 32-bit and 64-bit
co-processor access are the same as the sysreg one. Rather than
introducing new ones, repurpose the existent prototypes.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 836a0e2aecb3809d4ef7d58fe5db88a029222e1f
Author: Julien Grall 
Date:   Wed Dec 7 12:33:49 2016 +

xen/arm: 

[Xen-devel] [xen-4.5-testing bisection] complete test-xtf-amd64-amd64-2

[osstest service owner]

branch xen-4.5-testing
xenbranch xen-4.5-testing
job test-xtf-amd64-amd64-2
testid leak-check/check

Tree: linux git://xenbits.xen.org/linux-pvops.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
Tree: xtf git://xenbits.xen.org/xtf.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xtf git://xenbits.xen.org/xtf.git
  Bug introduced:  b945085085fe782d20524b7f4bf95875407cd081
  Bug not present: 6d562f0e17d8187aca7a47a38b584b989c8ded7a
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/103050/


  commit b945085085fe782d20524b7f4bf95875407cd081
  Author: Andrew Cooper 
  Date:   Wed Nov 2 18:44:43 2016 +
  
  XSA-195 PoC
  
  Signed-off-by: Andrew Cooper 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.5-testing/test-xtf-amd64-amd64-2.leak-check--check.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.5-testing/test-xtf-amd64-amd64-2.leak-check--check
 --summary-out=tmp/103050.bisection-summary --basis-template=102721 
--blessings=real,real-bisect xen-4.5-testing test-xtf-amd64-amd64-2 
leak-check/check
Searching for failure / basis pass:
 103007 fail [host=italia1] / 102721 [host=huxelrebe1] 102710 
[host=chardonnay1] 102690 [host=godello0] 102683 [host=fiano0] 102679 
[host=huxelrebe0] 102673 [host=elbling0] 102666 [host=baroque1] 102657 
[host=baroque0] 102637 [host=italia0] 102601 [host=chardonnay0] 102543 
[host=nobling1] 102520 [host=nobling0] 101275 [host=godello1] 101258 
[host=italia0] 101106 [host=godello0] 101088 [host=fiano1] 101070 
[host=huxelrebe1] 101045 [host=pinot1] 100909 ok.
Failure / basis pass flights: 103007 / 100909
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.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
Tree: xtf git://xenbits.xen.org/xtf.git
Latest b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
fadd27b1a7d6f5cfc4786ef09d60b368e44226ad 
37a460ca696381bb14dfbf012d7a062c7c05c324 
bdf3ef18a3f5d7f2e6b198838f6e77f237d3e3f2 
1f021c88130b4d2d818ba4f269b3929339c00a88
Basis pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
28c21388c2a32259cff37fc578684f994dca8c9f 
835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a 
b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#b65f2f457c49b2cfd7967c34b7a0b04c25587f13-b65f2f457c49b2cfd7967c34b7a0b04c25587f13
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#28c21388c2a32259cff37fc578684f994dca8c9f-fadd27b1a7d6f5cfc4786ef09d60b368e44226ad
 
git://xenbits.xen.org/qemu-xen.git#835c204f1196ab8f5213a9dc5299ed76e748cdca-37a460ca696381bb14dfbf012d7a062c7c05c324
 
git://xenbits.xen.org/xen.git#c18dfbb88670e9f2cabd93bbb32f661b71ffb73a-bdf3ef18a3f5d7f2e6b198838f6e77f237d3e3f2
 
git://xenbits.xen.org/xtf.git#b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3-1f021c88130b4d2d818ba4f269b3929339c00a88
Use of uninitialized value $parents in array dereference at 
./adhoc-revtuple-generator line 464.
Use of uninitialized value in concatenation (.) or string at 
./adhoc-revtuple-generator line 464.
Loaded 1277 nodes in revision graph
Searching for test results:
 100909 pass b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
28c21388c2a32259cff37fc578684f994dca8c9f 
835c204f1196ab8f5213a9dc5299ed76e748cdca 
c18dfbb88670e9f2cabd93bbb32f661b71ffb73a 
b5c5332de4268d33a6f8eadc1d17c7b9cf0e7dc3
 101015 []
 101045 [host=pinot1]
 101024 []
 101070 [host=huxelrebe1]
 101088 [host=fiano1]
 101106 [host=godello0]
 101275 [host=godello1]
 101258 [host=italia0]
 102520 [host=nobling0]
 102543 [host=nobling1]
 102601 [host=chardonnay0]
 102637 [host=italia0]
 102666 [host=baroque1]
 102683 [host=fiano0]
 102673 [host=elbling0]
 102657 [host=baroque0]
 102679 [host=huxelrebe0]
 102710 [host=chardonnay1]
 102690 [host=godello0]
 102721 [host=huxelrebe1]
 102767 fail b65f2f457c49b2cfd7967c34b7a0b04c25587f13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
fadd27b1a7d6f5cfc4786ef09d60b368e44226ad 
37a460ca696381bb14dfbf012d7a062c7c05c324 
bdf3ef18a3f5d7f2e6b198838f6e77f237d3e3f2 
1f021c88130b4d2d818ba4f269b3929339c00a88
 102855 fail 

[Xen-devel] [xen-4.4-testing test] 103006: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt3 host-install(3) broken in 102751 REGR. vs. 102521

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64  3 host-install(3)   broken pass in 102962
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)broken pass in 102962
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3)broken pass in 102962
 test-amd64-amd64-xl-qemuu-win7-amd64  3 host-install(3)  broken pass in 102962
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 102751 pass 
in 102962
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
102751 pass in 103006
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 102751 pass 
in 103006
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 102962 
pass in 102914
 test-armhf-armhf-xl-arndale   6 xen-boot fail in 102962 pass in 103006
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
102962 pass in 103006
 test-xtf-amd64-amd64-3 20 xtf/test-hvm32-invlpg~shadow fail pass in 102751
 test-xtf-amd64-amd64-3  31 xtf/test-hvm32pae-invlpg~shadow fail pass in 102751
 test-xtf-amd64-amd64-3 42 xtf/test-hvm64-invlpg~shadow fail pass in 102751
 test-xtf-amd64-amd64-3   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-4   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-5   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-1   52 leak-check/check   fail pass in 102751
 test-xtf-amd64-amd64-2   52 leak-check/check   fail pass in 102751
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install fail pass in 102751

Regressions which are regarded as allowable (not blocking):
 test-xtf-amd64-amd64-5 16 xtf/test-pv32pae-selftest fail in 102751 like 102521
 test-xtf-amd64-amd64-3 16 xtf/test-pv32pae-selftest fail in 102751 like 102521
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail in 102751 like 102521
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail in 102914 like 102521
 test-xtf-amd64-amd64-4   16 xtf/test-pv32pae-selftestfail  like 102521
 test-xtf-amd64-amd64-2   16 xtf/test-pv32pae-selftestfail  like 102521
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102521
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102521

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked in 102751 n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked in 102751 n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1) blocked in 102751 n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-5 18 xtf/test-hvm32-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-2 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-2 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-2 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 18 xtf/test-hvm32-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-1 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-1 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-1 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-4 49 xtf/test-pv64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-4 51 xtf/test-pv64-pv-iopl~hypercall fail in 102751 never 
pass
 test-xtf-amd64-amd64-4 52 xtf/test-pv64-pv-iopl~vmassist fail in 102751 never 
pass
 test-xtf-amd64-amd64-5 27 xtf/test-hvm32pae-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-5 33 xtf/test-hvm32pse-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-5 37 xtf/test-hvm64-cpuid-faulting fail in 102751 never 
pass
 test-xtf-amd64-amd64-3 27 xtf/test-hvm32pae-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pse-cpuid-faulting fail in 102751 
never pass
 test-xtf-amd64-amd64-3 37 

[Xen-devel] [distros-debian-squeeze test] 68168: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
68128
 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 
68128
 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
68128
 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 68128

baseline version:
 flight   68128

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 00/13] xen/arm: Allow AArch32 guest to boot with GICv3

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Hi all,
> 
> Currently, it is only possible to start AArch32 guest with GICv2. This means
> that if the host interrupt controller is not compatible with GICv2, it will
> not be possible to boot AArch32 guest.
> 
> The vGICv3 code is nearly fully compatible with AArch32 guest except that
> co-processor access to ICC_SGI1R_EL1 is not emulated.
> 
> The first part (#1 - #11) of the series contains clean-up, only patch #12 and
> #13 contains the meat.
> 
> Note this is only allowing AArch32 guest to use GICv3 on AArch64 host. This
> series does not add support for GICv3 on AArch32 host.
> 
> A branch with all the patches can be found on xenbits:
> 
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch gicv3-32bit-v1

Nice and clean series. Only a couple of minor issues, I fixed them as I
applied the patches.

Thanks,

Stefano


> Regards,
> 
> Julien Grall (13):
>   xen/arm: vtimer: Switch the emulation functions return from int to
> bool
>   xen/arm: vtimer: Switch the read variable in the emulation from int to
> bool
>   xen/arm: traps: Switch from bool_t to bool
>   xen/arm: vgic: Switch from bool_t to bool
>   xen/arm: vgic: Switch vgic_to_sgi return from int to bool and progate
> up to...
>   xen/arm: vgic: Switch emulate_sysreg return from int to bool
>   xen/arm: vgic: Clean-up the sysreg emulation
>   xen/arm: vgic-v3: Build vgic-v3.c when CONFIG_HAS_GICV3 is enabled.
>   xen/arm: vtimer: Move emulate_sysreg* callback in a separate header
>   xen/arm: vreg: Introduce vreg_emulate_cp{32,64}
>   xen/arm: vgic: Rename emulate_sysreg callback to emulate_reg
>   xen/arm: vgic-v3: Move the emulation of ICC_SGI1R_EL1 in a separate
> helper
>   xen/arm: vgic-v3: Allow AArch32 guest booting with GICv3
> 
>  xen/arch/arm/Makefile|   2 +-
>  xen/arch/arm/traps.c |  42 +++--
>  xen/arch/arm/vgic-v2.c   |   4 +-
>  xen/arch/arm/vgic-v3.c   |  64 
>  xen/arch/arm/vgic.c  |  22 +++
>  xen/arch/arm/vtimer.c| 126 
> ---
>  xen/arch/arm/vtimer.h|   2 +-
>  xen/include/asm-arm/cpregs.h |   3 +
>  xen/include/asm-arm/perfc_defn.h |   2 +
>  xen/include/asm-arm/vgic.h   |  20 +++
>  xen/include/asm-arm/vreg.h   | 110 ++
>  11 files changed, 240 insertions(+), 157 deletions(-)
>  create mode 100644 xen/include/asm-arm/vreg.h
> 
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 13/13] xen/arm: vgic-v3: Allow AArch32 guest booting with GICv3

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> AArch32 guest will use co-processor registers to access the GICv3 (see
> 8.5 in IHI 0069C). Some of the registers have to be trapped and emulated
> (e.g ICC_SGI1R), this is the purpose of this patch.
> 
> The rest of the emulation already supports access required for AArch32
> so nothing has to be changed there.
> 
> Note this is only enabling 32-bit guest using GICv3 on Xen ARM64. Further
> work would be required to compile GICv3 and vGICv3 for Xen ARM32.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/traps.c | 12 
>  xen/arch/arm/vgic-v3.c   | 20 
>  xen/include/asm-arm/cpregs.h |  3 +++
>  xen/include/asm-arm/perfc_defn.h |  2 ++
>  4 files changed, 37 insertions(+)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 1fe02cb..eb85d92 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1876,6 +1876,18 @@ static void do_cp15_64(struct cpu_user_regs *regs,
>  break;
>  
>  /*
> + * HCR_EL2.FMO or HCR_EL2.IMO
> + *
> + * GIC Architecture Specification (IHI 0069C): Section 4.6.3
> + */
> +case HSR_CPREG64(ICC_SGI1R):
> +case HSR_CPREG64(ICC_ASGI1R):
> +case HSR_CPREG64(ICC_SGI0R):
> +if ( !vgic_emulate(regs, hsr) )
> +return inject_undef_exception(regs, hsr);
> +break;
> +
> +/*
>   * CPTR_EL2.T{0..9,12..13}
>   *
>   * ARMv7 (DDI 0406C.b): B1.14.12
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index f23135d..22c8ce0 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1335,12 +1335,32 @@ static bool vgic_v3_emulate_sysreg(struct 
> cpu_user_regs *regs, union hsr hsr)
>  }
>  }
>  
> +static bool vgic_v3_emulate_cp64(struct cpu_user_regs *regs, union hsr hsr)
> +{
> +struct hsr_cp64 cp64 = hsr.cp64;
> +
> +if ( cp64.read )
> +perfc_incr(vgic_cp64_reads);
> +else
> +perfc_incr(vgic_cp64_writes);
> +
> +switch ( hsr.bits & HSR_CP64_REGS_MASK )
> +{
> +case HSR_CPREG64(ICC_SGI1R):
> +return vreg_emulate_cp64(regs, hsr, vgic_v3_emulate_sgi1r);
> +default:
> +return false;
> +}
> +}
> +
>  static bool vgic_v3_emulate_reg(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  switch (hsr.ec)
>  {
>  case HSR_EC_SYSREG:
>  return vgic_v3_emulate_sysreg(regs, hsr);
> +case HSR_EC_CP15_64:
> +return vgic_v3_emulate_cp64(regs, hsr);
>  default:
>  return false;
>  }
> diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
> index e5cb00c..af45ec7 100644
> --- a/xen/include/asm-arm/cpregs.h
> +++ b/xen/include/asm-arm/cpregs.h
> @@ -246,6 +246,9 @@
>  /* CP15 CR11: DMA Operations for TCM Access */
>  
>  /* CP15 CR12:  */
> +#define ICC_SGI1R   p15,0,c12   /* Interrupt Controller SGI Group 1 
> */
> +#define ICC_ASGI1R  p15,1,c12   /* Interrupt Controller Alias SGI 
> Group 1 Register */
> +#define ICC_SGI0R   p15,2,c12   /* Interrupt Controller SGI Group 0 
> */
>  #define VBARp15,0,c12,c0,0  /* Vector Base Address Register */
>  #define HVBAR   p15,4,c12,c0,0  /* Hyp. Vector Base Address Register 
> */
>  
> diff --git a/xen/include/asm-arm/perfc_defn.h 
> b/xen/include/asm-arm/perfc_defn.h
> index 69fabe7..5f957ee 100644
> --- a/xen/include/asm-arm/perfc_defn.h
> +++ b/xen/include/asm-arm/perfc_defn.h
> @@ -38,6 +38,8 @@ PERFCOUNTER(vgicd_reads,"vgicd: read")
>  PERFCOUNTER(vgicd_writes,   "vgicd: write")
>  PERFCOUNTER(vgicr_reads,"vgicr: read")
>  PERFCOUNTER(vgicr_writes,   "vgicr: write")
> +PERFCOUNTER(vgic_cp64_reads,"vgic: cp64 read")
> +PERFCOUNTER(vgic_cp64_writes,   "vgic: cp64 write")
>  PERFCOUNTER(vgic_sysreg_reads,  "vgic: sysreg read")
>  PERFCOUNTER(vgic_sysreg_writes, "vgic: sysreg write")
>  PERFCOUNTER(vgic_sgi_list  ,"vgic: SGI send to list")
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 12/13] xen/arm: vgic-v3: Move the emulation of ICC_SGI1R_EL1 in a separate helper

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> The emulation of the co-processor register ICC_SGI1R is the same as the
> system register ICC_SGI1R_EL1. So move the emulation outside and use the
> newly introduced helper vreg_emulate_sysreg64 to abstract the access.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/vgic-v3.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index f3f0bd2..f23135d 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * PIDR2: Only bits[7:4] are not implementation defined. We are
> @@ -1300,9 +1301,21 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t 
> sgir)
>  return vgic_to_sgi(v, sgir, sgi_mode, virq, );
>  }
>  
> +static bool vgic_v3_emulate_sgi1r(struct cpu_user_regs *regs, uint64_t *r,
> +  bool read)
> +{
> +/* WO */
> +if ( !read )
> +return vgic_v3_to_sgi(current, *r);
> +else
> +{
> +gdprintk(XENLOG_WARNING, "Reading SGI1R_EL1 - WO register\n");
> +return false;
> +}
> +}
> +
>  static bool vgic_v3_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
>  {
> -struct vcpu *v = current;
>  struct hsr_sysreg sysreg = hsr.sysreg;
>  
>  ASSERT (hsr.ec == HSR_EC_SYSREG);
> @@ -1315,14 +1328,8 @@ static bool vgic_v3_emulate_sysreg(struct 
> cpu_user_regs *regs, union hsr hsr)
>  switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
>  {
>  case HSR_SYSREG_ICC_SGI1R_EL1:
> -/* WO */
> -if ( !sysreg.read )
> -return vgic_v3_to_sgi(v, get_user_reg(regs, sysreg.reg));
> -else
> -{
> -gprintk(XENLOG_WARNING, "Reading SGI1R_EL1 - WO register\n");
> -return false;
> -}
> +return vreg_emulate_sysreg64(regs, hsr, vgic_v3_emulate_sgi1r);
> +
>  default:
>  return false;
>  }
> -- 
> 1.9.1
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  779a0e15ca0d9d5dbcbdee29b1dad9faf73bfc77
baseline version:
 xen  395010f346356f0c9639af362a0300dc6d1242bf

Last test of basis   103037  2016-12-07 17:04:01 Z0 days
Testing same since   103045  2016-12-07 20:03:56 Z0 days1 attempts


People who touched revisions under test:
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

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

Re: [Xen-devel] [PATCH 11/13] xen/arm: vgic: Rename emulate_sysreg callback to emulate_reg

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> We will want to emulate co-processor registers access in a follow-up
> patch.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/vgic-v3.c | 13 -
>  xen/arch/arm/vgic.c|  4 ++--
>  xen/include/asm-arm/vgic.h |  4 ++--
>  3 files changed, 16 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index e54df0b..f3f0bd2 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1328,6 +1328,17 @@ static bool vgic_v3_emulate_sysreg(struct 
> cpu_user_regs *regs, union hsr hsr)
>  }
>  }
>  
> +static bool vgic_v3_emulate_reg(struct cpu_user_regs *regs, union hsr hsr)
> +{
> +switch (hsr.ec)
> +{
> +case HSR_EC_SYSREG:
> +return vgic_v3_emulate_sysreg(regs, hsr);
> +default:
> +return false;
> +}
> +}
> +
>  static const struct mmio_handler_ops vgic_rdistr_mmio_handler = {
>  .read  = vgic_v3_rdistr_mmio_read,
>  .write = vgic_v3_rdistr_mmio_write,
> @@ -1491,7 +1502,7 @@ static const struct vgic_ops v3_ops = {
>  .vcpu_init   = vgic_v3_vcpu_init,
>  .domain_init = vgic_v3_domain_init,
>  .domain_free = vgic_v3_domain_free,
> -.emulate_sysreg  = vgic_v3_emulate_sysreg,
> +.emulate_reg  = vgic_v3_emulate_reg,
>  /*
>   * We use both AFF1 and AFF0 in (v)MPIDR. Thus, the max number of CPU
>   * that can be supported is up to 4096(==256*16) in theory.
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 196e86b..364d5f0 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -550,9 +550,9 @@ bool vgic_emulate(struct cpu_user_regs *regs, union hsr 
> hsr)
>  {
>  struct vcpu *v = current;
>  
> -ASSERT(v->domain->arch.vgic.handler->emulate_sysreg != NULL);
> +ASSERT(v->domain->arch.vgic.handler->emulate_reg != NULL);
>  
> -return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
> +return v->domain->arch.vgic.handler->emulate_reg(regs, hsr);
>  }
>  
>  bool vgic_reserve_virq(struct domain *d, unsigned int virq)
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index fadb1e1..672f649 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -130,8 +130,8 @@ struct vgic_ops {
>  int (*domain_init)(struct domain *d);
>  /* Release resources that were allocated by domain_init */
>  void (*domain_free)(struct domain *d);
> -/* vGIC sysreg emulation */
> -bool (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr hsr);
> +/* vGIC sysreg/cpregs emulate */
> +bool (*emulate_reg)(struct cpu_user_regs *regs, union hsr hsr);
>  /* Maximum number of vCPU supported */
>  const unsigned int max_vcpus;
>  };
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 09/13] xen/arm: vtimer: Move emulate_sysreg* callback in a separate header

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> The core emulation of sysreg (reading/writing registers) is not specific
> to the virtual timer. Move the helpers in a new header vreg.h.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
> 
> The helpers will be necessary in a follow-up patch to emulate sysreg
> for another components.
> ---
>  xen/arch/arm/vtimer.c  | 53 ---
>  xen/include/asm-arm/vreg.h | 56 
> ++
>  2 files changed, 60 insertions(+), 49 deletions(-)
>  create mode 100644 xen/include/asm-arm/vreg.h
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 3fc97b3..091b5e7 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /*
> @@ -321,52 +322,6 @@ static bool vtimer_emulate_cp64(struct cpu_user_regs 
> *regs, union hsr hsr)
>  }
>  
>  #ifdef CONFIG_ARM_64
> -typedef bool (*vtimer_sysreg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> - bool read);
> -typedef bool (*vtimer_sysreg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> - bool read);
> -
> -static bool vtimer_emulate_sysreg32(struct cpu_user_regs *regs, union hsr 
> hsr,
> -vtimer_sysreg32_fn_t fn)
> -{
> -struct hsr_sysreg sysreg = hsr.sysreg;
> -uint32_t r = 0;
> -bool ret;
> -
> -if ( !sysreg.read )
> -r = get_user_reg(regs, sysreg.reg);
> -
> -ret = fn(regs, , sysreg.read);
> -
> -if ( ret && sysreg.read )
> -set_user_reg(regs, sysreg.reg, r);
> -
> -return ret;
> -}
> -
> -static bool vtimer_emulate_sysreg64(struct cpu_user_regs *regs, union hsr 
> hsr,
> -vtimer_sysreg64_fn_t fn)
> -{
> -struct hsr_sysreg sysreg = hsr.sysreg;
> -/*
> - * Initialize to zero to avoid leaking data if there is an
> - * implementation error in the emulation (such as not correctly
> - * setting x).
> - */
> -uint64_t x = 0;
> -bool ret;
> -
> -if ( !sysreg.read )
> -x = get_user_reg(regs, sysreg.reg);
> -
> -ret = fn(regs, , sysreg.read);
> -
> -if ( ret && sysreg.read )
> -set_user_reg(regs, sysreg.reg, x);
> -
> -return ret;
> -}
> -
>  static bool vtimer_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct hsr_sysreg sysreg = hsr.sysreg;
> @@ -379,11 +334,11 @@ static bool vtimer_emulate_sysreg(struct cpu_user_regs 
> *regs, union hsr hsr)
>  switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
>  {
>  case HSR_SYSREG_CNTP_CTL_EL0:
> -return vtimer_emulate_sysreg32(regs, hsr, vtimer_cntp_ctl);
> +return vreg_emulate_sysreg32(regs, hsr, vtimer_cntp_ctl);
>  case HSR_SYSREG_CNTP_TVAL_EL0:
> -return vtimer_emulate_sysreg32(regs, hsr, vtimer_cntp_tval);
> +return vreg_emulate_sysreg32(regs, hsr, vtimer_cntp_tval);
>  case HSR_SYSREG_CNTP_CVAL_EL0:
> -return vtimer_emulate_sysreg64(regs, hsr, vtimer_cntp_cval);
> +return vreg_emulate_sysreg64(regs, hsr, vtimer_cntp_cval);
>  
>  default:
>  return false;
> diff --git a/xen/include/asm-arm/vreg.h b/xen/include/asm-arm/vreg.h
> new file mode 100644
> index 000..2671f6e
> --- /dev/null
> +++ b/xen/include/asm-arm/vreg.h
> @@ -0,0 +1,56 @@
> +/*
> + * Helpers to emulate co-processor and system registers
> + */
> +#ifndef __ASM_ARM_VREG__
> +#define __ASM_ARM_VREG__
> +
> +#ifdef CONFIG_ARM_64
> +typedef bool (*vreg_sysreg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> +   bool read);
> +typedef bool (*vreg_sysreg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> +   bool read);
> +
> +static inline bool vreg_emulate_sysreg32(struct cpu_user_regs *regs, union 
> hsr hsr,
> + vreg_sysreg32_fn_t fn)
> +{
> +struct hsr_sysreg sysreg = hsr.sysreg;
> +uint32_t r = 0;
> +bool ret;
> +
> +if ( !sysreg.read )
> +r = get_user_reg(regs, sysreg.reg);
> +
> +ret = fn(regs, , sysreg.read);
> +
> +if ( ret && sysreg.read )
> +set_user_reg(regs, sysreg.reg, r);
> +
> +return ret;
> +}
> +
> +static inline bool vreg_emulate_sysreg64(struct cpu_user_regs *regs, union 
> hsr hsr,
> + vreg_sysreg64_fn_t fn)
> +{
> +struct hsr_sysreg sysreg = hsr.sysreg;
> +/*
> + * Initialize to zero to avoid leaking data if there is an
> + * implementation error in the emulation (such as not correctly
> + * setting x).
> + */
> +uint64_t x = 0;
> +bool ret;
> +
> +if ( !sysreg.read )
> +x = get_user_reg(regs, sysreg.reg);
> +
> +ret = fn(regs, , sysreg.read);
> +
> +if ( ret && 

Re: [Xen-devel] [PATCH 10/13] xen/arm: vreg: Introduce vreg_emulate_cp{32, 64}

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Factorize the code to emulate 32-bit and 64-bit access to a co-processor
> in specific helpers.
> 
> The new helpers will be used in different components to simplify the
> emulation.
> 
> Finally, the prototypes for the callbacks to emulate 32-bit and 64-bit
> co-processor access are the same as the sysreg one. Rather than
> introducing new ones, repurpose the existent prototypes.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/vtimer.c  | 37 +++
>  xen/include/asm-arm/vreg.h | 64 
> ++
>  2 files changed, 62 insertions(+), 39 deletions(-)
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 091b5e7..4ec3b95 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -252,49 +252,28 @@ static bool vtimer_cntp_cval(struct cpu_user_regs 
> *regs, uint64_t *r,
>  static bool vtimer_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct hsr_cp32 cp32 = hsr.cp32;
> -/*
> - * Initialize to zero to avoid leaking data if there is an
> - * implementation error in the emulation (such as not correctly
> - * setting r).
> - */
> -uint32_t r = 0;
> -bool res;
> -
>  
>  if ( cp32.read )
>  perfc_incr(vtimer_cp32_reads);
>  else
>  perfc_incr(vtimer_cp32_writes);
>  
> -if ( !cp32.read )
> -r = get_user_reg(regs, cp32.reg);
> -
>  switch ( hsr.bits & HSR_CP32_REGS_MASK )
>  {
>  case HSR_CPREG32(CNTP_CTL):
> -res = vtimer_cntp_ctl(regs, , cp32.read);
> -break;
> +return vreg_emulate_cp32(regs, hsr, vtimer_cntp_ctl);
>  
>  case HSR_CPREG32(CNTP_TVAL):
> -res = vtimer_cntp_tval(regs, , cp32.read);
> -break;
> +return vreg_emulate_cp32(regs, hsr, vtimer_cntp_tval);
>  
>  default:
>  return false;
>  }
> -
> -if ( res && cp32.read )
> -set_user_reg(regs, cp32.reg, r);
> -
> -return res;
>  }
>  
>  static bool vtimer_emulate_cp64(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct hsr_cp64 cp64 = hsr.cp64;
> -uint32_t r1 = get_user_reg(regs, cp64.reg1);
> -uint32_t r2 = get_user_reg(regs, cp64.reg2);
> -uint64_t x = (uint64_t)r1 | ((uint64_t)r2 << 32);
>  
>  if ( cp64.read )
>  perfc_incr(vtimer_cp64_reads);
> @@ -304,21 +283,11 @@ static bool vtimer_emulate_cp64(struct cpu_user_regs 
> *regs, union hsr hsr)
>  switch ( hsr.bits & HSR_CP64_REGS_MASK )
>  {
>  case HSR_CPREG64(CNTP_CVAL):
> -if ( !vtimer_cntp_cval(regs, , cp64.read) )
> -return false;
> -break;
> +return vreg_emulate_cp64(regs, hsr, vtimer_cntp_cval);
>  
>  default:
>  return false;
>  }
> -
> -if ( cp64.read )
> -{
> -set_user_reg(regs, cp64.reg1, x & 0x);
> -set_user_reg(regs, cp64.reg2, x >> 32);
> -}
> -
> -return true;
>  }
>  
>  #ifdef CONFIG_ARM_64
> diff --git a/xen/include/asm-arm/vreg.h b/xen/include/asm-arm/vreg.h
> index 2671f6e..ed2bd6f 100644
> --- a/xen/include/asm-arm/vreg.h
> +++ b/xen/include/asm-arm/vreg.h
> @@ -4,14 +4,68 @@
>  #ifndef __ASM_ARM_VREG__
>  #define __ASM_ARM_VREG__
>  
> -#ifdef CONFIG_ARM_64
> -typedef bool (*vreg_sysreg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> +typedef bool (*vreg_reg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> bool read);
> -typedef bool (*vreg_sysreg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> +typedef bool (*vreg_reg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> bool read);
>  
> +static inline bool vreg_emulate_cp32(struct cpu_user_regs *regs, union hsr 
> hsr,
> + vreg_reg32_fn_t fn)
> +{
> +struct hsr_cp32 cp32 = hsr.cp32;
> +/*
> + * Initialize to zero to avoid leaking data if there is an
> + * implementation error in the emulation (such as not correctly
> + * setting r).
> + */
> +uint32_t r = 0;
> +bool ret;
> +
> +if ( !cp32.read )
> +r = get_user_reg(regs, cp32.reg);
> +
> +ret = fn(regs, , cp32.read);
> +
> +if ( ret && cp32.read )
> +set_user_reg(regs, cp32.reg, r);
> +
> +return ret;
> +}
> +
> +static inline bool vreg_emulate_cp64(struct cpu_user_regs *regs, union hsr 
> hsr,
> + vreg_reg64_fn_t fn)
> +{
> +struct hsr_cp64 cp64 = hsr.cp64;
> +/*
> + * Initialize to zero to avoid leaking data if there is an
> + * implementation error in the emulation (such as not correctly
> + * setting x).
> + */
> +uint64_t x = 0;
> +bool ret;
> +
> +if ( !cp64.read )
> +{
> +uint32_t r1 = get_user_reg(regs, cp64.reg1);
> +uint32_t r2 = get_user_reg(regs, cp64.reg2);
> +

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 2c1cc12931b6c5a85471272799b3d4c249025a60
baseline version:
 ovmf 0db4acb61ac4e79a8a95b0e82874e8b6bed8e4bb

Last test of basis68162  2016-12-05 17:21:10 Z2 days
Testing same since68167  2016-12-07 07:47:05 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 
  Leif Lindholm 
  Liming Gao 
  Richard Thomaiyar 
  Star Zeng 
  Zeng, Star 

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



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

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

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


Push not applicable.


commit 2c1cc12931b6c5a85471272799b3d4c249025a60
Author: Leif Lindholm 
Date:   Thu Dec 1 15:13:33 2016 +

EmbeddedPkg: Remove use of IntelFrameworkModulePkg legacy libs

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move EmbeddedPkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Ard Biesheuvel 

commit 532e7cf44f8cf101f4c52dd9d9dd083ec0e1c1f2
Author: Leif Lindholm 
Date:   Thu Dec 1 15:11:44 2016 +

BeagleBoardPkg: Remove use of IntelFrameworkModulePkg legacy libs

LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.

Since the libraries are identical, move BeagleBoardPkg to use the
MdeModulePkg versions instead.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm 
Reviewed-by: Ard Biesheuvel 

commit bb34cc8c389a6c301b70984879eaa846fb12c9fe
Author: Liming Gao 
Date:   Thu Dec 1 14:30:18 2016 +0800

MdeModulePkg PiSmmCore: Update comments in InitializeMemoryServices

Add the comments to describe Free and Allocated SMRAM are added separately.

Cc: Star Zeng 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Jiewen Yao 

commit 60131098f302d9e449e95c53dec328aaf828076b
Author: Zeng, Star 
Date:   Mon Dec 5 10:52:45 2016 +0800

IntelFsp2Pkg: 41d739e breaks flat tree build

There may be no environment variable PACKAGES_PATH defined
in flat tree, then 41d739e breaks flat tree build.
This patch is to update GenCfgOpt.py to be compatible with
both flat tree and package path build.

Cc: Richard Thomaiyar 
Cc: Maurice Ma 
Cc: Jiewen Yao 
Cc: Giri P Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Jiewen Yao 
Reviewed-by: Richard Thomaiyar 
Tested-by: Richard Thomaiyar 

commit 3883e2cb52fa1582165d6558c67649835d0eada3
Author: Hao Wu 
Date:   Mon Nov 28 15:18:20 2016 +0800

BaseTools/VolInfo: Fix printf issue using '%ls' in 

Re: [Xen-devel] [PATCH 08/13] xen/arm: vgic-v3: Build vgic-v3.c when CONFIG_HAS_GICV3 is enabled.

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> The vGICv3 depends whether Xen has a host driver for GICv3, not on the
> architecture (AArch64 vs AArch32).
> 
> Note CONFIG_HAS_GICV3 is enabled only when for ARM64 build, so there is
> no functional change.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index f165178..59b3b53 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -43,7 +43,7 @@ obj-y += time.o
>  obj-y += traps.o
>  obj-y += vgic.o
>  obj-y += vgic-v2.o
> -obj-$(CONFIG_ARM_64) += vgic-v3.o
> +obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
>  obj-y += vm_event.o
>  obj-y += vtimer.o
>  obj-y += vpsci.o
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 07/13] xen/arm: vgic: Clean-up the sysreg emulation

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Couple of clean-up for the vgic sysreg emulation:
> - Reference the public documentation rather than a non-public one
> - Let the vgic emulation decides whether a register needs to be
> emulated
> - Drop unnecessary debug printk. They don't bring much information
> and can be misleading (vGICv2 does not support thoses registers)
> 
> Signed-off-by: Julien Grall 

Aside from a couple of typos in the commit message that I'll fix.

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/traps.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index fb07ae1..1fe02cb 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -2261,23 +2261,15 @@ static void do_sysreg(struct cpu_user_regs *regs,
>  /*
>   * HCR_EL2.FMO or HCR_EL2.IMO
>   *
> - * ARMv8: GIC Architecture Specification (PRD03-GENC-010745 24.0)
> - *Section 4.6.8.
> + * GIC Architecture Specification (IHI 0069C): Section 4.6.3
>   */
>  case HSR_SYSREG_ICC_SGI1R_EL1:
> +case HSR_SYSREG_ICC_ASGI1R_EL1:
> +case HSR_SYSREG_ICC_SGI0R_EL1:
> +
>  if ( !vgic_emulate(regs, hsr) )
> -{
> -dprintk(XENLOG_WARNING,
> -"failed emulation of sysreg ICC_SGI1R_EL1 access\n");
>  return inject_undef64_exception(regs, hsr.len);
> -}
>  break;
> -case HSR_SYSREG_ICC_SGI0R_EL1:
> -case HSR_SYSREG_ICC_ASGI1R_EL1:
> -/* TBD: Implement to support secure grp0/1 SGI forwarding */
> -dprintk(XENLOG_WARNING,
> -"Emulation of sysreg ICC_SGI0R_EL1/ASGI1R_EL1 not 
> supported\n");
> -return inject_undef64_exception(regs, hsr.len);
>  
>  /*
>   *  ICC_SRE_EL2.Enable = 0
> -- 
> 1.9.1
> 

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

[Xen-devel] [xen-4.5-testing test] 103007: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumprunbroken  in 102952
 build-i386-libvirtbroken  in 102952
 test-xtf-amd64-amd64-2   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-4   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-5   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-1   52 leak-check/check fail REGR. vs. 102721
 test-xtf-amd64-amd64-3   52 leak-check/check fail REGR. vs. 102721

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   9 debian-install   fail in 102952 pass in 103007
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail in 102952 pass in 103007
 test-armhf-armhf-xl-arndale  11 guest-startfail pass in 102952
 test-amd64-amd64-libvirt 17 guest-start/debian.repeat  fail pass in 102952

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail blocked in 
102721
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 102952 blocked in 
102721
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail in 
102952 like 102721
 test-amd64-amd64-xl-rtds  6 xen-boot fail  like 102721
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 102721
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 102721
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102721
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102721
 test-armhf-armhf-xl-rtds 11 guest-start  fail  like 102721

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked in 102952 n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked in 102952 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked in 102952 n/a
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 102952 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 102952 never 
pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-5   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 29 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 35 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   39 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-xtf-amd64-amd64-5   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-1   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-3   51 xtf/test-hvm64-xsa-195   fail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 

Re: [Xen-devel] [PATCH 05/13] xen/arm: vgic: Switch vgic_to_sgi return from int to bool and progate up to...

[Stefano Stabellini]

On Wed, 7 Dec 2016, Stefano Stabellini wrote:
> On Wed, 7 Dec 2016, Julien Grall wrote:
> > vgic_v{2,3}_to_sgi.
> > 
> > vgic_*to_sgi functions can only return 2 values: 0 or 1. Use bool instead
> > to make clear only two possible values exist.
> > 
> > Signed-off-by: Julien Grall 
> 
> Reviewed-by: Stefano Stabellini 

Actually, you missed one see below.


> > ---
> >  xen/arch/arm/vgic-v2.c | 4 ++--
> >  xen/arch/arm/vgic-v3.c | 2 +-
> >  xen/arch/arm/vgic.c| 8 
> >  xen/include/asm-arm/vgic.h | 6 +++---
> >  4 files changed, 10 insertions(+), 10 deletions(-)
> > 
> > diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> > index c6d280e..3dbcfe8 100644
> > --- a/xen/arch/arm/vgic-v2.c
> > +++ b/xen/arch/arm/vgic-v2.c
> > @@ -374,7 +374,7 @@ read_reserved:
> >  return 1;
> >  }
> >  
> > -static int vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
> > +static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
> >  {
> >  
> >  int virq;
> > @@ -403,7 +403,7 @@ static int vgic_v2_to_sgi(struct vcpu *v, register_t 
> > sgir)
> >  printk(XENLOG_G_DEBUG
> > "%pv: vGICD: unhandled GICD_SGIR write %"PRIregister" with 
> > wrong mode\n",
> > v, sgir);
> > -return 0;
> > +return false;
> >  }
> >  
> >  return vgic_to_sgi(v, sgir, sgi_mode, virq, );
> > diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> > index ec038a3..17c3000 100644
> > --- a/xen/arch/arm/vgic-v3.c
> > +++ b/xen/arch/arm/vgic-v3.c
> > @@ -1269,7 +1269,7 @@ write_reserved:
> >  return 1;
> >  }
> >  
> > -static int vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
> > +static bool vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
> >  {
> >  int virq;
> >  int irqmode;

You missed a 0 to false change here, if you don't mind, I'll do it.


> > diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> > index 84735a9..3e1774d 100644
> > --- a/xen/arch/arm/vgic.c
> > +++ b/xen/arch/arm/vgic.c
> > @@ -393,8 +393,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
> >  }
> >  }
> >  
> > -int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode 
> > irqmode, int virq,
> > -const struct sgi_target *target)
> > +bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode 
> > irqmode,
> > + int virq, const struct sgi_target *target)
> >  {
> >  struct domain *d = v->domain;
> >  int vcpuid;
> > @@ -440,10 +440,10 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
> > gic_sgi_mode irqmode, int
> >  gprintk(XENLOG_WARNING,
> >  "vGICD:unhandled GICD_SGIR write %"PRIregister" \
> >   with wrong mode\n", sgir);
> > -return 0;
> > +return false;
> >  }
> >  
> > -return 1;
> > +return true;
> >  }
> >  
> >  struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
> > diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> > index 1f371c8..83843fa 100644
> > --- a/xen/include/asm-arm/vgic.h
> > +++ b/xen/include/asm-arm/vgic.h
> > @@ -309,9 +309,9 @@ int vgic_v3_init(struct domain *d, int *mmio_count);
> >  
> >  extern int domain_vgic_register(struct domain *d, int *mmio_count);
> >  extern int vcpu_vgic_free(struct vcpu *v);
> > -extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
> > -   enum gic_sgi_mode irqmode, int virq,
> > -   const struct sgi_target *target);
> > +extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
> > +enum gic_sgi_mode irqmode, int virq,
> > +const struct sgi_target *target);
> >  extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned 
> > int irq);
> >  
> >  /* Reserve a specific guest vIRQ */
> > -- 
> > 1.9.1
> > 
> 

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

Re: [Xen-devel] [PATCH 06/13] xen/arm: vgic: Switch emulate_sysreg return from int to bool

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> emulate_sysreg callback can only return 2 values: 0 or 1. Use bool
> instead to make clear only two possible values exist.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/vgic-v3.c | 6 +++---
>  xen/arch/arm/vgic.c| 2 +-
>  xen/include/asm-arm/vgic.h | 4 ++--
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index 17c3000..e54df0b 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1300,7 +1300,7 @@ static bool vgic_v3_to_sgi(struct vcpu *v, register_t 
> sgir)
>  return vgic_to_sgi(v, sgir, sgi_mode, virq, );
>  }
>  
> -static int vgic_v3_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
> +static bool vgic_v3_emulate_sysreg(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct vcpu *v = current;
>  struct hsr_sysreg sysreg = hsr.sysreg;
> @@ -1321,10 +1321,10 @@ static int vgic_v3_emulate_sysreg(struct 
> cpu_user_regs *regs, union hsr hsr)
>  else
>  {
>  gprintk(XENLOG_WARNING, "Reading SGI1R_EL1 - WO register\n");
> -return 0;
> +return false;
>  }
>  default:
> -return 0;
> +return false;
>  }
>  }
>  
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 3e1774d..196e86b 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -546,7 +546,7 @@ void arch_evtchn_inject(struct vcpu *v)
>  vgic_vcpu_inject_irq(v, v->domain->arch.evtchn_irq);
>  }
>  
> -int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
> +bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct vcpu *v = current;
>  
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 83843fa..fadb1e1 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -131,7 +131,7 @@ struct vgic_ops {
>  /* Release resources that were allocated by domain_init */
>  void (*domain_free)(struct domain *d);
>  /* vGIC sysreg emulation */
> -int (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr hsr);
> +bool (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr hsr);
>  /* Maximum number of vCPU supported */
>  const unsigned int max_vcpus;
>  };
> @@ -300,7 +300,7 @@ extern struct pending_irq *irq_to_pending(struct vcpu *v, 
> unsigned int irq);
>  extern struct pending_irq *spi_to_pending(struct domain *d, unsigned int 
> irq);
>  extern struct vgic_irq_rank *vgic_rank_offset(struct vcpu *v, int b, int n, 
> int s);
>  extern struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, unsigned int irq);
> -extern int vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
> +extern bool vgic_emulate(struct cpu_user_regs *regs, union hsr hsr);
>  extern void vgic_disable_irqs(struct vcpu *v, uint32_t r, int n);
>  extern void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n);
>  extern void register_vgic_ops(struct domain *d, const struct vgic_ops *ops);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 05/13] xen/arm: vgic: Switch vgic_to_sgi return from int to bool and progate up to...

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> vgic_v{2,3}_to_sgi.
> 
> vgic_*to_sgi functions can only return 2 values: 0 or 1. Use bool instead
> to make clear only two possible values exist.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/vgic-v2.c | 4 ++--
>  xen/arch/arm/vgic-v3.c | 2 +-
>  xen/arch/arm/vgic.c| 8 
>  xen/include/asm-arm/vgic.h | 6 +++---
>  4 files changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> index c6d280e..3dbcfe8 100644
> --- a/xen/arch/arm/vgic-v2.c
> +++ b/xen/arch/arm/vgic-v2.c
> @@ -374,7 +374,7 @@ read_reserved:
>  return 1;
>  }
>  
> -static int vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
> +static bool vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
>  {
>  
>  int virq;
> @@ -403,7 +403,7 @@ static int vgic_v2_to_sgi(struct vcpu *v, register_t sgir)
>  printk(XENLOG_G_DEBUG
> "%pv: vGICD: unhandled GICD_SGIR write %"PRIregister" with 
> wrong mode\n",
> v, sgir);
> -return 0;
> +return false;
>  }
>  
>  return vgic_to_sgi(v, sgir, sgi_mode, virq, );
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index ec038a3..17c3000 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -1269,7 +1269,7 @@ write_reserved:
>  return 1;
>  }
>  
> -static int vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
> +static bool vgic_v3_to_sgi(struct vcpu *v, register_t sgir)
>  {
>  int virq;
>  int irqmode;
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 84735a9..3e1774d 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -393,8 +393,8 @@ void vgic_enable_irqs(struct vcpu *v, uint32_t r, int n)
>  }
>  }
>  
> -int vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode, 
> int virq,
> -const struct sgi_target *target)
> +bool vgic_to_sgi(struct vcpu *v, register_t sgir, enum gic_sgi_mode irqmode,
> + int virq, const struct sgi_target *target)
>  {
>  struct domain *d = v->domain;
>  int vcpuid;
> @@ -440,10 +440,10 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
> gic_sgi_mode irqmode, int
>  gprintk(XENLOG_WARNING,
>  "vGICD:unhandled GICD_SGIR write %"PRIregister" \
>   with wrong mode\n", sgir);
> -return 0;
> +return false;
>  }
>  
> -return 1;
> +return true;
>  }
>  
>  struct pending_irq *irq_to_pending(struct vcpu *v, unsigned int irq)
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 1f371c8..83843fa 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -309,9 +309,9 @@ int vgic_v3_init(struct domain *d, int *mmio_count);
>  
>  extern int domain_vgic_register(struct domain *d, int *mmio_count);
>  extern int vcpu_vgic_free(struct vcpu *v);
> -extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
> -   enum gic_sgi_mode irqmode, int virq,
> -   const struct sgi_target *target);
> +extern bool vgic_to_sgi(struct vcpu *v, register_t sgir,
> +enum gic_sgi_mode irqmode, int virq,
> +const struct sgi_target *target);
>  extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned 
> int irq);
>  
>  /* Reserve a specific guest vIRQ */
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 04/13] xen/arm: vgic: Switch from bool_t to bool

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Since commit 9202342 "xen/build: Use C99 booleans", bool_t is an alias
> to bool. Going forward, therer is a preference to use bool rather than
> bool_t. Also replace 0 and 1 by false and true when relevant.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/vgic.c| 8 
>  xen/include/asm-arm/vgic.h | 8 
>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
> index 0965119..84735a9 100644
> --- a/xen/arch/arm/vgic.c
> +++ b/xen/arch/arm/vgic.c
> @@ -482,7 +482,7 @@ void vgic_vcpu_inject_irq(struct vcpu *v, unsigned int 
> virq)
>  uint8_t priority;
>  struct pending_irq *iter, *n = irq_to_pending(v, virq);
>  unsigned long flags;
> -bool_t running;
> +bool running;
>  
>  priority = vgic_get_virq_priority(v, virq);
>  
> @@ -555,15 +555,15 @@ int vgic_emulate(struct cpu_user_regs *regs, union hsr 
> hsr)
>  return v->domain->arch.vgic.handler->emulate_sysreg(regs, hsr);
>  }
>  
> -bool_t vgic_reserve_virq(struct domain *d, unsigned int virq)
> +bool vgic_reserve_virq(struct domain *d, unsigned int virq)
>  {
>  if ( virq >= vgic_num_irqs(d) )
> -return 0;
> +return false;
>  
>  return !test_and_set_bit(virq, d->arch.vgic.allocated_irqs);
>  }
>  
> -int vgic_allocate_virq(struct domain *d, bool_t spi)
> +int vgic_allocate_virq(struct domain *d, bool spi)
>  {
>  int first, end;
>  unsigned int virq;
> diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
> index 300f461..1f371c8 100644
> --- a/xen/include/asm-arm/vgic.h
> +++ b/xen/include/asm-arm/vgic.h
> @@ -315,23 +315,23 @@ extern int vgic_to_sgi(struct vcpu *v, register_t sgir,
>  extern void vgic_migrate_irq(struct vcpu *old, struct vcpu *new, unsigned 
> int irq);
>  
>  /* Reserve a specific guest vIRQ */
> -extern bool_t vgic_reserve_virq(struct domain *d, unsigned int virq);
> +extern bool vgic_reserve_virq(struct domain *d, unsigned int virq);
>  
>  /*
>   * Allocate a guest VIRQ
>   *  - spi == 0 => allocate a PPI. It will be the same on every vCPU
>   *  - spi == 1 => allocate an SPI
>   */
> -extern int vgic_allocate_virq(struct domain *d, bool_t spi);
> +extern int vgic_allocate_virq(struct domain *d, bool spi);
>  
>  static inline int vgic_allocate_ppi(struct domain *d)
>  {
> -return vgic_allocate_virq(d, 0 /* ppi */);
> +return vgic_allocate_virq(d, false /* ppi */);
>  }
>  
>  static inline int vgic_allocate_spi(struct domain *d)
>  {
> -return vgic_allocate_virq(d, 1 /* spi */);
> +return vgic_allocate_virq(d, true /* spi */);
>  }
>  
>  extern void vgic_free_virq(struct domain *d, unsigned int virq);
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 03/13] xen/arm: traps: Switch from bool_t to bool

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Since commit 9202342 "xen/build: Use C99 booleans", bool_t is an alias
> to bool. Going forward, there is a preference to use bool rather than
> bool_t. Also replace 0 and 1 by true and false when relevant.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/traps.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index ae921d7..fb07ae1 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -154,13 +154,13 @@ static void print_xen_info(void)
>  }
>  
>  #ifdef CONFIG_ARM_32
> -static inline bool_t is_zero_register(int reg)
> +static inline bool is_zero_register(int reg)
>  {
>  /* There is no zero register for ARM32 */
> -return 0;
> +return false;
>  }
>  #else
> -static inline bool_t is_zero_register(int reg)
> +static inline bool is_zero_register(int reg)
>  {
>  /*
>   * For store/load and sysreg instruction, the encoding 31 always
> @@ -1500,7 +1500,7 @@ static void do_trap_hypercall(struct cpu_user_regs 
> *regs, register_t *nr,
>  #endif
>  }
>  
> -static bool_t check_multicall_32bit_clean(struct multicall_entry *multi)
> +static bool check_multicall_32bit_clean(struct multicall_entry *multi)
>  {
>  int i;
>  
> @@ -1661,7 +1661,7 @@ static void advance_pc(struct cpu_user_regs *regs, 
> const union hsr hsr)
>  /* Read as zero and write ignore */
>  static void handle_raz_wi(struct cpu_user_regs *regs,
>int regidx,
> -  bool_t read,
> +  bool read,
>const union hsr hsr,
>int min_el)
>  {
> @@ -1680,7 +1680,7 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
>  /* Write only as write ignore */
>  static void handle_wo_wi(struct cpu_user_regs *regs,
>   int regidx,
> - bool_t read,
> + bool read,
>   const union hsr hsr,
>   int min_el)
>  {
> @@ -1699,7 +1699,7 @@ static void handle_wo_wi(struct cpu_user_regs *regs,
>  /* Read only as read as zero */
>  static void handle_ro_raz(struct cpu_user_regs *regs,
>int regidx,
> -  bool_t read,
> +  bool read,
>const union hsr hsr,
>int min_el)
>  {
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 02/13] xen/arm: vtimer: Switch the read variable in the emulation from int to bool

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> The read variable can only take two values: 1 => read, 0 => write. Use
> bool instead to make clear the variable can only take 2 values.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/vtimer.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index f8d3295..3fc97b3 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -164,7 +164,7 @@ int virt_timer_restore(struct vcpu *v)
>  return 0;
>  }
>  
> -static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, int 
> read)
> +static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, bool 
> read)
>  {
>  struct vcpu *v = current;
>  
> @@ -193,7 +193,8 @@ static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, 
> uint32_t *r, int read)
>  return true;
>  }
>  
> -static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, int 
> read)
> +static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r,
> + bool read)
>  {
>  struct vcpu *v = current;
>  s_time_t now;
> @@ -221,7 +222,8 @@ static bool vtimer_cntp_tval(struct cpu_user_regs *regs, 
> uint32_t *r, int read)
>  return true;
>  }
>  
> -static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, int 
> read)
> +static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r,
> + bool read)
>  {
>  struct vcpu *v = current;
>  
> @@ -320,9 +322,9 @@ static bool vtimer_emulate_cp64(struct cpu_user_regs 
> *regs, union hsr hsr)
>  
>  #ifdef CONFIG_ARM_64
>  typedef bool (*vtimer_sysreg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> - int read);
> + bool read);
>  typedef bool (*vtimer_sysreg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> - int read);
> + bool read);
>  
>  static bool vtimer_emulate_sysreg32(struct cpu_user_regs *regs, union hsr 
> hsr,
>  vtimer_sysreg32_fn_t fn)
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] [PATCH 01/13] xen/arm: vtimer: Switch the emulation functions return from int to bool

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> The emulation functions are always returning 0 or 1. Use bool instead to
> make clear only two possible values exist.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


>  xen/arch/arm/vtimer.c | 60 
> +--
>  xen/arch/arm/vtimer.h |  2 +-
>  2 files changed, 31 insertions(+), 31 deletions(-)
> 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index f636705..f8d3295 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -164,12 +164,12 @@ int virt_timer_restore(struct vcpu *v)
>  return 0;
>  }
>  
> -static int vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, int read)
> +static bool vtimer_cntp_ctl(struct cpu_user_regs *regs, uint32_t *r, int 
> read)
>  {
>  struct vcpu *v = current;
>  
>  if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
> -return 0;
> +return false;
>  
>  if ( read )
>  {
> @@ -190,16 +190,16 @@ static int vtimer_cntp_ctl(struct cpu_user_regs *regs, 
> uint32_t *r, int read)
>  else
>  stop_timer(>arch.phys_timer.timer);
>  }
> -return 1;
> +return true;
>  }
>  
> -static int vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, int 
> read)
> +static bool vtimer_cntp_tval(struct cpu_user_regs *regs, uint32_t *r, int 
> read)
>  {
>  struct vcpu *v = current;
>  s_time_t now;
>  
>  if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
> -return 0;
> +return false;
>  
>  now = NOW() - v->domain->arch.phys_timer_base.offset;
>  
> @@ -218,15 +218,15 @@ static int vtimer_cntp_tval(struct cpu_user_regs *regs, 
> uint32_t *r, int read)
>v->domain->arch.phys_timer_base.offset);
>  }
>  }
> -return 1;
> +return true;
>  }
>  
> -static int vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, int 
> read)
> +static bool vtimer_cntp_cval(struct cpu_user_regs *regs, uint64_t *r, int 
> read)
>  {
>  struct vcpu *v = current;
>  
>  if ( !ACCESS_ALLOWED(regs, EL0PTEN) )
> -return 0;
> +return false;
>  
>  if ( read )
>  {
> @@ -243,10 +243,10 @@ static int vtimer_cntp_cval(struct cpu_user_regs *regs, 
> uint64_t *r, int read)
>v->domain->arch.phys_timer_base.offset);
>  }
>  }
> -return 1;
> +return true;
>  }
>  
> -static int vtimer_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr)
> +static bool vtimer_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct hsr_cp32 cp32 = hsr.cp32;
>  /*
> @@ -255,7 +255,7 @@ static int vtimer_emulate_cp32(struct cpu_user_regs 
> *regs, union hsr hsr)
>   * setting r).
>   */
>  uint32_t r = 0;
> -int res;
> +bool res;
>  
>  
>  if ( cp32.read )
> @@ -277,7 +277,7 @@ static int vtimer_emulate_cp32(struct cpu_user_regs 
> *regs, union hsr hsr)
>  break;
>  
>  default:
> -return 0;
> +return false;
>  }
>  
>  if ( res && cp32.read )
> @@ -286,7 +286,7 @@ static int vtimer_emulate_cp32(struct cpu_user_regs 
> *regs, union hsr hsr)
>  return res;
>  }
>  
> -static int vtimer_emulate_cp64(struct cpu_user_regs *regs, union hsr hsr)
> +static bool vtimer_emulate_cp64(struct cpu_user_regs *regs, union hsr hsr)
>  {
>  struct hsr_cp64 cp64 = hsr.cp64;
>  uint32_t r1 = get_user_reg(regs, cp64.reg1);
> @@ -302,11 +302,11 @@ static int vtimer_emulate_cp64(struct cpu_user_regs 
> *regs, union hsr hsr)
>  {
>  case HSR_CPREG64(CNTP_CVAL):
>  if ( !vtimer_cntp_cval(regs, , cp64.read) )
> -return 0;
> +return false;
>  break;
>  
>  default:
> -return 0;
> +return false;
>  }
>  
>  if ( cp64.read )
> @@ -315,21 +315,21 @@ static int vtimer_emulate_cp64(struct cpu_user_regs 
> *regs, union hsr hsr)
>  set_user_reg(regs, cp64.reg2, x >> 32);
>  }
>  
> -return 1;
> +return true;
>  }
>  
>  #ifdef CONFIG_ARM_64
> -typedef int (*vtimer_sysreg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> -int read);
> -typedef int (*vtimer_sysreg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> -int read);
> +typedef bool (*vtimer_sysreg32_fn_t)(struct cpu_user_regs *regs, uint32_t *r,
> + int read);
> +typedef bool (*vtimer_sysreg64_fn_t)(struct cpu_user_regs *regs, uint64_t *r,
> + int read);
>  
> -static int vtimer_emulate_sysreg32(struct cpu_user_regs *regs, union hsr hsr,
> -   vtimer_sysreg32_fn_t fn)
> +static bool vtimer_emulate_sysreg32(struct cpu_user_regs *regs, union hsr 
> hsr,
> +vtimer_sysreg32_fn_t fn)
>  {
>  struct hsr_sysreg sysreg = hsr.sysreg;
>  uint32_t r 

Re: [Xen-devel] [PATCH] arm/xen: Use alloc_percpu rather than __alloc_percpu

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> The function xen_guest_init is using __alloc_percpu with an alignment
> which are not power of two.
> 
> However, the percpu allocator never supported alignments which are not power
> of two and has always behaved incorectly in thise case.
> 
> Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
> introduced a check which trigger a warning [1] when booting linux-next
> on Xen. But in fine this bug was always present.
> 
> This can be fixed by replacing the call to __alloc_percpu with
> alloc_percpu. The latter will use an alignment which are a power of two.
> 
> [1]
> 
> [0.023921] illegal size (48) or align (48) for percpu allocation
> [0.024167] [ cut here ]
> [0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 
> pcpu_alloc+0x88/0x6c0
> [0.024584] Modules linked in:
> [0.024708]
> [0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.9.0-rc7-next-20161128 #473
> [0.025012] Hardware name: Foundation-v8A (DT)
> [0.025162] task: 80003d87 task.stack: 80003d844000
> [0.025351] PC is at pcpu_alloc+0x88/0x6c0
> [0.025490] LR is at pcpu_alloc+0x88/0x6c0
> [0.025624] pc : [] lr : []
> pstate: 6045
> [0.025830] sp : 80003d847cd0
> [0.025946] x29: 80003d847cd0 x28: 
> [0.026147] x27:  x26: 
> [0.026348] x25:  x24: 
> [0.026549] x23:  x22: 024000c0
> [0.026752] x21: 08e97000 x20: 
> [0.026953] x19: 0030 x18: 0010
> [0.027155] x17: 0a3f x16: deadbeef
> [0.027357] x15: 0006 x14: 88f79c3f
> [0.027573] x13: 08f79c4d x12: 0041
> [0.027782] x11: 0006 x10: 0042
> [0.027995] x9 : 80003d847a40 x8 : 6f697461636f6c6c
> [0.028208] x7 : 6120757063726570 x6 : 08f79c84
> [0.028419] x5 : 0005 x4 : 
> [0.028628] x3 :  x2 : 017f
> [0.028840] x1 : 80003d87 x0 : 0035
> [0.029056]
> [0.029152] ---[ end trace  ]---
> [0.029297] Call trace:
> [0.029403] Exception stack(0x80003d847b00 to
>0x80003d847c30)
> [0.029621] 7b00: 0030 0001
> 80003d847cd0 0818e678
> [0.029901] 7b20: 0002 0004
> 08f7c060 0035
> [0.030153] 7b40: 08f79000 08c4cd88
> 80003d847bf0 08101778
> [0.030402] 7b60: 0030 
> 08e97000 024000c0
> [0.030647] 7b80:  
>  
> [0.030895] 7ba0: 0035 80003d87
> 017f 
> [0.031144] 7bc0:  0005
> 08f79c84 6120757063726570
> [0.031394] 7be0: 6f697461636f6c6c 80003d847a40
> 0042 0006
> [0.031643] 7c00: 0041 08f79c4d
> 88f79c3f 0006
> [0.031877] 7c20: deadbeef 0a3f
> [0.032051] [] pcpu_alloc+0x88/0x6c0
> [0.032229] [] __alloc_percpu+0x18/0x20
> [0.032409] [] xen_guest_init+0x174/0x2f4
> [0.032591] [] do_one_initcall+0x38/0x130
> [0.032783] [] kernel_init_freeable+0xe0/0x248
> [0.032995] [] kernel_init+0x10/0x100
> [0.033172] [] ret_from_fork+0x10/0x50
> 
> Reported-by: Wei Chen 
> Link: https://lkml.org/lkml/2016/11/28/669
> Signed-off-by: Julien Grall 
> 
> Cc: sta...@vger.kernel.org
> 
> ---
> 
> I have requested backport to stable because the percpu allocator may
> misbehaves when the alignment is not a power of two.

Reviewed-by: Stefano Stabellini 

I'll fix a small wording issue in the commit message and apply to
xentip.


>  arch/arm/xen/enlighten.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index f193414..4986dc0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -372,8 +372,7 @@ static int __init xen_guest_init(void)
>* for secondary CPUs as they are brought up.
>* For uniformity we use VCPUOP_register_vcpu_info even on cpu0.
>*/
> - xen_vcpu_info = __alloc_percpu(sizeof(struct vcpu_info),
> -sizeof(struct vcpu_info));
> + xen_vcpu_info = alloc_percpu(struct vcpu_info);
>   if (xen_vcpu_info == NULL)
>   return -ENOMEM;
>  
> -- 
> 1.9.1
> 

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

Re: [Xen-devel] PV Autotranslate guests (are they used at all?)

[Konrad Rzeszutek Wilk]

On Wed, Dec 07, 2016 at 08:37:29PM +, Andrew Cooper wrote:
> Hello,
> 
> While digging around, it looks like there is some major bitrot of the PV
> autotranslate code.
> 
> When constructing an autotranslate domain, tools/libxc/xc_dom_x86.c:
> x86_shadow() sets refcount | translate on the domain.
> 
> The combination of translate != external was excluded by c/s
> 92942fd3d469, which means that PV autotranslate guests can't boot on Xen
> 4.7 or later.
> 
> The shadow emulation code for PV guests (which gets used one way or
> another if any of refcount|translate|external are set) always sets up
> emulation in the same mode as Xen's %cs.  It appears to have had this
> behaviour since its introduction in c/s 1daf5e293b, and presumably means
> that noone has tried running a 32bit autotranslate guest on 64bit Xen in
> anger.
> 
> Does anyone use PV autotranslate guests at all?  I don't believe I have
> never come across one.

I ran it once I thing for fun. Just to see if dom0 could run. But that
was in .. Xen 4.1 days?

> 
> The current shadow code excludes the translate without refcounts case,
> but the converse case (refcounts without translate) doesn't make sense. 
> Without Xen performing translation, there are no shadow tables to
> reference count in the first place.
> 
> This means that the only sensible shadow mode is refcount | translate |
> external, which allows PV emulation code in arch/x86/mm/shadow/ to be
> dropped, as PV guests necessarily can't be external.  Doing so however
> would definitely be the end of autotranslate mode.
> 
> Given that it hasn't booted on the past two releases of Xen, and doesn't
> appear to have ever worked in one common case, does anyone have any
> objection if I remove all vestigial pieces and permanently lay the
> feature to rest in SCM history?

No objection.




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

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

[Xen-devel] PV Autotranslate guests (are they used at all?)

[Andrew Cooper]

Hello,

While digging around, it looks like there is some major bitrot of the PV
autotranslate code.

When constructing an autotranslate domain, tools/libxc/xc_dom_x86.c:
x86_shadow() sets refcount | translate on the domain.

The combination of translate != external was excluded by c/s
92942fd3d469, which means that PV autotranslate guests can't boot on Xen
4.7 or later.

The shadow emulation code for PV guests (which gets used one way or
another if any of refcount|translate|external are set) always sets up
emulation in the same mode as Xen's %cs.  It appears to have had this
behaviour since its introduction in c/s 1daf5e293b, and presumably means
that noone has tried running a 32bit autotranslate guest on 64bit Xen in
anger.

Does anyone use PV autotranslate guests at all?  I don't believe I have
never come across one.

The current shadow code excludes the translate without refcounts case,
but the converse case (refcounts without translate) doesn't make sense. 
Without Xen performing translation, there are no shadow tables to
reference count in the first place.

This means that the only sensible shadow mode is refcount | translate |
external, which allows PV emulation code in arch/x86/mm/shadow/ to be
dropped, as PV guests necessarily can't be external.  Doing so however
would definitely be the end of autotranslate mode.

Given that it hasn't booted on the past two releases of Xen, and doesn't
appear to have ever worked in one common case, does anyone have any
objection if I remove all vestigial pieces and permanently lay the
feature to rest in SCM history?

~Andrew

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

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Stefano Stabellini]

On Tue, 6 Dec 2016, Dario Faggioli wrote:
> On Tue, 2016-12-06 at 13:53 -0800, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Dario Faggioli wrote:
> > > Sorry if I can't be more useful than this for now. :-/
> > 
> > We don't need scheduler support to implement interrupt migration. The
> > question was much simpler than that: moving a vCPU with interrupts
> > assigned to it is slower than moving a vCPU without interrupts
> > assigned
> > to it. You could say that the slowness is directly proportional do
> > the
> > number of interrupts assigned to the vCPU. Does the scheduler know
> > that?
> > Or blindly moves vCPUs around? Also see below.
> > 
> Ah, ok, it is indeed a simpler question than I thought! :-)
> 
> Answer: no, the scheduler does not use the information of how many or
> what interrupts are being routed to a vCPU in any way.
> 
> Just for the sake of correctness and precision, it does not "blindly
> moves vCPUs around", as in, it follows some criteria for deciding
> whether or not to move a vCPU, and if yes, where to, but among those
> criteria, there is no trace of anything related to routed interrupts.
> 
> Let me also add that the criteria are scheduler specific, so they're
> different, e.g., between Credit and Credit2.
> 
> Starting considering routed interrupt as a migration criteria in Credit
> would be rather difficult. Credit use a 'best effort' approach for
> migrating vCPUs, which is hard to augment.
> 
> Starting considering routed interrupt as a migration criteria in
> Credit2 would be much easier. Credit2's load balancer is specifically
> designed for being extendible with things like that. It would require
> some thinking, though, in order to figure out how important this
> particular aspect would be, wrt others that are considered.
> 
> E.g., if I have pCPU 0 loaded at 75% and pCPU 1 loaded at 25%, vCPU A
> has a lot of routed interrupts, and moving it gives me perfect load
> balancing (i.e., load will become 50% on pCPU 0 and 50% on pCPU 1)
> should I move it or not?
> Well, it depends if whether or not we think that the overhead we save
> by not migrating outweights the benefit of a perfectly balanced system.

Right. I don't know where to draw the line. I don't how much weight it
should have, but certainly it shouldn't be considered the same thing as
moving any other vCPU.

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

Re: [Xen-devel] [RFC PATCH 21/24] ARM: vITS: handle INVALL command

[Stefano Stabellini]

On Tue, 6 Dec 2016, Julien Grall wrote:
> On 06/12/2016 22:01, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Stefano Stabellini wrote:
> > > moving a vCPU with interrupts assigned to it is slower than moving a
> > > vCPU without interrupts assigned to it. You could say that the
> > > slowness is directly proportional do the number of interrupts assigned
> > > to the vCPU.
> > 
> > To be pedantic, by "assigned" I mean that a physical interrupt is routed
> > to a given pCPU and is set to be forwarded to a guest vCPU running on it
> > by the _IRQ_GUEST flag. The guest could be dom0. Upon receiving one of
> > these physical interrupts, a corresponding virtual interrupt (could be a
> > different irq) will be injected into the guest vCPU.
> > 
> > When the vCPU is migrated to a new pCPU, the physical interrupts that
> > are configured to be injected as virtual interrupts into the vCPU, are
> > migrated with it. The physical interrupt migration has a cost. However,
> > receiving physical interrupts on the wrong pCPU has an higher cost.
> 
> I don't understand why it is a problem for you to receive the first interrupt
> to the wrong pCPU and moving it if necessary.
> 
> While this may have an higher cost (I don't believe so) on the first received
> interrupt, migrating thousands of interrupts at the same time is very
> expensive and will likely get Xen stuck for a while (think about ITS with a
> single command queue).
> 
> Furthermore, the current approach will move every single interrupt routed a
> the vCPU, even those disabled. That's pointless and a waste of resource. You
> may argue that we can skip the ones disabled, but in that case what would be
> the benefits to migrate the IRQs while migrate the vCPUs?
>
> So I would suggest to spread it over the time. This also means less headache
> for the scheduler developers.

The most important aspect of interrupts handling in Xen is latency,
measured as the time between Xen receiving a physical interrupt and the
guest receiving it. This latency should be both small and deterministic.

We all agree so far, right?


The issue with spreading interrupts migrations over time is that it makes
interrupt latency less deterministic. It is OK, in the uncommon case of
vCPU migration with interrupts, to take a hit for a short time. This
"hit" can be measured. It can be known. If your workload cannot tolerate
it, vCPUs can be pinned. It should be a rare event anyway. On the other
hand, by spreading interrupts migrations, we make it harder to predict
latency. Aside from determinism, another problem with this approach is
that it ensures that every interrupt assigned to a vCPU will first hit
the wrong pCPU, then it will be moved. It guarantees the worst-case
scenario for interrupt latency for the vCPU that has been moved. If we
migrated all interrupts as soon as possible, we would minimize the
amount of interrupts delivered to the wrong pCPU. Most interrupts would
be delivered to the new pCPU right away, reducing interrupt latency.

Regardless of how we implement interrupts migrations on ARM, I think it
still makes sense for the scheduler to know about it. I realize that
this is a separate point. Even if we spread interrupts migrations over
time, it still has a cost, in terms of latency as I wrote above, but also
in terms of interactions with interrupt controllers and ITSes. A vCPU
with no interrupts assigned to it poses no such problems. The scheduler
should be aware of the difference. If the scheduler knew, I bet that
vCPU migration would be a rare event for vCPUs that have many interrupts
assigned to them. For example, Dom0 vCPU0 would never be moved, and
dom0_pin_vcpus would be superfluous.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  395010f346356f0c9639af362a0300dc6d1242bf
baseline version:
 xen  f33b4fc4efc11a45184a8a368bd3a6bdb6b01dd0

Last test of basis   103027  2016-12-07 12:54:38 Z0 days
Testing same since   103037  2016-12-07 17:04:01 Z0 days1 attempts


People who touched revisions under test:
  Daniel Kiper 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Roger Pau Monné 
  Tamas K Lengyel 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

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

[Xen-devel] Issue while bringing up libvirtd.service

[Praveen Kumar]

Hi,

I am new in Xen environment and trying to get VMs running with the build
xen code base.

But, am facing issue bringing up the libvirt deamon. I have installed
latest unstable xen ( 4.9 ).
There seems to be a conflict in library version and because of which I am
getting below error :
...
Dec 08 00:44:43 kpraveen.labs.blr.novell.com libvirtd[14603]: Unable to
configure libxl's memory management parameters
Dec 08 00:44:43 kpraveen.labs.blr.novell.com libvirtd[14603]:
Initialization of LIBXL state driver failed: no error
Dec 08 00:44:43 kpraveen.labs.blr.novell.com libvirtd[14603]: Driver state
initialization failed
...

The problem is resolved when I remove libvirt-daemon-driver-libxl, but that
seems to be removing libvirt package also and causing below error during
vm-install :

Dec 08 00:41:59 kpraveen.labs.blr.novell.com libvirtd[7005]: no connection
driver available for xen:///
Dec 08 00:41:59 kpraveen.labs.blr.novell.com libvirtd[7005]: End of file
while reading data: Input/output error


I found that we have xen-libs of different version which is 4.7, but don't
know if that is the root cause and how to upgrade that. As suggested, I
have also rebuild xen tree and tried reinstalling, but the issue persists.

Any guidance will be very much helpful to resolve this problem . Also,
wanted to know, what others follow as best practices when there is a
version change or if hit the similar problem.
Just FYI, I am following
https://wiki.xenproject.org/wiki/Compiling_Xen_From_Source link for
compiling and installing xen.

Thanks in advance.

Regards,

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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Juergen Gross]

On 07/12/16 17:28, Jan Beulich wrote:
 On 07.12.16 at 17:18,  wrote:
>> On 07/12/16 17:10, Sven Köhler wrote:
>>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
 On 28/09/16 01:33, Sven Köhler wrote:
> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
>> On 27/09/16 14:09, Sven Köhler wrote:
>>> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
 On 27/09/16 13:13, Sven Köhler wrote:
> Am 27.09.2016 um 07:31 schrieb Juergen Gross:
>> On 27/09/16 00:48, Sven Köhler wrote:
>>> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
 On 25/09/16 18:04, Sven Köhler wrote:
> Hi,
>
> I'm experiencing the bug below which was discussed on xen-devel 
> December
> last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on 
> Gentoo.
>
> The bug only seems to occur with the last domU booted on my 
> machine.
> Where do I find a patch that fixes that?

 The issue back in December was fixed by commit
 c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 
 4.7.
 Either gentoo didn't update to the official Xen 4.7 release 
 (including
 pvgrub) or you are seeing a new issue.
>>>
>>> From the looks of it, the Gentoo package is using the grub from the
>>> xen-4.7.0 tarball.
>>>
>>> I downgraded to pvgrub 4.6.3 and the problem went away.
>>>
>>> So I assume I'm seeing a new issue. How do I debug it?
>>
>> Interesting. Just tested it on upstream Xen and saw the same problem
>> with a rather old guest kernel (3.0 based, xen flavor), while a newer
>> kernel (4.1, pvops) is working.
>>
>> Can you give me some more details about the kernel you are trying to
>> boot?
>
> It's an unmodified 4.4.21 kernel which I compile by hand. The config 
> is
> attached. Does that help?

 Not really. OTOH I think I don't need more help, as I've found a 
 problem
 in pvgrub. I have a patch which seems to correct the issue. Are you 
 fine
 with me adding you as the original reporter of the problem in the 
 patch?
>>>
>>> Yes, I'm fine with adding me as the reporter.
>>> Do you want me to test the patch first?
>>
>> Sure. The attached patch is for Xen upstream, but I think it should
>> apply to Xen 4.7, too.
>
> This patch solved the issue for me. My domU boots fine again after
> recompiling pvgrub with the patch applied.
>
> Thanks!

 Thank you for the test!
>>>
>>> It seems this patch was not included in 4.7.1. That's a shame, cause I
>>> ran into the same issue after upgrading to 4.7.1.
>>
>> Right. Jan, could you please include the patch for 4.7.2? Upstream
>> commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.
> 
> Samuel, could you confirm that this is okay to backport. In
> which case the question then is whether 4.6.5 should get it
> too - with p2m_seg mentioned no-where else under stubdom/
> I can't really tell where this is coming from.

4.6 is not affected.


Juergen


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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Juergen Gross]

On 07/12/16 17:33, Jan Beulich wrote:
 On 07.12.16 at 17:10,  wrote:
>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>>> On 28/09/16 01:33, Sven Köhler wrote:
 Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>>> On 27/09/16 13:13, Sven Köhler wrote:
 Am 27.09.2016 um 07:31 schrieb Juergen Gross:
> On 27/09/16 00:48, Sven Köhler wrote:
>> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>>> On 25/09/16 18:04, Sven Köhler wrote:
 Hi,

 I'm experiencing the bug below which was discussed on xen-devel 
 December
 last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on 
 Gentoo.

 The bug only seems to occur with the last domU booted on my 
 machine.
 Where do I find a patch that fixes that?
>>>
>>> The issue back in December was fixed by commit
>>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 
>>> 4.7.
>>> Either gentoo didn't update to the official Xen 4.7 release 
>>> (including
>>> pvgrub) or you are seeing a new issue.
>>
>> From the looks of it, the Gentoo package is using the grub from the
>> xen-4.7.0 tarball.
>>
>> I downgraded to pvgrub 4.6.3 and the problem went away.
>>
>> So I assume I'm seeing a new issue. How do I debug it?
>
> Interesting. Just tested it on upstream Xen and saw the same problem
> with a rather old guest kernel (3.0 based, xen flavor), while a newer
> kernel (4.1, pvops) is working.
>
> Can you give me some more details about the kernel you are trying to
> boot?

 It's an unmodified 4.4.21 kernel which I compile by hand. The config is
 attached. Does that help?
>>>
>>> Not really. OTOH I think I don't need more help, as I've found a problem
>>> in pvgrub. I have a patch which seems to correct the issue. Are you fine
>>> with me adding you as the original reporter of the problem in the patch?
>>
>> Yes, I'm fine with adding me as the reporter.
>> Do you want me to test the patch first?
>
> Sure. The attached patch is for Xen upstream, but I think it should
> apply to Xen 4.7, too.

 This patch solved the issue for me. My domU boots fine again after
 recompiling pvgrub with the patch applied.

 Thanks!
>>>
>>> Thank you for the test!
>>
>> It seems this patch was not included in 4.7.1. That's a shame, cause I
>> ran into the same issue after upgrading to 4.7.1.
> 
> I don't think anyone requested its inclusion - that process is in no
> way automatic.

I mentioned it in the patch. See
https://lists.xen.org/archives/html/xen-devel/2016-09/msg02993.html


Juergen

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

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Dario Faggioli]

On Wed, 2016-12-07 at 19:38 +0100, Dario Faggioli wrote:
>  [DOC RFC] Heterogeneous Multi Processing Support in Xen
>  <1481135379.3445.142.ca...@citrix.com>
> 
> (I wanted to post a link to the message in the archives, but I'm not
> seeing it there yet... oh, well.)
>
It appeared:

https://lists.xen.org/archives/html/xen-devel/2016-12/msg00826.html

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

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

Re: [Xen-devel] [PATCH v2] xen/arm: fix smpboot barriers

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 07/12/2016 19:02, Stefano Stabellini wrote:
> > Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
> > _online_map), which is not synchronizing against anything.
> > 
> > Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
> > that all writes before setting the cpu online are visible to other cpus.
> > For that to work properly, we need a corresponding smp_rmb() barrier,
> > after reading the online cpumask from other processors, which is
> > currently missing. Add it.
> > 
> > See: http://marc.info/?l=xen-devel=148093236307211
> > 
> > Signed-off-by: Stefano Stabellini 
> 
> With some minor coding styles change:
> 
> Reviewed-by: Julien Grall 
> 
> Also, I am wondering whether we should backport this patch? Technically the
> barrier are wrong.

It is true that the missing smp_rmb() could cause problems. However this
is the kind of patch that would be better left stirring in staging for a
few weeks before backporting.


> > ---
> > 
> > Changes in v2:
> > - add in-code comments
> > 
> > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > index 90ad1d0..4570f45 100644
> > --- a/xen/arch/arm/smpboot.c
> > +++ b/xen/arch/arm/smpboot.c
> > @@ -307,11 +307,12 @@ void start_secondary(unsigned long boot_phys_offset,
> > 
> >  /* Run local notifiers */
> >  notify_cpu_starting(cpuid);
> > +/* Ensure that previous writes are visible before marking the cpu as
> > + * online. */
> 
> It looks like smpboot.c is using different style for comment. However, the
> correct one is
> 
> /*
>  * Ensure...
>  * ...
>  */
> 
> >  smp_wmb();
> > 
> >  /* Now report this CPU is up */
> >  cpumask_set_cpu(cpuid, _online_map);
> > -smp_wmb();
> > 
> >  local_irq_enable();
> >  local_abort_enable();
> > @@ -408,6 +409,9 @@ int __cpu_up(unsigned int cpu)
> >  cpu_relax();
> >  process_pending_softirqs();
> >  }
> > +/* Ensure that other cpus' initializations are visible before
> > + * proceeding. Corresponds to smp_wmb() in start_secondary. */
> 
> Ditto.
> 
> > +smp_rmb();
> > 
> >  /*
> >   * Nuke start of day info before checking one last time if the CPU
> > 
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v2] xen/arm: fix smpboot barriers

[Julien Grall]

Hi Stefano,

On 07/12/2016 19:02, Stefano Stabellini wrote:

Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
_online_map), which is not synchronizing against anything.

Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
that all writes before setting the cpu online are visible to other cpus.
For that to work properly, we need a corresponding smp_rmb() barrier,
after reading the online cpumask from other processors, which is
currently missing. Add it.

See: http://marc.info/?l=xen-devel=148093236307211

Signed-off-by: Stefano Stabellini 


With some minor coding styles change:

Reviewed-by: Julien Grall 

Also, I am wondering whether we should backport this patch? Technically 
the barrier are wrong.




---

Changes in v2:
- add in-code comments

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 90ad1d0..4570f45 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -307,11 +307,12 @@ void start_secondary(unsigned long boot_phys_offset,

 /* Run local notifiers */
 notify_cpu_starting(cpuid);
+/* Ensure that previous writes are visible before marking the cpu as
+ * online. */


It looks like smpboot.c is using different style for comment. However, 
the correct one is


/*
 * Ensure...
 * ...
 */


 smp_wmb();

 /* Now report this CPU is up */
 cpumask_set_cpu(cpuid, _online_map);
-smp_wmb();

 local_irq_enable();
 local_abort_enable();
@@ -408,6 +409,9 @@ int __cpu_up(unsigned int cpu)
 cpu_relax();
 process_pending_softirqs();
 }
+/* Ensure that other cpus' initializations are visible before
+ * proceeding. Corresponds to smp_wmb() in start_secondary. */


Ditto.


+smp_rmb();

 /*
  * Nuke start of day info before checking one last time if the CPU



--
Julien Grall

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

[Xen-devel] [PATCH v2] xen/arm: fix smpboot barriers

[Stefano Stabellini]

Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
_online_map), which is not synchronizing against anything.

Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
that all writes before setting the cpu online are visible to other cpus.
For that to work properly, we need a corresponding smp_rmb() barrier,
after reading the online cpumask from other processors, which is
currently missing. Add it.

See: http://marc.info/?l=xen-devel=148093236307211

Signed-off-by: Stefano Stabellini 

---

Changes in v2:
- add in-code comments

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 90ad1d0..4570f45 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -307,11 +307,12 @@ void start_secondary(unsigned long boot_phys_offset,
 
 /* Run local notifiers */
 notify_cpu_starting(cpuid);
+/* Ensure that previous writes are visible before marking the cpu as
+ * online. */
 smp_wmb();
 
 /* Now report this CPU is up */
 cpumask_set_cpu(cpuid, _online_map);
-smp_wmb();
 
 local_irq_enable();
 local_abort_enable();
@@ -408,6 +409,9 @@ int __cpu_up(unsigned int cpu)
 cpu_relax();
 process_pending_softirqs();
 }
+/* Ensure that other cpus' initializations are visible before
+ * proceeding. Corresponds to smp_wmb() in start_secondary. */
+smp_rmb();
 
 /*
  * Nuke start of day info before checking one last time if the CPU

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

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

[Julien Grall]

On 07/12/2016 18:44, Stefano Stabellini wrote:

On Wed, 7 Dec 2016, Julien Grall wrote:
Andrew thinks that (on x86) there is actually nothing that CPU0 will be
looking at, that has been set by CPU1. However looking at the code it is
difficult to verify. There are many cpu notifiers and many things
written by start_secondary. I would prefer to submit this patch, and be
safe.


I agree on this. Better be safe than hunting a bug later on.

Although, I think I just found an example for ARM. The gic_cpu_id (see 
gic-v2.c) is stored per-cpu and initialized by each CPU at boot.


gic_cpu_id is commonly used to send a SGI to a specific target. So we 
need to ensure that CPU0 will see this value before sending an SGI (see 
gicv2_send_SGI). Otherwise the SGI may go to the wild.


While you are sending a patch, can you document in the code why the 
barrier is present?


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] xen/arm: fix smpboot barriers

[Stefano Stabellini]

Remove useless smp_wmb() barrier after cpumask_set_cpu(cpuid,
_online_map), which is not synchronizing against anything.

Keep the other smp_wmb(), before the cpumask_set_cpu call, to ensure
that all writes before setting the cpu online are visible to other cpus.
For that to work properly, we need a corresponding smp_rmb() barrier,
after reading the online cpumask from other processors, which is
currently missing. Add it.

See: http://marc.info/?l=xen-devel=148093236307211

Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 90ad1d0..c841a15 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -311,7 +311,6 @@ void start_secondary(unsigned long boot_phys_offset,
 
 /* Now report this CPU is up */
 cpumask_set_cpu(cpuid, _online_map);
-smp_wmb();
 
 local_irq_enable();
 local_abort_enable();
@@ -408,6 +407,7 @@ int __cpu_up(unsigned int cpu)
 cpu_relax();
 process_pending_softirqs();
 }
+smp_rmb();
 
 /*
  * Nuke start of day info before checking one last time if the CPU

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

Re: [Xen-devel] [PATCH] xen/physmap: Propagate error rc from xenmem_add_to_physmap_one

[Jiandi An]

On 12/07/16 05:43, Jan Beulich wrote:
 On 07.12.16 at 02:07,  wrote:
>> On 07/12/2016 01:00, Jiandi An wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -762,6 +762,8 @@ static int xenmem_add_to_physmap_batch(struct domain *d,
>>>  rc = xenmem_add_to_physmap_one(d, xatpb->space,
>>> xatpb->u,
>>> idx, _gfn(gpfn));
>>> +if ( rc < 0 )
>>> +goto out;
>>>  
>>>  if ( unlikely(__copy_to_guest_offset(xatpb->errs, 0, , 1)) )
>>>  {
>>
>> This can't be correct.  You now skip writing rc into the errs[] array on
>> a failure, which means that userspace will get an overall failure but an
>> errs[] array which said that nothing went wrong.
>>
>> This code addition looks like it wants to be an "else if" on the end of
>> this if() in context.
> 
> Why would this go elsewhere? It's unneeded - it's a property of the
> hypercall that when seeing overall success you still need to look at
> errs[].
> 
> Jan
> 

I realized the issue is on the guest side errs[] is not being checked
after the heypercall.  Will fix on the guest side.

-- 
Jiandi An
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

[Stefano Stabellini]

On Wed, 7 Dec 2016, Julien Grall wrote:
> Hi Stefano,
> 
> On 06/12/2016 20:32, Stefano Stabellini wrote:
> > On Tue, 6 Dec 2016, Stefano Stabellini wrote:
> > > On Tue, 6 Dec 2016, Andrew Cooper wrote:
> > > > On 05/12/2016 19:17, Stefano Stabellini wrote:
> > > > > On Mon, 5 Dec 2016, Andrew Cooper wrote:
> > > > > > None of these barriers serve any purpose, as they are not
> > > > > > synchronising with
> > > > > > any anything on remote CPUs.
> > > > > > 
> > > > > > Signed-off-by: Andrew Cooper 
> > > > > > ---
> > > > > > CC: Jan Beulich 
> > > > > > CC: Stefano Stabellini 
> > > > > > CC: Julien Grall 
> > > > > > 
> > > > > > Restricting to just the $ARCH maintainers, as this is a project-wide
> > > > > > sweep.
> > > > > > 
> > > > > > Julien/Stefano: I think the ARM smpboot inhereted the erronious
> > > > > > barrier usage
> > > > > > from x86, but I don't know whether further development has gained a
> > > > > > dependence
> > > > > > on them.
> > > > > We turned them into smp_wmb already (kudos to IanC).
> > > > 
> > > > Right, but the entire point I am trying to argue is that they are not
> > > > needed in the first place.
> > 
> > Just to be clear, on ARM the barriers are unneeded only if it is
> > unimportant that "init stuff" (which correspond to all the
> > initialization done in start_secondary up to smp_wmb) below is completed
> > before "write cpu_online_map". But it looks like we do want to complete
> > mmu, irq, timer initializations and set the current vcpu before marking
> > the cpu as online, right?
> 
> *mb are memory barriers. This would not prevent write to system registers and
> co-processor registers happening before "write cpu_online_map". Only an
> dsb(sy); isb() would ensure this.
> 
> However, I don't think we really care about the state of the hardware for a
> specific CPU. This should never be accessed by another one.
> 
> > 
> > > This is the current code:
> > > 
> > > CPU 1  CPU 0
> > > -  -
> > > 
> > > init stuff read cpu_online_map
> > > 
> > > write barrier
> > > 
> > > write cpu_online_map   do more initialization
> > > 
> > > write barrier
> > > 
> > > init more stuff
> > > 
> > > 
> > > I agree that it's wrong, because the second write barrier in
> > > start_secondary is useless and in addition we are missing a read barrier
> > > in __cpu_up, corresponding to the first write barrier in
> > > start_secondary.
> > > 
> > > I think it should look like:
> > > 
> > > 
> > > CPU 1  CPU 0
> > > -  -
> > > 
> > > init stuff read cpu_online_map
> > > 
> > > write barrier  read barrier
> > > 
> > > write cpu_online_map   do more initialization
> > > 
> > > init more stuff
> > > 
> > > 
> > > The patch is as follow.
> > > 
> > > Julien, what do you think?
> > > 
> > > Also, do we need to change the remaming smp_wmb() in start_secondary to
> > > wmb() to ensure execution ordering as well as memory access ordering?
> 
> I don't think so. If synchronization of hardware access was necessary it would
> have been taken care by the driver itself.

I thought the same, thanks for confirming.


> What we should care here is if there any xen internal state that are required
> between CPU0 and CPU1.
> 
> In this specific case, I think we should have the smp_wmb() barrier to ensure
> all write happening whilst calling local notifiers will be visible before the
> CPU mark itself as online. So IHMO, the patch looks good to me (see a small
> comment below).

Andrew thinks that (on x86) there is actually nothing that CPU0 will be
looking at, that has been set by CPU1. However looking at the code it is
difficult to verify. There are many cpu notifiers and many things
written by start_secondary. I would prefer to submit this patch, and be
safe.


> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > 
> > > diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> > > index 90ad1d0..c841a15 100644
> > > --- a/xen/arch/arm/smpboot.c
> > > +++ b/xen/arch/arm/smpboot.c
> > > @@ -311,7 +311,6 @@ void start_secondary(unsigned long boot_phys_offset,
> > > 
> > >  /* Now report this CPU is up */
> > >  cpumask_set_cpu(cpuid, _online_map);
> > > -smp_wmb();
> > > 
> > >  local_irq_enable();
> > >  local_abort_enable();
> > > @@ -408,6 +407,7 @@ int __cpu_up(unsigned int cpu)
> > >  cpu_relax();
> > >  process_pending_softirqs();
> > >  }
> > > +smp_rmb();
> 
> It would be good to start annotating the pair of barrier with "This barrier
> corresponds with the one in...". It would avoid "wild" barrier in the code :).
> 
> > > 
> > >  

Re: [Xen-devel] Xen ARM community call - meeting minutes and date for the next one

[Dario Faggioli]

On Tue, 2016-12-06 at 13:48 +, Julien Grall wrote:
> === big.LITTLE ===
> 
> Anastassios:interested in knowing the status of big.LITTLE
> support in Xen
> Dario:  went through the thread on the ML. The consensus
> seems to be
> based on vcpu pin/affinity.
> Anastassios:There are issue the way xen handles boot code. Wrong
> errata
> for cpus.
> Julien: Core could have different errata and features. Errata
> already
> works today.
> We need a summary of the discussion.
> 
> Dario stepped in to write a summary.
> 
> Anastassios:What is the best board to work big.LITTLE with Xen?
> 
> ?:  Renesas
> 
> ACTION: Dario to write a summary of the big.LITTLE discussions.
> 
Here it is. I took the chance and wrote it as a design / feature
document, but it still has some TODO, for things that were either not
clear or not fully agreed upon in the thread.

 [DOC RFC] Heterogeneous Multi Processing Support in Xen
 <1481135379.3445.142.ca...@citrix.com>

(I wanted to post a link to the message in the archives, but I'm not
seeing it there yet... oh, well.)

Hope this helps. :-)

Regards,
Dario

> === Secure Call Monitor (SMC) from guests ===
> 
> Andrii/Artem:   EPAM is working on allowing a guest to make call to
> TEE (e.g
> OPTEE). They are working in collaboration with Linaro
> to
> make OPTEE  virtualization aware. A design document
> has been
> posted on the ML (see [3]).
> Edgar:  interested on this. Trusted world need to be accessed
> to
> manage FPGA and for power management
> 
> === Running unmodified baremetal software in a guest ===
> 
> Edgar:  Xilinx is working on running unmodified baremetal
> software
> in a guest. Piece of work required:
> - Mapping memory area with different memory
> attribut
>   to domU
> - Replicate host memory map
> - Exposing a vUART to guest (see [4] for the
> discussion)
> Steward:vUART is very important, especially for baremetal
> guests
> Stefano:it would need to be loggable
> Julien: we would have the same issue in the future to be
> compliant
> with the VM Spec (see [5]).
> 
> === Areas of concern ===
> 
> Bosch: problem with xen-swiotlb. It does not work properly on renesas
> board.
> Stefano: please report the error on the ML
> 
> ACTION: Bosch to send a bug report regarding xen-swiotlb
> 
> Edgar:  IOMMU could not be used by the guest (Stage-1). This would be
> useful
> to implement driver in userspace.
> Julien: When will it be required?
> Edgar:  It is a trend
> 
> Julien: Should we organized another Community Call? When?
> Artem: Once per month is a good start
> 
> All: Agreed on a call before Christmas
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2016-10/msg0
> 1966.html
> [2] https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg0
> 1802.html
> [3] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg0
> 2220.html
> [4] https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg0
> 0846.html
> [5] http://people.linaro.org/~christoffer.dall/VMSystemSpecificationF
> orARM-v2.0.pdf
> 
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

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

Re: [Xen-devel] [PATCH 2/4] xen/x86: Drop erronious barriers

[Julien Grall]

Hi Stefano,

On 06/12/2016 20:32, Stefano Stabellini wrote:

On Tue, 6 Dec 2016, Stefano Stabellini wrote:

On Tue, 6 Dec 2016, Andrew Cooper wrote:

On 05/12/2016 19:17, Stefano Stabellini wrote:

On Mon, 5 Dec 2016, Andrew Cooper wrote:

None of these barriers serve any purpose, as they are not synchronising with
any anything on remote CPUs.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 

Restricting to just the $ARCH maintainers, as this is a project-wide sweep.

Julien/Stefano: I think the ARM smpboot inhereted the erronious barrier usage
from x86, but I don't know whether further development has gained a dependence
on them.

We turned them into smp_wmb already (kudos to IanC).


Right, but the entire point I am trying to argue is that they are not
needed in the first place.


Just to be clear, on ARM the barriers are unneeded only if it is
unimportant that "init stuff" (which correspond to all the
initialization done in start_secondary up to smp_wmb) below is completed
before "write cpu_online_map". But it looks like we do want to complete
mmu, irq, timer initializations and set the current vcpu before marking
the cpu as online, right?


*mb are memory barriers. This would not prevent write to system 
registers and co-processor registers happening before "write 
cpu_online_map". Only an dsb(sy); isb() would ensure this.


However, I don't think we really care about the state of the hardware 
for a specific CPU. This should never be accessed by another one.





This is the current code:

CPU 1  CPU 0
-  -

init stuff read cpu_online_map

write barrier

write cpu_online_map   do more initialization

write barrier

init more stuff


I agree that it's wrong, because the second write barrier in
start_secondary is useless and in addition we are missing a read barrier
in __cpu_up, corresponding to the first write barrier in
start_secondary.

I think it should look like:


CPU 1  CPU 0
-  -

init stuff read cpu_online_map

write barrier  read barrier

write cpu_online_map   do more initialization

init more stuff


The patch is as follow.

Julien, what do you think?

Also, do we need to change the remaming smp_wmb() in start_secondary to
wmb() to ensure execution ordering as well as memory access ordering?


I don't think so. If synchronization of hardware access was necessary it 
would have been taken care by the driver itself.


What we should care here is if there any xen internal state that are 
required between CPU0 and CPU1.


In this specific case, I think we should have the smp_wmb() barrier to 
ensure all write happening whilst calling local notifiers will be 
visible before the CPU mark itself as online. So IHMO, the patch looks 
good to me (see a small comment below).




Signed-off-by: Stefano Stabellini 

diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 90ad1d0..c841a15 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -311,7 +311,6 @@ void start_secondary(unsigned long boot_phys_offset,

 /* Now report this CPU is up */
 cpumask_set_cpu(cpuid, _online_map);
-smp_wmb();

 local_irq_enable();
 local_abort_enable();
@@ -408,6 +407,7 @@ int __cpu_up(unsigned int cpu)
 cpu_relax();
 process_pending_softirqs();
 }
+smp_rmb();


It would be good to start annotating the pair of barrier with "This 
barrier corresponds with the one in...". It would avoid "wild" barrier 
in the code :).




 /*
  * Nuke start of day info before checking one last time if the CPU



Regards,

--
Julien Grall

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

[Xen-devel] [DOC RFC] Heterogeneous Multi Processing Support in Xen

[Dario Faggioli]

% Heterogeneous Multi Processing Support in Xen
% Revision 1

\clearpage

# Basics

 
 Status: **Design Document**

Architecture(s): x86, arm

   Component(s): Hypervisor and toolstack
 

# Overview

HMP (Heterogeneous Multi Processing) and AMP (Asymmetric Multi Processing)
refer to systems where physical CPUs are not exactly equal. It may be that
they have different processing power, or capabilities, or that each is
specifically designed to run a particular system component.
Most of the times the CPUs have different Instruction Set Architectures (ISA)
or Application Binary Interfaces (ABIs). But they may *just* be different
implementations of the same ISA, in which case they typically differ in
speed, power efficiency or handling of special things (e.g., erratas).

An example is ARM big.LITTLE, which in fact, is the use case that got the
discussion about HMP started. This document, however, is generic, and does
not target only big.LITTLE.

What need proper Xen support are systems and use cases where virtual CPUs
can not be seamlessly moved around all the physical CPUs. In fact, in these
cases, there must be a way to:

* decide and specify on what (set of) physical CPU(s), each vCPU can execute on;
* enforce that a vCPU that can only run on a certain (set of) pCPUs, is never
  actually run anywhere else.

**N.B.:** it is becoming common to refer as AMP or HMP also to systems which
have various kind of co-processors (from crypto engines to graphic hardware),
integrated with the CPUs on the same chip. This is not what this design 
document is about.

# Classes of CPUs

A *class of CPUs* is defined as follows:

1. each pCPU in the system belongs to a class;
2. a class can consist of one or more pCPUs;
3. each pCPU can only be in one class;
4. CPUs belonging to the same class are homogeneous enough that a virtual
   CPU that blocks/is preempted while running on a pCPU of a class can,
   **seamlessly**, unblock/be scheduler on any pCPU of that same class;
5. when a virtual CPU is associated with a (set of) class(es) of CPUs, it
   means that the vCPU can run on all the pCPUs belonging to the said
   class(es).

So, for instance, in architecture Foobar two classes of CPUs exist, class
foo and class bar. If a virtual CPU running on a CPU 0, which is of class
foo, blocks (or is preempted), it can, when it unblocks (or is selected by
the scheduler to run  again), run on CPU 3, still of class foo, but not on
CPU 6, which is of class bar.

## Defining classes

How a class is defined, i.e., what are the specific characteristics that
determine what CPUs belong to which class, is highly architecture specific.

### x86

There is no HMP platform of relevance, for now, in x86 world. Therefore,
only one class will exist, and all the CPUs will be set to belong to it.
**TODO X86:** is this correct?

### ARM

**TODO ARM:** I know nothing about what specifically should be used to
form classes, so I'm deferring this to ARM people.

So far, in the original thread the following ideas came up (well, there's
more, but I don't know enough of ARM to judge what is really relevant about
this topic):

* 
[Julien](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02153.html)
  "I don't think an hardcoded list of processor in Xen is the right solution.
   There are many existing processors and combinations for big.LITTLE so it
   will nearly be impossible to keep updated."
* 
[Julien](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02256.html)
  "Well, before trying to do something clever like that (i.e naming "big" and
  "little"), we need to have upstreamed bindings available to acknowledge the
  difference. AFAICT, it is not yet upstreamed for Device Tree and I don't
  know any static ACPI tables providing the similar information."
* 
[Peng](https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg02194.html)
  "For how to differentiate cpus, I am looking the linaro eas cpu topology code"

# User details

## Classes of CPUs for the users

It will be possible, in a VM config file, to specify the (set of) class(es)
of each vCPU. This allows creating HMP VMs.

E.g., on ARM, it will be possible to create big.LITTLE VMs which, if run on
big.LITTLE hosts, could leverage the big.LITTLE support of the guest OS kernel
and tools.

For such purpose, a new option will be added to xl config file:

vcpus = "8"
vcpuclass = ["0-2:class0", "3,4:class1,class3", "5:class0, class2", 
"8:class4"]

with the following meaning:

* vCPUs 0, 1, 2 can only run on pcpus of class class0
* vCPUs 3, 4 can run on pcpus of class class1 **and** on pcpus of class class3
* vCPUs 5 can run on pcpus of class class0 **and** on pCPUs of class class2
* for vCPUs 7, since they're not mentioned, default applies
* vCPUs 8 can only run on pcpus of class class4

For the vCPUs for which no class is specified, default behavior applies.

**TODO:** note 

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 00/13] multiboot2: Update documentation

[Daniel Kiper]

On Wed, Dec 07, 2016 at 09:34:30AM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 07, 2016 at 12:26:19PM +0100, Daniel Kiper wrote:
> > On Tue, Dec 06, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On December 6, 2016 5:52:48 PM EST, Daniel Kiper 
> > >  wrote:
> > > >Hi,
> > > >
> > > >This updated patch series adds description of the Multiboot2 protocol
> > > >new
> > > >features and fixes some issues found here and there.
> > > >
> > > >It applies to multiboot2 branch in GRUB2 git tree.
> > >
> > > Why not the master one?
> >
> > Because doc lives in multiboot2 branch. I am going to
> > move it to master after 2.02 and then...
> >
> > > >Here is short list of changes since v2:
> > > >  - new patches: 01, 02,
> > > >  - changed patches: 07.
> > > >
> > >
> > > How about the rename of the file? Or would it make sense
> > > to do that in some other followup patches?
> >
> > ...rename relevant files.
>
> I only had one question on #7, otherwise feel free to stick
> Reviewed-by: Konrad Rzeszutek Wilk 

Thanks a lot!

> Thank you for documenting this!

You are welcome!

Daniel

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

Re: [Xen-devel] [MULTIBOOT2 DOC PATCH v3 07/13] multiboot2: Add description of support for EFI boot services

[Daniel Kiper]

On Wed, Dec 07, 2016 at 09:33:55AM -0500, Konrad Rzeszutek Wilk wrote:
> ..snip..
> > --- a/doc/multiboot.texi
> > +++ b/doc/multiboot.texi
> > @@ -528,6 +528,66 @@ The physical address to which the boot loader should 
> > jump in order to
> >  start running the operating system.
> >  @end table
> >
> > +@subsection EFI i386 entry address tag of Multiboot2 header
> > +
> > +@example
> > +@group
> > ++---+
> > +u16 | type = 8  |
> > +u16 | flags |
>
>
> Would it make sense to describe what 'flags' should contain? Or at least
> if there is nothing yet there mention that the value is ignored and
> should be zero?

'flags' is generic field and it is described earlier in the document.

Daniel

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

Re: [Xen-devel] [PATCH v11 08/13] x86/boot: implement early command line parser in C

[Daniel Kiper]

On Wed, Dec 07, 2016 at 06:43:40AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 23:25,  wrote:
> > Current early command line parser implementation in assembler
> > is very difficult to change to relocatable stuff using segment
> > registers. This requires a lot of changes in very weird and
> > fragile code. So, reimplement this functionality in C. This
> > way code will be relocatable out of the box (without playing
> > with segment registers) and much easier to maintain.
> >
> > Additionally, put all common cmdline.c and reloc.c definitions
> > into defs.h header. This way we do not duplicate needlessly
> > some stuff.
> >
> > And finally remove unused xen/include/asm-x86/config.h
> > header from reloc.c dependencies.
> >
> > Suggested-by: Andrew Cooper 
> > Signed-off-by: Daniel Kiper 
> > Acked-by: Jan Beulich 
>
> As you may have seen I've applied patches 2..4. I would also

Great! Thanks a lot!

> have applied this one, but it fails to apply cleanly. Whether
> that's because it needs re-basing or because it can't be applied
> out of order I can't tell. In order for you to not have to re-submit
> the whole series all the time it would help if you moved
> uncontroversial patches which make sense to be applied without
> the rest of the series to the beginning of the series.

Will do!

Daniel

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

Re: [Xen-devel] [PATCH v11 03/13] x86: allow EFI reboot method neither on EFI platforms...

[Daniel Kiper]

On Wed, Dec 07, 2016 at 06:18:19AM -0700, Jan Beulich wrote:
> >>> On 05.12.16 at 23:25,  wrote:
> > ..nor EFI platforms with runtime services enabled.
>
> Btw, was the title meant to read "... neither on non-EFI platforms ..."?

Right, thanks for pointing this out.

Daniel

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

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Ian Jackson]

Juergen Gross writes ("Xenstore domains and XS_RESTRICT"):
> In order to solve the problem I suggest the following change to the
> Xenstore wire protocol:
> 
>  struct xsd_sockmsg
>  {
> -uint32_t type;  /* XS_??? */
> +uint16_t type;  /* XS_??? */
> +uint16_t domid; /* Use privileges of this domain */

I don't think this is a particularly nice extension.  (Also the way
you have written it has an endianness hazard.)  What if we decide, at
some future point, to support domids >2^16 ?  That's hard right now
but I don't want to make it harder.

I suggest the following protocol extension instead:

Add to xenstore.txt (the list of xenstore commands):

  RESTRICTCMD   

Here  is a domain id, and  is a command
number; both of these are 32-bit integers in host byte order.

This is an instruction to execute the command 
with payload .  However, all permissions
checking should be done as if the command had been issued by
domain .

The req_id and tx_id, and (if the command affects watches) any
watches that are manipulated, are those of the calling
connection.  So the reply is sent to the xenstore client
(usually, ring client) which sent the RESTRICTCMD command.

If RESTRICTCMD is used to invoke WATCH, the  from the
RESTRICTCMD is attached to the watch, in xenstored.  Insofar
as watch events are filtered by the permission system, the
 from the RESTRICTCMD is used for watch events
originating from such a watch.  But the actual watch events
are sent to the connection that called RESTRICTCMD.

This is similar in semantics to RESTRICT but applies to this
one particular command (and its effects), only.

RESTRICTCMD has no effect on, and is not visible through, the
xenstore ring connection of domain  (if that domain
has one).

What do you think ?

There is a command length limit implication but I don't think that's
important.

Ian.

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

Re: [Xen-devel] [PATCH] xen/physmap: Propagate error rc from xenmem_add_to_physmap_one

[Andrew Cooper]

On 07/12/16 11:43, Jan Beulich wrote:
 On 07.12.16 at 02:07,  wrote:
>> On 07/12/2016 01:00, Jiandi An wrote:
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -762,6 +762,8 @@ static int xenmem_add_to_physmap_batch(struct domain *d,
>>>  rc = xenmem_add_to_physmap_one(d, xatpb->space,
>>> xatpb->u,
>>> idx, _gfn(gpfn));
>>> +if ( rc < 0 )
>>> +goto out;
>>>  
>>>  if ( unlikely(__copy_to_guest_offset(xatpb->errs, 0, , 1)) )
>>>  {
>> This can't be correct.  You now skip writing rc into the errs[] array on
>> a failure, which means that userspace will get an overall failure but an
>> errs[] array which said that nothing went wrong.
>>
>> This code addition looks like it wants to be an "else if" on the end of
>> this if() in context.
> Why would this go elsewhere? It's unneeded - it's a property of the
> hypercall that when seeing overall success you still need to look at
> errs[].

Looking at the public header files, the error behaviour isn't even
documented.  (I'm going to try and remember to pick up on bugs like this
more closely during future review.)

Similar batch hypercalls return the index of the first failing
operation, which is a far more helpful behaviour for the caller.

Having said that, I can't actually see any in-tree callers.

~Andrew

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

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

[John L. Poole]

On 12/7/2016 8:51 AM, Jan Beulich wrote:

On 07.12.16 at 16:57,  wrote:

I did the the following:

wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
tar -xvzf xen-4.8.0.tar.gz
cd /usr/local/src/xen-4.8.0
./configure

The config.log is available at: http://napadata.net/paste/view/9e7faf3d


make

 ...
  mv -f .efi.lds.d.new .efi.lds.d
  gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -Wdeclaration-after-statement -g -o efi/mkreloc
efi/mkreloc.c
  ld -mi386pep --subsystem=10 --image-base=0x82d08000
--stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x20
--file-alignment=0x20 --major-image-version=4 --minor-image-version=8
--major-os-version=2 --minor-os-version=0 --major-subsystem-version=2
--minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o
efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o
efi/buildid.o -o
/usr/local/src/xen-4.8.0/xen/.xen.efi.0x82d08000.0 &&   ld
-mi386pep --subsystem=10 --image-base=0x82d0c000 --stack=0,0
--heap=0,0 --strip-debug --section-alignment=0x20
--file-alignment=0x20 --major-image-version=4 --minor-image-version=8
--major-os-version=2 --minor-os-version=0 --major-subsystem-version=2
--minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o
efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o
efi/buildid.o -o
/usr/local/src/xen-4.8.0/xen/.xen.efi.0x82d0c000.0 && :
  efi/buildid.o: file not recognized: File format is ambiguous
  efi/buildid.o: matching formats: coff-x86-64 pe-x86-64

Hmm, at the first glance I'd call this a binutils bug: When talking
about an object file, it's necessarily COFF and never PE. But I'd
have to study their logic first to be certain. What binutils version
are you using, and what's the target list e.g. objcopy lists at the
end of its --help output?

Jan


Jan -

1) bintuils version: 2.25.1-r1

jlpoole@zeta /boot/efi $ eix binutils -I
[I] sys-devel/binutils
 Available versions:
 ...
 Installed versions:  2.25.1-r1(2.25.1)(06:01:52 AM 
11/12/2016)(cxx multitarget nls zlib -static-libs -test -vanilla)

 Homepage:https://sourceware.org/binutils/
 Description: Tools necessary to build programs

2) target list from the output of "objcopy --help" is located at:
 http://napadata.net/paste/view/6ebf2472

Thank you,

John

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

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Ian Jackson]

Konrad Rzeszutek Wilk writes ("Re: Xenstore domains and XS_RESTRICT"):
> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
> > There is no socket connection to xenstore domain.
> 
> Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
> with domid_id of zero? Or are you saying this is irrelevant becasue
> what you are interested is for the Linux kernel to filter certain
> xsd_sockmsg so it won't do something silly?

The latter.

> OK, so this all sounds like the OS needs to mediate access? Sorry for
> being so dense this morning.

The OS already needs to mediate access for all xenstore commands.  The
kernel xenbus driver has a list of the commands.  Some of them it will
"simply" proxy, translating request id and transaction fields, as
applicable.  Some of them it does something special for.  Unknown
commands are rejected.

> This would imply that the kernel driver would need to understand
> the format and disallow the XS_RESTRICT under certain conditions?

There should be a way to tell the kernel driver that the connection
should be restricted.  XS_RESTRICT is as good as any.

But the XS_RESTRICT command must not be forwarded by the kernel proxy
to the real xenstore.  Rather, the driver must make an annotation in
its client struct instead.

That annotation should result in _every_ proxied xenstore command,
from that client, being decorated so as to specify the restriction
domain.

There needs to be an extension to the xenstore protocol to support
this.

Ian.

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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Sven Köhler]

Am 07.12.2016 um 17:38 schrieb Samuel Thibault:
> Hello,
> 
> Jan Beulich, on Wed 07 Dec 2016 09:28:52 -0700, wrote:
>>> Right. Jan, could you please include the patch for 4.7.2? Upstream
>>> commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.
>>
>> Samuel, could you confirm that this is okay to backport.
> 
> For 4.7, yes.
> 
>> In which case the question then is whether 4.6.5 should get it too -
>> with p2m_seg mentioned no-where else under stubdom/ I can't really
>> tell where this is coming from.
> 
> For 4.6, I don't think so:
> 
> Commit abdf3c5b2b971dc12e665e8e0cda184b416efffe ('libxc: create p2m list
> outside of kernel mapping if supported') introduced that new case, and
> it's not in 4.6.

For me, the problems started with 4.7.0. Prior to that, the domUs were
booting fine. So I can confirm that 4.6.x was not affected.

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

Re: [Xen-devel] [PATCH] misc/release-checklist: Import from xenbits:~xen/release-checklist

[Ian Jackson]

Wei Liu writes ("Re: [PATCH] misc/release-checklist: Import from 
xenbits:~xen/release-checklist"):
> On Mon, Dec 05, 2016 at 12:36:12PM +, Ian Jackson wrote:
> > Please argue about the filename :-).
> 
> I don't have opinion on this.

Thanks all :-).  Committed.

Ian.

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

Re: [Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

[Jan Beulich]

>>> On 07.12.16 at 16:57,  wrote:
> I did the the following:
> 
> wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz 
> tar -xvzf xen-4.8.0.tar.gz
> cd /usr/local/src/xen-4.8.0
> ./configure
> 
> The config.log is available at: http://napadata.net/paste/view/9e7faf3d 
> 
> 
> make
> 
> ...
>  mv -f .efi.lds.d.new .efi.lds.d
>  gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer 
> -fno-strict-aliasing -Wdeclaration-after-statement -g -o efi/mkreloc 
> efi/mkreloc.c
>  ld -mi386pep --subsystem=10 --image-base=0x82d08000 
> --stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x20 
> --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 
> --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 
> --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o 
> efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o 
> efi/buildid.o -o 
> /usr/local/src/xen-4.8.0/xen/.xen.efi.0x82d08000.0 &&   ld 
> -mi386pep --subsystem=10 --image-base=0x82d0c000 --stack=0,0 
> --heap=0,0 --strip-debug --section-alignment=0x20 
> --file-alignment=0x20 --major-image-version=4 --minor-image-version=8 
> --major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 
> --minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o 
> efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o 
> efi/buildid.o -o 
> /usr/local/src/xen-4.8.0/xen/.xen.efi.0x82d0c000.0 && :
>  efi/buildid.o: file not recognized: File format is ambiguous
>  efi/buildid.o: matching formats: coff-x86-64 pe-x86-64

Hmm, at the first glance I'd call this a binutils bug: When talking
about an object file, it's necessarily COFF and never PE. But I'd
have to study their logic first to be certain. What binutils version
are you using, and what's the target list e.g. objcopy lists at the
end of its --help output?

Jan


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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Sven Köhler]

Am 07.12.2016 um 17:33 schrieb Jan Beulich:
 On 07.12.16 at 17:10,  wrote:
>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>>> On 28/09/16 01:33, Sven Köhler wrote:
 Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>>> On 27/09/16 13:13, Sven Köhler wrote:
 Am 27.09.2016 um 07:31 schrieb Juergen Gross:
> On 27/09/16 00:48, Sven Köhler wrote:
>> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>>> On 25/09/16 18:04, Sven Köhler wrote:
 Hi,

 I'm experiencing the bug below which was discussed on xen-devel 
 December
 last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on 
 Gentoo.

 The bug only seems to occur with the last domU booted on my 
 machine.
 Where do I find a patch that fixes that?
>>>
>>> The issue back in December was fixed by commit
>>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 
>>> 4.7.
>>> Either gentoo didn't update to the official Xen 4.7 release 
>>> (including
>>> pvgrub) or you are seeing a new issue.
>>
>> From the looks of it, the Gentoo package is using the grub from the
>> xen-4.7.0 tarball.
>>
>> I downgraded to pvgrub 4.6.3 and the problem went away.
>>
>> So I assume I'm seeing a new issue. How do I debug it?
>
> Interesting. Just tested it on upstream Xen and saw the same problem
> with a rather old guest kernel (3.0 based, xen flavor), while a newer
> kernel (4.1, pvops) is working.
>
> Can you give me some more details about the kernel you are trying to
> boot?

 It's an unmodified 4.4.21 kernel which I compile by hand. The config is
 attached. Does that help?
>>>
>>> Not really. OTOH I think I don't need more help, as I've found a problem
>>> in pvgrub. I have a patch which seems to correct the issue. Are you fine
>>> with me adding you as the original reporter of the problem in the patch?
>>
>> Yes, I'm fine with adding me as the reporter.
>> Do you want me to test the patch first?
>
> Sure. The attached patch is for Xen upstream, but I think it should
> apply to Xen 4.7, too.

 This patch solved the issue for me. My domU boots fine again after
 recompiling pvgrub with the patch applied.

 Thanks!
>>>
>>> Thank you for the test!
>>
>> It seems this patch was not included in 4.7.1. That's a shame, cause I
>> ran into the same issue after upgrading to 4.7.1.
> 
> I don't think anyone requested its inclusion - that process is in no
> way automatic.

I reported the error for 4.7.0, and I thought that Juergen might have
suggested it for inclusion. I upgraded to 4.7.1 just a few days ago, so
I thought I should point out that this patch was missed.

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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Samuel Thibault]

Hello,

Jan Beulich, on Wed 07 Dec 2016 09:28:52 -0700, wrote:
> > Right. Jan, could you please include the patch for 4.7.2? Upstream
> > commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.
> 
> Samuel, could you confirm that this is okay to backport.

For 4.7, yes.

> In which case the question then is whether 4.6.5 should get it too -
> with p2m_seg mentioned no-where else under stubdom/ I can't really
> tell where this is coming from.

For 4.6, I don't think so:

Commit abdf3c5b2b971dc12e665e8e0cda184b416efffe ('libxc: create p2m list
outside of kernel mapping if supported') introduced that new case, and
it's not in 4.6.

Samuel

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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Jan Beulich]

>>> On 07.12.16 at 17:10,  wrote:
> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>> On 28/09/16 01:33, Sven Köhler wrote:
>>> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
 On 27/09/16 14:09, Sven Köhler wrote:
> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>> On 27/09/16 13:13, Sven Köhler wrote:
>>> Am 27.09.2016 um 07:31 schrieb Juergen Gross:
 On 27/09/16 00:48, Sven Köhler wrote:
> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>> On 25/09/16 18:04, Sven Köhler wrote:
>>> Hi,
>>>
>>> I'm experiencing the bug below which was discussed on xen-devel 
>>> December
>>> last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on Gentoo.
>>>
>>> The bug only seems to occur with the last domU booted on my machine.
>>> Where do I find a patch that fixes that?
>>
>> The issue back in December was fixed by commit
>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 
>> 4.7.
>> Either gentoo didn't update to the official Xen 4.7 release 
>> (including
>> pvgrub) or you are seeing a new issue.
>
> From the looks of it, the Gentoo package is using the grub from the
> xen-4.7.0 tarball.
>
> I downgraded to pvgrub 4.6.3 and the problem went away.
>
> So I assume I'm seeing a new issue. How do I debug it?

 Interesting. Just tested it on upstream Xen and saw the same problem
 with a rather old guest kernel (3.0 based, xen flavor), while a newer
 kernel (4.1, pvops) is working.

 Can you give me some more details about the kernel you are trying to
 boot?
>>>
>>> It's an unmodified 4.4.21 kernel which I compile by hand. The config is
>>> attached. Does that help?
>>
>> Not really. OTOH I think I don't need more help, as I've found a problem
>> in pvgrub. I have a patch which seems to correct the issue. Are you fine
>> with me adding you as the original reporter of the problem in the patch?
>
> Yes, I'm fine with adding me as the reporter.
> Do you want me to test the patch first?

 Sure. The attached patch is for Xen upstream, but I think it should
 apply to Xen 4.7, too.
>>>
>>> This patch solved the issue for me. My domU boots fine again after
>>> recompiling pvgrub with the patch applied.
>>>
>>> Thanks!
>> 
>> Thank you for the test!
> 
> It seems this patch was not included in 4.7.1. That's a shame, cause I
> ran into the same issue after upgrading to 4.7.1.

I don't think anyone requested its inclusion - that process is in no
way automatic.

Jan

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

Re: [Xen-devel] [PATCH] x86emul: defer rIP-relative address calculation

[Jan Beulich]

>>> On 07.12.16 at 17:08,  wrote:
> On 07/12/16 15:47, Jan Beulich wrote:
> On 07.12.16 at 16:43,  wrote:
>> On 07.12.16 at 16:38,  wrote:
 On 07/12/16 14:07, Jan Beulich wrote:
> By putting it after all instruction fetching has been done, we can both
> simplify the existing handling of immediate operands and take care of
> any future instructions allowing rIP-relative operands and getting
> additional bytes fetched in x86_decode_*() (the current cases of extra
> bytes getting fetched there are only for operands without ModR/M bytes,
> or with them only allowing their register forms).
>
> Similarly the new placement of truncate_ea() will take care of any
> future cases of non-standard memory operands (the one existing case -
> opcodes A0...A3 - are fine with and without this, as they fetch an
> ad_bytes sized unsigned address anyway).
>
> Signed-off-by: Jan Beulich 
 This is rather clearer to follow.

 Reviewed-by: Andrew Cooper , although...

> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1925,6 +1925,7 @@ x86_decode(
>  uint8_t b, d, sib, sib_index, sib_base;
>  unsigned int def_op_bytes, def_ad_bytes, opcode;
>  enum x86_segment override_seg = x86_seg_none;
> +bool ip_rel = false;
 I would name this specifically rip_rel, as that is the term used in all
 the manuals.
>>> And I specifically avoided it as being wrong in the context of the
>>> 32-bit test harness. Would pc_rel suit you better than ip_rel?
>> Actually the reference to the 32-bit test harness was wrong here
>> (obviously). Instead, it is wrong in the context of 32-bit addressing
>> in 64-bit mode.
> 
> Such a case would still have rip_rel = false.  This addressing mode is
> unique to 64bit.

That's what I've said - 32-bit addressing in 64-bit mode (specifically
not compat mode), i.e. an address size override present there.

> But yes, pc_rel is still slightly better if you insist for not using
> rip_rel.

Will use that then.

Jan


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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Jan Beulich]

>>> On 07.12.16 at 17:18,  wrote:
> On 07/12/16 17:10, Sven Köhler wrote:
>> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>>> On 28/09/16 01:33, Sven Köhler wrote:
 Am 27.09.2016 um 14:52 schrieb Juergen Gross:
> On 27/09/16 14:09, Sven Köhler wrote:
>> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>>> On 27/09/16 13:13, Sven Köhler wrote:
 Am 27.09.2016 um 07:31 schrieb Juergen Gross:
> On 27/09/16 00:48, Sven Köhler wrote:
>> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>>> On 25/09/16 18:04, Sven Köhler wrote:
 Hi,

 I'm experiencing the bug below which was discussed on xen-devel 
 December
 last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on 
 Gentoo.

 The bug only seems to occur with the last domU booted on my 
 machine.
 Where do I find a patch that fixes that?
>>>
>>> The issue back in December was fixed by commit
>>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 
>>> 4.7.
>>> Either gentoo didn't update to the official Xen 4.7 release 
>>> (including
>>> pvgrub) or you are seeing a new issue.
>>
>> From the looks of it, the Gentoo package is using the grub from the
>> xen-4.7.0 tarball.
>>
>> I downgraded to pvgrub 4.6.3 and the problem went away.
>>
>> So I assume I'm seeing a new issue. How do I debug it?
>
> Interesting. Just tested it on upstream Xen and saw the same problem
> with a rather old guest kernel (3.0 based, xen flavor), while a newer
> kernel (4.1, pvops) is working.
>
> Can you give me some more details about the kernel you are trying to
> boot?

 It's an unmodified 4.4.21 kernel which I compile by hand. The config is
 attached. Does that help?
>>>
>>> Not really. OTOH I think I don't need more help, as I've found a problem
>>> in pvgrub. I have a patch which seems to correct the issue. Are you fine
>>> with me adding you as the original reporter of the problem in the patch?
>>
>> Yes, I'm fine with adding me as the reporter.
>> Do you want me to test the patch first?
>
> Sure. The attached patch is for Xen upstream, but I think it should
> apply to Xen 4.7, too.

 This patch solved the issue for me. My domU boots fine again after
 recompiling pvgrub with the patch applied.

 Thanks!
>>>
>>> Thank you for the test!
>> 
>> It seems this patch was not included in 4.7.1. That's a shame, cause I
>> ran into the same issue after upgrading to 4.7.1.
> 
> Right. Jan, could you please include the patch for 4.7.2? Upstream
> commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.

Samuel, could you confirm that this is okay to backport. In
which case the question then is whether 4.6.5 should get it
too - with p2m_seg mentioned no-where else under stubdom/
I can't really tell where this is coming from.

Jan

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

Re: [Xen-devel] Possible improvement to Xen Security Response Process

[Ian Jackson]

Matthew Allen writes ("Re: [Xen-devel] Possible improvement to Xen Security 
Response Process"):
> I agree; I'm suggesting changes to the dates that the security team
> would propose to a discoverer.

Right.

Personally I think that batching would be valuable, if it does not
lead to either inordinate delay or precipitate publication.  Of course
opinions about what "inordinate" or "precipitate" mean are likely to
produce some disagreements...

Matthew's suggestion of having fixed dates is a possible way forward
but it might also lead to avoidable delays.


I have an alternative concrete suggestion:

 Unless there are good reasons to diverge, our suggestions to
 discoverer(s) will be based on the following criteria, in order of
 precedence:
 1. Avoiding disclosure on Fridays, weekends, or on or immediately
before widely respected public holidays.
 2. Minimising the number of distinct publication dates 
within each 14 day period.
 3. Making the preparation period for each advisory as close,
on a log scale, to 14 days as possible.
 (The preparation period for an advisory is the period between
 predisclosure and publication.)

Essentially this means that if predisclosure of a second batch occurs
in the first 5 days of a 14 day preparation period, the existing date
will be reused; on or after the 6th day, a new date, beyond, will be
suggested.  So the minimum preparation period is 9 days (9/14 = ie,
1.55x too short), and the maximum is 22 days (22/14 = 1.57x too long).
(Figures slightly fudged due to day-granuarity rounding error.)

That's a suggested compromise between those who will want to do
batching by making the timescales shorter and those who want to make
them longer.  (Using a log scale avoids the problem that a linear
scale would mean that the error factor would be ~2x short but only ~1.5x
long.)


Bunfight, anyone ?


Ian.
(Responding with a personal opinion, and hence from a personal
 email address.  I haven't discussed this with my management at
 Citrix.)

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

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

Re: [Xen-devel] [PATCH] x86emul: fold SReg PUSH/POP cases

[Jan Beulich]

>>> On 07.12.16 at 16:54,  wrote:
> On 07/12/16 14:09, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -2670,51 +2670,40 @@ x86_emulate(
>>  break;
>>  
>>  case 0x06: /* push %%es */
>> -src.val = x86_seg_es;
>> -push_seg:
>> -generate_exception_if(mode_64bit() && !ext, EXC_UD);
>> +case 0x0e: /* push %%cs */
>> +case 0x16: /* push %%ss */
>> +case 0x1e: /* push %%ds */
>> +generate_exception_if(mode_64bit(), EXC_UD);
>> +/* fall through */
>> +case X86EMUL_OPC(0x0f, 0xa0): /* push %%fs */
>> +case X86EMUL_OPC(0x0f, 0xa8): /* push %%gs */
>>  fail_if(ops->read_segment == NULL);
>> -if ( (rc = ops->read_segment(src.val, , ctxt)) != 0 )
>> +if ( (rc = ops->read_segment((b >> 3) & 7, ,
>> + ctxt)) != X86EMUL_OKAY )
>>  goto done;
>>  src.val = sreg.sel;
>>  goto push;
>>  
>>  case 0x07: /* pop %%es */
>> -src.val = x86_seg_es;
>> -pop_seg:
>> -generate_exception_if(mode_64bit() && !ext, EXC_UD);
>> +case 0x17: /* pop %%ss */
>> +case 0x1f: /* pop %%ds */
>> +generate_exception_if(mode_64bit(), EXC_UD);
>> +/* fall through */
>> +case X86EMUL_OPC(0x0f, 0xa1): /* pop %%fs */
>> +case X86EMUL_OPC(0x0f, 0xa9): /* pop %%gs */
>>  fail_if(ops->write_segment == NULL);
>>  /* 64-bit mode: POP defaults to a 64-bit operand. */
>>  if ( mode_64bit() && (op_bytes == 4) )
>>  op_bytes = 8;
>> -if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
>> -  , op_bytes, ctxt, ops)) != 0 ||
>> - (rc = load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) != 0 )
>> +if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes), ,
>> +  op_bytes, ctxt, ops)) != X86EMUL_OKAY ||
>> + (rc = load_seg((b >> 3) & 7, dst.val, 0, NULL, ctxt,
>> +ops)) != X86EMUL_OKAY )
>>  goto done;
>> -if ( src.val == x86_seg_ss )
>> +if ( b == 0x07 )
> 
> This would be less error prone by setting
> 
> seg = (b >> 3) & 7;
> 
> similarly to the mov %sreg blocks.
> 
> Doing so wouldn't accidentally break this by setting mov_ss for a pop %es.

Oops - that's a pretty kind way of saying that I've introduced a bug.

Jan


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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Juergen Gross]

On 07/12/16 17:10, Sven Köhler wrote:
> Am 28.09.2016 um 05:50 schrieb Juergen Gross:
>> On 28/09/16 01:33, Sven Köhler wrote:
>>> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
 On 27/09/16 14:09, Sven Köhler wrote:
> Am 27.09.2016 um 14:02 schrieb Juergen Gross:
>> On 27/09/16 13:13, Sven Köhler wrote:
>>> Am 27.09.2016 um 07:31 schrieb Juergen Gross:
 On 27/09/16 00:48, Sven Köhler wrote:
> Am 26.09.2016 um 07:43 schrieb Juergen Gross:
>> On 25/09/16 18:04, Sven Köhler wrote:
>>> Hi,
>>>
>>> I'm experiencing the bug below which was discussed on xen-devel 
>>> December
>>> last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on Gentoo.
>>>
>>> The bug only seems to occur with the last domU booted on my machine.
>>> Where do I find a patch that fixes that?
>>
>> The issue back in December was fixed by commit
>> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 
>> 4.7.
>> Either gentoo didn't update to the official Xen 4.7 release 
>> (including
>> pvgrub) or you are seeing a new issue.
>
> From the looks of it, the Gentoo package is using the grub from the
> xen-4.7.0 tarball.
>
> I downgraded to pvgrub 4.6.3 and the problem went away.
>
> So I assume I'm seeing a new issue. How do I debug it?

 Interesting. Just tested it on upstream Xen and saw the same problem
 with a rather old guest kernel (3.0 based, xen flavor), while a newer
 kernel (4.1, pvops) is working.

 Can you give me some more details about the kernel you are trying to
 boot?
>>>
>>> It's an unmodified 4.4.21 kernel which I compile by hand. The config is
>>> attached. Does that help?
>>
>> Not really. OTOH I think I don't need more help, as I've found a problem
>> in pvgrub. I have a patch which seems to correct the issue. Are you fine
>> with me adding you as the original reporter of the problem in the patch?
>
> Yes, I'm fine with adding me as the reporter.
> Do you want me to test the patch first?

 Sure. The attached patch is for Xen upstream, but I think it should
 apply to Xen 4.7, too.
>>>
>>> This patch solved the issue for me. My domU boots fine again after
>>> recompiling pvgrub with the patch applied.
>>>
>>> Thanks!
>>
>> Thank you for the test!
> 
> It seems this patch was not included in 4.7.1. That's a shame, cause I
> ran into the same issue after upgrading to 4.7.1.

Right. Jan, could you please include the patch for 4.7.2? Upstream
commit was 9714f6b87e19b32d3a6663a20df6610265c4bfe5.


Juergen


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

Re: [Xen-devel] [Xen-users] pvgrub: Error 9: Unknown boot failure

[Sven Köhler]

Am 28.09.2016 um 05:50 schrieb Juergen Gross:
> On 28/09/16 01:33, Sven Köhler wrote:
>> Am 27.09.2016 um 14:52 schrieb Juergen Gross:
>>> On 27/09/16 14:09, Sven Köhler wrote:
 Am 27.09.2016 um 14:02 schrieb Juergen Gross:
> On 27/09/16 13:13, Sven Köhler wrote:
>> Am 27.09.2016 um 07:31 schrieb Juergen Gross:
>>> On 27/09/16 00:48, Sven Köhler wrote:
 Am 26.09.2016 um 07:43 schrieb Juergen Gross:
> On 25/09/16 18:04, Sven Köhler wrote:
>> Hi,
>>
>> I'm experiencing the bug below which was discussed on xen-devel 
>> December
>> last year buy Ian and Juergen. I'm using xen-pvgrub-4.7.0 on Gentoo.
>>
>> The bug only seems to occur with the last domU booted on my machine.
>> Where do I find a patch that fixes that?
>
> The issue back in December was fixed by commit
> c8eb0ec277ae387e78d685523e0fee633e46f046 which is included in Xen 4.7.
> Either gentoo didn't update to the official Xen 4.7 release (including
> pvgrub) or you are seeing a new issue.

 From the looks of it, the Gentoo package is using the grub from the
 xen-4.7.0 tarball.

 I downgraded to pvgrub 4.6.3 and the problem went away.

 So I assume I'm seeing a new issue. How do I debug it?
>>>
>>> Interesting. Just tested it on upstream Xen and saw the same problem
>>> with a rather old guest kernel (3.0 based, xen flavor), while a newer
>>> kernel (4.1, pvops) is working.
>>>
>>> Can you give me some more details about the kernel you are trying to
>>> boot?
>>
>> It's an unmodified 4.4.21 kernel which I compile by hand. The config is
>> attached. Does that help?
>
> Not really. OTOH I think I don't need more help, as I've found a problem
> in pvgrub. I have a patch which seems to correct the issue. Are you fine
> with me adding you as the original reporter of the problem in the patch?

 Yes, I'm fine with adding me as the reporter.
 Do you want me to test the patch first?
>>>
>>> Sure. The attached patch is for Xen upstream, but I think it should
>>> apply to Xen 4.7, too.
>>
>> This patch solved the issue for me. My domU boots fine again after
>> recompiling pvgrub with the patch applied.
>>
>> Thanks!
> 
> Thank you for the test!

It seems this patch was not included in 4.7.1. That's a shame, cause I
ran into the same issue after upgrading to 4.7.1.


Regards,
  Sven

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

Re: [Xen-devel] [PATCH] x86emul: defer rIP-relative address calculation

[Andrew Cooper]

On 07/12/16 15:47, Jan Beulich wrote:
 On 07.12.16 at 16:43,  wrote:
> On 07.12.16 at 16:38,  wrote:
>>> On 07/12/16 14:07, Jan Beulich wrote:
 By putting it after all instruction fetching has been done, we can both
 simplify the existing handling of immediate operands and take care of
 any future instructions allowing rIP-relative operands and getting
 additional bytes fetched in x86_decode_*() (the current cases of extra
 bytes getting fetched there are only for operands without ModR/M bytes,
 or with them only allowing their register forms).

 Similarly the new placement of truncate_ea() will take care of any
 future cases of non-standard memory operands (the one existing case -
 opcodes A0...A3 - are fine with and without this, as they fetch an
 ad_bytes sized unsigned address anyway).

 Signed-off-by: Jan Beulich 
>>> This is rather clearer to follow.
>>>
>>> Reviewed-by: Andrew Cooper , although...
>>>
 --- a/xen/arch/x86/x86_emulate/x86_emulate.c
 +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
 @@ -1925,6 +1925,7 @@ x86_decode(
  uint8_t b, d, sib, sib_index, sib_base;
  unsigned int def_op_bytes, def_ad_bytes, opcode;
  enum x86_segment override_seg = x86_seg_none;
 +bool ip_rel = false;
>>> I would name this specifically rip_rel, as that is the term used in all
>>> the manuals.
>> And I specifically avoided it as being wrong in the context of the
>> 32-bit test harness. Would pc_rel suit you better than ip_rel?
> Actually the reference to the 32-bit test harness was wrong here
> (obviously). Instead, it is wrong in the context of 32-bit addressing
> in 64-bit mode.

Such a case would still have rip_rel = false.  This addressing mode is
unique to 64bit.

But yes, pc_rel is still slightly better if you insist for not using
rip_rel.

~Andrew

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

Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP

[Andrew Cooper]

On 07/12/16 15:39, Jan Beulich wrote:
 On 07.12.16 at 16:31,  wrote:
>> On 12/07/2016 10:14 AM, Jan Beulich wrote:
>> On 07.12.16 at 16:10,  wrote:
 On 12/07/2016 06:29 AM, Jan Beulich wrote:
 On 06.12.16 at 17:23,  wrote:
>> On 12/06/2016 06:44 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -154,6 +154,13 @@ static void __init calculate_hvm_feature
>>>  __set_bit(X86_FEATURE_APIC, hvm_featureset);
>>>  
>>>  /*
>>> + * Xen can often provide UMIP emulation to HVM guests even if the 
>>> host
>>> + * doesn't have such functionality.
>>> + */
>>> +if ( cpu_has_vmx_dt_exiting || cpu_has_svm )
>>> +__set_bit(X86_FEATURE_UMIP, hvm_featureset);
>> I don't think I understand how this is going to work for processors that
>> don't support UMIP.
>>
>> How, for example, can guest_cr[4] have X86_CR4_UMIP set on these
>> processors when CPUID will not show the feature being there?
> What we allow the guest to see and what we store into hardware
> registers are two different things: Note how svm_update_guest_cr()
> masks off X86_CR4_UMIP from the vale to be put into the VMCB.
 So that was kind of my question --- why would a guest ever try to set
 this bit? As far as it is concerned, UMIP is not available and the guest
 is then trying to set an unsupported bit in cr4. And that should result
 in a #GP.
>>> But the code fragment above adds the respective CPUID bit to the
>>> permitted features. Believe me, I've tried this with a UMIP-enabled
>>> Linux (including proper CPUID based detection).
>> Are you referring to these patches: https://lkml.org/lkml/2016/11/8/68 ?
>> If yes then they look to be Intel-specific.
> No, I had written my own before these had been posted. I did
> actually post mine too, but that was a week or so after theirs,
> and theirs appears to be more complete.
>
>> If AMD decides to use CPUID0x7.ecx[2] for something else --- won't this
>> be a problem for this patch?
> I think the two vendors meanwhile do a good job not interfering with
> one another's CPUID bits. We'd have ugly problems elsewhere if any
> new dual purpose CPUID bit appeared.

[root@minuet-1 ~]# head /proc/cpuinfo
processor: 0
vendor_id: AuthenticAMD
cpu family: 21
model: 96

[root@minuet-1 ~]# xen-cpuid
nr_features: 10
  KEY 1d   1c   e1d  e1c  Da1 
7b0  7c0  e7d  e8b  7d0 

Static sets:
Known
b7ebfbff:fffef3ff:efd3fbff:2469bfff:000f:fdbf:001b:0500:0001:000c
Special  
1200:8820::0002::2040:0010:::
PV Mask  
17c9cbf5:f6f83203:e2500800:042109e3:0007:fdaf0b39:0003::0001:000c
HVM Shadow Mask  
17cbfbff:f7f83223:ea500800:04218df7:000f:fdbf4bbb:0003::0001:000c
HVM Hap Mask 
17cbfbff:f7fa3223:ee500800:04218df7:000f:fdbf4fbb:000b::0001:000c

Dynamic sets:
Raw  
178bfbff:fed8320b:2fd3fbff:2febbfff:0001:01a9::37d9::
Host 
178bf3ff:f6d8320b:2fd3fbff:2469bfff:0001:01a9::0500::
PV   
1789c3f5:f6f83203:23d1cbf5:042109e3:0001:0129::::
HVM  
178bfbff:f6f83203:2fd3fbff:04218df7:0001:01a9::::


This processor already implements some of Intel's features from
0x7[0].ebx, including SMEP.  According to marketing, AMD Zen processors
will add the ADX, RDSEED, SHA, CLFLUSHOPT and SMAP features

I can't reasonably see them using a different feature word.

~Andrew

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

Re: [Xen-devel] [PATCH v3 5/5] tools/libacpi: announce that PVHv2 has no CMOS RTC in FADT

[Jan Beulich]

>>> On 05.12.16 at 16:04,  wrote:
> At the moment this flag is unconditionally set for PVHv2 domains. Note that
> using this boot flag requires that the FADT table revision is at least 5 (or 
> any
> later version), so bump the current FADT version from 4 to 5 and add two new
> fields that will be unused.

This version bumping part appears to be stale now. The patch itself
looks okay, but will likely need some re-basing over changes to the
previous one.

Jan


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

Re: [Xen-devel] [PATCH v3 4/5] tools/libacpi: update FADT layout to support version 5

[Jan Beulich]

>>> On 05.12.16 at 16:04,  wrote:
> --- a/tools/firmware/hvmloader/util.c
> +++ b/tools/firmware/hvmloader/util.c
> @@ -949,7 +949,7 @@ void hvmloader_acpi_build_tables(struct acpi_config 
> *config,
>  config->table_flags |= ACPI_HAS_SSDT_S4;
>  
>  config->table_flags |= (ACPI_HAS_TCPA | ACPI_HAS_IOAPIC | ACPI_HAS_WAET |
> -ACPI_HAS_VGA | ACPI_HAS_8042);
> +ACPI_HAS_VGA | ACPI_HAS_8042 | ACPI_FADT_4);

It shouldn't be an explicit FADT version that gets requested, but
a specific ACPI version (and I don't think a boolean flag is suitable
for this).

> --- a/tools/libacpi/acpi2_0.h
> +++ b/tools/libacpi/acpi2_0.h
> @@ -169,7 +169,7 @@ struct acpi_10_fadt {
>  /*
>   * Fixed ACPI Description Table Structure (FADT).
>   */
> -struct acpi_20_fadt {
> +struct acpi_50_fadt {

I think it would be better to drop the version number from this
name and ...

> @@ -222,6 +222,8 @@ struct acpi_20_fadt {
>  struct acpi_20_generic_address x_pm_tmr_blk;
>  struct acpi_20_generic_address x_gpe0_blk;
>  struct acpi_20_generic_address x_gpe1_blk;
> +struct acpi_20_generic_address sleep_control;
> +struct acpi_20_generic_address sleep_status;
>  };

... add version comments to the new fields.

> --- a/tools/libacpi/build.c
> +++ b/tools/libacpi/build.c
> @@ -503,12 +503,13 @@ int acpi_build_tables(struct acpi_ctxt *ctxt, struct 
> acpi_config *config)
>  struct acpi_20_rsdp *rsdp;
>  struct acpi_20_rsdt *rsdt;
>  struct acpi_20_xsdt *xsdt;
> -struct acpi_20_fadt *fadt;
> +struct acpi_50_fadt *fadt;
>  struct acpi_10_fadt *fadt_10;
>  struct acpi_20_facs *facs;
>  unsigned char   *dsdt;
>  unsigned longsecondary_tables[ACPI_MAX_SECONDARY_TABLES];
>  int  nr_secondaries, i;
> +unsigned longfadt_size;

unsigned int would suffice here, wouldn't it? Otherwise it should be
size_t.

> --- a/tools/libacpi/static_tables.c
> +++ b/tools/libacpi/static_tables.c
> @@ -38,11 +38,11 @@ struct acpi_20_facs Facs = {
>  #define ACPI_PM_TMR_BLK_BIT_WIDTH   0x20
>  #define ACPI_PM_TMR_BLK_BIT_OFFSET  0x00
>  
> -struct acpi_20_fadt Fadt = {
> +struct acpi_50_fadt Fadt = {
>  .header = {
> -.signature= ACPI_2_0_FADT_SIGNATURE,
> -.length   = sizeof(struct acpi_20_fadt),
> -.revision = ACPI_2_0_FADT_REVISION,
> +.signature= ACPI_FADT_SIGNATURE,
> +.length   = sizeof(struct acpi_50_fadt),
> +.revision = ACPI_5_0_FADT_REVISION,

Let's please not pre-initialize either value, but set both fields uniformly
at runtime.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f33b4fc4efc11a45184a8a368bd3a6bdb6b01dd0
baseline version:
 xen  2a854e414f7e1b905af5bdb9c88f154cfe4f5f4e

Last test of basis   103012  2016-12-07 08:12:12 Z0 days
Testing same since   103027  2016-12-07 12:54:38 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Cédric Bosdonnat 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  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 :

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

[Xen-devel] [xen-4.8-testing test] 102998: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   6 xen-boot fail REGR. vs. 102940
 test-armhf-armhf-xl-vhd   6 xen-boot fail REGR. vs. 102940
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102940
 test-amd64-amd64-xl-credit2  21 guest-destroyfail REGR. vs. 102940
 test-amd64-i386-freebsd10-i386 18 guest-start/freebsd.repeat fail REGR. vs. 
102940

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 16 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 102940
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 102940
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 102940

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

version targeted for testing:
 xen  1f4ea1603570a91c486f2cd26c819d076f260f30
baseline version:
 xen  a7a578ce6b8634eec30cb8445ea98e18d9b4e9b8

Last test of basis   102940  2016-12-05 12:52:01 Z2 days
Failing since102988  2016-12-06 06:24:35 Z1 days2 attempts
Testing same since   102998  2016-12-07 08:02:48 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 

[Xen-devel] [BUG] Xen-4.8.0 efi/buildid.o: file not recognized/Ambiguous

[John L. Poole]

I did the the following:

wget https://downloads.xenproject.org/release/xen/4.8.0/xen-4.8.0.tar.gz
tar -xvzf xen-4.8.0.tar.gz
cd /usr/local/src/xen-4.8.0
./configure

The config.log is available at: http://napadata.net/paste/view/9e7faf3d


make

   ...
mv -f .efi.lds.d.new .efi.lds.d
gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer 
-fno-strict-aliasing -Wdeclaration-after-statement -g -o efi/mkreloc 
efi/mkreloc.c
ld -mi386pep --subsystem=10 --image-base=0x82d08000 
--stack=0,0 --heap=0,0 --strip-debug --section-alignment=0x20 
--file-alignment=0x20 --major-image-version=4 --minor-image-version=8 
--major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o 
efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o 
efi/buildid.o -o 
/usr/local/src/xen-4.8.0/xen/.xen.efi.0x82d08000.0 &&   ld 
-mi386pep --subsystem=10 --image-base=0x82d0c000 --stack=0,0 
--heap=0,0 --strip-debug --section-alignment=0x20 
--file-alignment=0x20 --major-image-version=4 --minor-image-version=8 
--major-os-version=2 --minor-os-version=0 --major-subsystem-version=2 
--minor-subsystem-version=0 --build-id=sha1 -T efi.lds -N prelink-efi.o 
efi/relocs-dummy.o /usr/local/src/xen-4.8.0/xen/common/symbols-dummy.o 
efi/buildid.o -o 
/usr/local/src/xen-4.8.0/xen/.xen.efi.0x82d0c000.0 && :

efi/buildid.o: file not recognized: File format is ambiguous
efi/buildid.o: matching formats: coff-x86-64 pe-x86-64
Makefile:175: recipe for target 
'/usr/local/src/xen-4.8.0/xen/xen.efi' failed

make[3]: *** [/usr/local/src/xen-4.8.0/xen/xen.efi] Error 1
make[3]: Leaving directory '/usr/local/src/xen-4.8.0/xen/arch/x86'
Makefile:135: recipe for target '/usr/local/src/xen-4.8.0/xen/xen' 
failed

make[2]: *** [/usr/local/src/xen-4.8.0/xen/xen] Error 2
make[2]: Leaving directory '/usr/local/src/xen-4.8.0/xen'
Makefile:45: recipe for target 'install' failed
make[1]: *** [install] Error 2
make[1]: Leaving directory '/usr/local/src/xen-4.8.0/xen'
Makefile:97: recipe for target 'install-xen' failed
make: *** [install-xen] Error 2
jlpoole@zeta /usr/local/src/xen-4.8.0 $

I can post anything other information requested in my pastebin or 
provide as directed. I would have opened a bug, but 
https://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project 
suggests sending to this list first.


John Poole



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

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Juergen Gross]

On 07/12/16 16:40, Konrad Rzeszutek Wilk wrote:
> On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
>> On 07/12/16 15:15, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote:
 Hi,

 today the XS_RESTRICT wire command of Xenstore is supported by
 oxenstored only to drop the privilege of a connection to that of the
 domid given as a parameter to the command.

 Using this mechanism with Xenstore running in a stubdom will lead to
 problems as instead of only a dom0 process dropping its privileges
 the privileges of dom0 will be dropped (all dom0 Xenstore requests
 share the same connection).
>>>
>>> .. which means we can't create new XenStore entries or save
>>> off all the XenStore entries?
>>
>> Example: qemu for domid 4 is dropping its privilege to that of domid 4
>> with xenstore running as domain (in contrast to xenstored). If we don't
>> do anything about it dom0 will only be capable to access xenstore with
>> the privileges domid 4 has (e.g. creation of entries outside of
>> /local/domain/4/ will be impossible).
> 
> But .. why? Shouldn't it have RWX access to its tree? I should
> read up on XS_RESTRICT.

That would help, yes. :-)

With XS_RESTRICT a privileged connection can drop its privileges to
those of a specific domain. This is meant to be used e.g. by qemu
together with dropping root privileges after initialization to avoid
causing damage to odom0/other domains due to security leaks.

> 
>>

 In order to solve the problem I suggest the following change to the
 Xenstore wire protocol:

  struct xsd_sockmsg
  {
 -uint32_t type;  /* XS_??? */
 +uint16_t type;  /* XS_??? */
 +uint16_t domid; /* Use privileges of this domain */
  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). */
  };

 domid will normally be zero having the same effect as today.

 Using XS_RESTRICT via a socket connection will run as today by dropping
 the privileges of that connection.

 Using XS_RESTRICT via the kernel (Xenstore domain case) will save the
>>>
>>> Xenstore domain case? As in Linux kernel running the XenStore as
>>> an stubdomain?
>>
>> Xenstore is running in a stubdom and thus dom0 is issuing xenstore
>> commands via the kernel (xenbus driver) to the xenstore domain.
>>
>>> No, that can't be it. I think you mean that the kernel will have
>>> an priviligied connection all the time?
>>
>> No. the kernel will have just one connection. Privilege is derived
>> from domid (dom0 -> 0).
> 
> What if the XenBus Mirage is the first domain? You could have
> have it part of the .init section in Xen and it would be started as
> the first domain.
> 
> Depending on the value of domid I think is incorrect.

It is correct. The comparison done is to either 0 or privileged domain
(set via start parameter of xenstore domain/daemon).

> 
>>
 domid given as parameter in the connection specific private kernel
 structure. All future Xenstore commands of the connection will have
 this domid set in xsd_sockmsg. The kernel will never forward the
 XS_RESTRICT command to Xenstore.
>>>
>>>

 A domid other than 0 in xsd_sockmsg will be handled by Xenstore to use
 the privileges of that domain. Specifying a domid in xsd_sockmsg is
 allowed for privileged domain only, of course. XS_RESTRICT via a
 non-socket connection will be rejected in all cases.
>>>
>>> Um, but couldn't a malicious guest decide to craft such packet?
>>
>> There is no socket connection to xenstore domain.
> 
> Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
> with domid_id of zero? Or are you saying this is irrelevant becasue
> what you are interested is for the Linux kernel to filter certain
> xsd_sockmsg so it won't do something silly?

The domid has to be correct for being able to get a grant for its ring.
So it isn't transferred via the ring of the new domain, but from dom0
via the XS_INTRODUCE wire command (which is allowed for the privileged
domain only).

> 
>>

 The needed modifications for Xenstore and the kernel are rather small.
 As there is currently no Xenstore domain available supporting
 XS_RESTRICT there are no compatibility issues to expect.

 Thoughts?
>>>
>>> I think I need to wrap my head about your use-case? Could you enumerate
>>> what it is?
>>
>> Xenstore isn't running as a daemon in dom0, but as a domain. All domains
>> including dom0 have to connect via xenbus. This means all agents in dom0
>> accessing xenstore share one connection.
>>
>> In case xenstore is a daemon in dom0 each agent in dom0 accessing
>> xenstore will open an own socket 

Re: [Xen-devel] [PATCH] x86emul: fold SReg PUSH/POP cases

[Andrew Cooper]

On 07/12/16 14:09, Jan Beulich wrote:
> Now that segment registers are numbered naturally this can be easily
> done to achieve some code size reduction.
>
> Also consistently use X86EMUL_OKAY in the code being touched.
>
> Signed-off-by: Jan Beulich 

Nice improvement in principle, but...

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -2670,51 +2670,40 @@ x86_emulate(
>  break;
>  
>  case 0x06: /* push %%es */
> -src.val = x86_seg_es;
> -push_seg:
> -generate_exception_if(mode_64bit() && !ext, EXC_UD);
> +case 0x0e: /* push %%cs */
> +case 0x16: /* push %%ss */
> +case 0x1e: /* push %%ds */
> +generate_exception_if(mode_64bit(), EXC_UD);
> +/* fall through */
> +case X86EMUL_OPC(0x0f, 0xa0): /* push %%fs */
> +case X86EMUL_OPC(0x0f, 0xa8): /* push %%gs */
>  fail_if(ops->read_segment == NULL);
> -if ( (rc = ops->read_segment(src.val, , ctxt)) != 0 )
> +if ( (rc = ops->read_segment((b >> 3) & 7, ,
> + ctxt)) != X86EMUL_OKAY )
>  goto done;
>  src.val = sreg.sel;
>  goto push;
>  
>  case 0x07: /* pop %%es */
> -src.val = x86_seg_es;
> -pop_seg:
> -generate_exception_if(mode_64bit() && !ext, EXC_UD);
> +case 0x17: /* pop %%ss */
> +case 0x1f: /* pop %%ds */
> +generate_exception_if(mode_64bit(), EXC_UD);
> +/* fall through */
> +case X86EMUL_OPC(0x0f, 0xa1): /* pop %%fs */
> +case X86EMUL_OPC(0x0f, 0xa9): /* pop %%gs */
>  fail_if(ops->write_segment == NULL);
>  /* 64-bit mode: POP defaults to a 64-bit operand. */
>  if ( mode_64bit() && (op_bytes == 4) )
>  op_bytes = 8;
> -if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
> -  , op_bytes, ctxt, ops)) != 0 ||
> - (rc = load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) != 0 )
> +if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes), ,
> +  op_bytes, ctxt, ops)) != X86EMUL_OKAY ||
> + (rc = load_seg((b >> 3) & 7, dst.val, 0, NULL, ctxt,
> +ops)) != X86EMUL_OKAY )
>  goto done;
> -if ( src.val == x86_seg_ss )
> +if ( b == 0x07 )

This would be less error prone by setting

seg = (b >> 3) & 7;

similarly to the mov %sreg blocks.

Doing so wouldn't accidentally break this by setting mov_ss for a pop %es.

~Andrew

>  ctxt->retire.mov_ss = true;
>  break;


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

Re: [Xen-devel] [PATCH] x86emul: defer rIP-relative address calculation

[Jan Beulich]

>>> On 07.12.16 at 16:43,  wrote:
 On 07.12.16 at 16:38,  wrote:
>> On 07/12/16 14:07, Jan Beulich wrote:
>>> By putting it after all instruction fetching has been done, we can both
>>> simplify the existing handling of immediate operands and take care of
>>> any future instructions allowing rIP-relative operands and getting
>>> additional bytes fetched in x86_decode_*() (the current cases of extra
>>> bytes getting fetched there are only for operands without ModR/M bytes,
>>> or with them only allowing their register forms).
>>>
>>> Similarly the new placement of truncate_ea() will take care of any
>>> future cases of non-standard memory operands (the one existing case -
>>> opcodes A0...A3 - are fine with and without this, as they fetch an
>>> ad_bytes sized unsigned address anyway).
>>>
>>> Signed-off-by: Jan Beulich 
>> 
>> This is rather clearer to follow.
>> 
>> Reviewed-by: Andrew Cooper , although...
>> 
>>>
>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>>> @@ -1925,6 +1925,7 @@ x86_decode(
>>>  uint8_t b, d, sib, sib_index, sib_base;
>>>  unsigned int def_op_bytes, def_ad_bytes, opcode;
>>>  enum x86_segment override_seg = x86_seg_none;
>>> +bool ip_rel = false;
>> 
>> I would name this specifically rip_rel, as that is the term used in all
>> the manuals.
> 
> And I specifically avoided it as being wrong in the context of the
> 32-bit test harness. Would pc_rel suit you better than ip_rel?

Actually the reference to the 32-bit test harness was wrong here
(obviously). Instead, it is wrong in the context of 32-bit addressing
in 64-bit mode.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: defer rIP-relative address calculation

[Jan Beulich]

>>> On 07.12.16 at 16:38,  wrote:
> On 07/12/16 14:07, Jan Beulich wrote:
>> By putting it after all instruction fetching has been done, we can both
>> simplify the existing handling of immediate operands and take care of
>> any future instructions allowing rIP-relative operands and getting
>> additional bytes fetched in x86_decode_*() (the current cases of extra
>> bytes getting fetched there are only for operands without ModR/M bytes,
>> or with them only allowing their register forms).
>>
>> Similarly the new placement of truncate_ea() will take care of any
>> future cases of non-standard memory operands (the one existing case -
>> opcodes A0...A3 - are fine with and without this, as they fetch an
>> ad_bytes sized unsigned address anyway).
>>
>> Signed-off-by: Jan Beulich 
> 
> This is rather clearer to follow.
> 
> Reviewed-by: Andrew Cooper , although...
> 
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -1925,6 +1925,7 @@ x86_decode(
>>  uint8_t b, d, sib, sib_index, sib_base;
>>  unsigned int def_op_bytes, def_ad_bytes, opcode;
>>  enum x86_segment override_seg = x86_seg_none;
>> +bool ip_rel = false;
> 
> I would name this specifically rip_rel, as that is the term used in all
> the manuals.

And I specifically avoided it as being wrong in the context of the
32-bit test harness. Would pc_rel suit you better than ip_rel?

Jan


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

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

[Konrad Rzeszutek Wilk]

On Wed, Dec 07, 2016 at 03:26:38PM +0100, Juergen Gross wrote:
> On 07/12/16 15:15, Konrad Rzeszutek Wilk wrote:
> > On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote:
> >> Hi,
> >>
> >> today the XS_RESTRICT wire command of Xenstore is supported by
> >> oxenstored only to drop the privilege of a connection to that of the
> >> domid given as a parameter to the command.
> >>
> >> Using this mechanism with Xenstore running in a stubdom will lead to
> >> problems as instead of only a dom0 process dropping its privileges
> >> the privileges of dom0 will be dropped (all dom0 Xenstore requests
> >> share the same connection).
> > 
> > .. which means we can't create new XenStore entries or save
> > off all the XenStore entries?
> 
> Example: qemu for domid 4 is dropping its privilege to that of domid 4
> with xenstore running as domain (in contrast to xenstored). If we don't
> do anything about it dom0 will only be capable to access xenstore with
> the privileges domid 4 has (e.g. creation of entries outside of
> /local/domain/4/ will be impossible).

But .. why? Shouldn't it have RWX access to its tree? I should
read up on XS_RESTRICT.

> 
> >>
> >> In order to solve the problem I suggest the following change to the
> >> Xenstore wire protocol:
> >>
> >>  struct xsd_sockmsg
> >>  {
> >> -uint32_t type;  /* XS_??? */
> >> +uint16_t type;  /* XS_??? */
> >> +uint16_t domid; /* Use privileges of this domain */
> >>  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). */
> >>  };
> >>
> >> domid will normally be zero having the same effect as today.
> >>
> >> Using XS_RESTRICT via a socket connection will run as today by dropping
> >> the privileges of that connection.
> >>
> >> Using XS_RESTRICT via the kernel (Xenstore domain case) will save the
> > 
> > Xenstore domain case? As in Linux kernel running the XenStore as
> > an stubdomain?
> 
> Xenstore is running in a stubdom and thus dom0 is issuing xenstore
> commands via the kernel (xenbus driver) to the xenstore domain.
> 
> > No, that can't be it. I think you mean that the kernel will have
> > an priviligied connection all the time?
> 
> No. the kernel will have just one connection. Privilege is derived
> from domid (dom0 -> 0).

What if the XenBus Mirage is the first domain? You could have
have it part of the .init section in Xen and it would be started as
the first domain.

Depending on the value of domid I think is incorrect.

> 
> >> domid given as parameter in the connection specific private kernel
> >> structure. All future Xenstore commands of the connection will have
> >> this domid set in xsd_sockmsg. The kernel will never forward the
> >> XS_RESTRICT command to Xenstore.
> > 
> > 
> >>
> >> A domid other than 0 in xsd_sockmsg will be handled by Xenstore to use
> >> the privileges of that domain. Specifying a domid in xsd_sockmsg is
> >> allowed for privileged domain only, of course. XS_RESTRICT via a
> >> non-socket connection will be rejected in all cases.
> > 
> > Um, but couldn't a malicious guest decide to craft such packet?
> 
> There is no socket connection to xenstore domain.

Right but it creates its own XenStore ring. Can it send this xsd_sockmsg
with domid_id of zero? Or are you saying this is irrelevant becasue
what you are interested is for the Linux kernel to filter certain
xsd_sockmsg so it won't do something silly?

> 
> >>
> >> The needed modifications for Xenstore and the kernel are rather small.
> >> As there is currently no Xenstore domain available supporting
> >> XS_RESTRICT there are no compatibility issues to expect.
> >>
> >> Thoughts?
> > 
> > I think I need to wrap my head about your use-case? Could you enumerate
> > what it is?
> 
> Xenstore isn't running as a daemon in dom0, but as a domain. All domains
> including dom0 have to connect via xenbus. This means all agents in dom0
> accessing xenstore share one connection.
> 
> In case xenstore is a daemon in dom0 each agent in dom0 accessing
> xenstore will open an own socket connection to the daemon, so they can
> drop their privileges independent from each other.

OK, so this all sounds like the OS needs to mediate access? Sorry for
being so dense this morning.

This would imply that the kernel driver would need to understand
the format and disallow the XS_RESTRICT under certain conditions?

That seems reasonable.
> 
> 
> Juergen

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

Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP

[Jan Beulich]

>>> On 07.12.16 at 16:31,  wrote:
> On 12/07/2016 10:14 AM, Jan Beulich wrote:
> On 07.12.16 at 16:10,  wrote:
>>> On 12/07/2016 06:29 AM, Jan Beulich wrote:
>>> On 06.12.16 at 17:23,  wrote:
> On 12/06/2016 06:44 AM, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpuid.c
>> +++ b/xen/arch/x86/cpuid.c
>> @@ -154,6 +154,13 @@ static void __init calculate_hvm_feature
>>  __set_bit(X86_FEATURE_APIC, hvm_featureset);
>>  
>>  /*
>> + * Xen can often provide UMIP emulation to HVM guests even if the 
>> host
>> + * doesn't have such functionality.
>> + */
>> +if ( cpu_has_vmx_dt_exiting || cpu_has_svm )
>> +__set_bit(X86_FEATURE_UMIP, hvm_featureset);
> I don't think I understand how this is going to work for processors that
> don't support UMIP.
>
> How, for example, can guest_cr[4] have X86_CR4_UMIP set on these
> processors when CPUID will not show the feature being there?
 What we allow the guest to see and what we store into hardware
 registers are two different things: Note how svm_update_guest_cr()
 masks off X86_CR4_UMIP from the vale to be put into the VMCB.
>>> So that was kind of my question --- why would a guest ever try to set
>>> this bit? As far as it is concerned, UMIP is not available and the guest
>>> is then trying to set an unsupported bit in cr4. And that should result
>>> in a #GP.
>> But the code fragment above adds the respective CPUID bit to the
>> permitted features. Believe me, I've tried this with a UMIP-enabled
>> Linux (including proper CPUID based detection).
> 
> Are you referring to these patches: https://lkml.org/lkml/2016/11/8/68 ?
> If yes then they look to be Intel-specific.

No, I had written my own before these had been posted. I did
actually post mine too, but that was a week or so after theirs,
and theirs appears to be more complete.

> If AMD decides to use CPUID0x7.ecx[2] for something else --- won't this
> be a problem for this patch?

I think the two vendors meanwhile do a good job not interfering with
one another's CPUID bits. We'd have ugly problems elsewhere if any
new dual purpose CPUID bit appeared.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: defer rIP-relative address calculation

[Andrew Cooper]

On 07/12/16 14:07, Jan Beulich wrote:
> By putting it after all instruction fetching has been done, we can both
> simplify the existing handling of immediate operands and take care of
> any future instructions allowing rIP-relative operands and getting
> additional bytes fetched in x86_decode_*() (the current cases of extra
> bytes getting fetched there are only for operands without ModR/M bytes,
> or with them only allowing their register forms).
>
> Similarly the new placement of truncate_ea() will take care of any
> future cases of non-standard memory operands (the one existing case -
> opcodes A0...A3 - are fine with and without this, as they fetch an
> ad_bytes sized unsigned address anyway).
>
> Signed-off-by: Jan Beulich 

This is rather clearer to follow.

Reviewed-by: Andrew Cooper , although...

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -1925,6 +1925,7 @@ x86_decode(
>  uint8_t b, d, sib, sib_index, sib_base;
>  unsigned int def_op_bytes, def_ad_bytes, opcode;
>  enum x86_segment override_seg = x86_seg_none;
> +bool ip_rel = false;

I would name this specifically rip_rel, as that is the term used in all
the manuals.

~Andrew

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

Re: [Xen-devel] [PATCH 6/6] x86emul: simplify FPU handling asm() constraints

[Jan Beulich]

>>> On 07.12.16 at 16:16,  wrote:
> On 06/12/16 14:14, Jan Beulich wrote:
>> The memory clobber is rather harsh here.
> 
> Does removing it actually make a difference?  I can't spot anything
> which could reasonably be reordered around the asm() blocks.

It's not so much the re-ordering but the potential dropping of
something that was cached in a register. Indeed there was no
change to the generated code at all with current gcc, but the
compiler gets better over time, and we shouldn't restrict it
unduly.

>> However, fic.exn_raised may be
>> modified as a side effect, so we need to let the compiler know that all
>> of "fic" may be changed (preventing it from moving around accesses to
>> the exn_raised field).
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
>> @@ -784,7 +784,7 @@ do {
>>  })
>>  
>>  struct fpu_insn_ctxt {
>> -uint8_t insn_bytes;
>> +uint8_t insn_bytes; /* Must be first! */
> 
> And one single byte.  The compiler would previously have caught an
> accidental breaking of this requirement.

There was no such requirement before. Of course we could add an
immediate operand to all the asm()s, specifying the offsetof(). But
then again we already have a hidden dependency on its size anyway.

> As an alternative, how about using ACCESS_ONCE() to read exn_raised?  It
> would allow you to drop the memory clobber and also not generalise the
> fic.insn_bytes memory parameter to fic.

There's no ACCESS_ONCE() in the x86 code, and even less so in
what the emulator code can use. Nor would what you suggest
allow to legitimately drop the memory clobber.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: simplify {,i}{mul,div} fix

[Andrew Cooper]

On 07/12/16 14:05, Jan Beulich wrote:
> Commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") can be had with
> less code: Simply do the destination register override depending on
> DstEax being in effect (the four other ModRM.reg encoded operations of
> these two opcodes all use DstMem).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86emul: drop stray NULL check

[Andrew Cooper]

On 07/12/16 14:03, Jan Beulich wrote:
> ->read is required to be non-NULL, and is not being checked anywhere else.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86emul: drop dead code from SYSENTER handling

[Andrew Cooper]

On 07/12/16 14:02, Jan Beulich wrote:
> There's no point reading CS - all of the fields get set from scratch
> right afterwards. Also correct a wrong comment.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper , although

>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -4841,12 +4841,10 @@ x86_emulate(
>  
>  _regs.eflags &= ~(EFLG_VM | EFLG_IF | EFLG_RF);
>  
> -fail_if(ops->read_segment == NULL);
> -ops->read_segment(x86_seg_cs, , ctxt);
>  cs.sel = msr_content & ~3; /* SELECTOR_RPL_MASK */
>  cs.base = 0;   /* flat segment */
>  cs.limit = ~0u;  /* 4GB limit */
> -cs.attr.bytes = lm ? 0xa9b  /* L+DB+P+S+Code */
> +cs.attr.bytes = lm ? 0xa9b  /* L+G+P+S+Code */

Strictly speaking its G+L+P, seeing as the other attributes are listed
in bit order.

~Andrew

> : 0xc9b; /* G+DB+P+S+Code */
>  
>  sreg.sel = cs.sel + 8;
>
>
>


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

Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP

[Boris Ostrovsky]

On 12/07/2016 10:14 AM, Jan Beulich wrote:
 On 07.12.16 at 16:10,  wrote:
>> On 12/07/2016 06:29 AM, Jan Beulich wrote:
>> On 06.12.16 at 17:23,  wrote:
 On 12/06/2016 06:44 AM, Jan Beulich wrote:
> --- a/xen/arch/x86/cpuid.c
> +++ b/xen/arch/x86/cpuid.c
> @@ -154,6 +154,13 @@ static void __init calculate_hvm_feature
>  __set_bit(X86_FEATURE_APIC, hvm_featureset);
>  
>  /*
> + * Xen can often provide UMIP emulation to HVM guests even if the 
> host
> + * doesn't have such functionality.
> + */
> +if ( cpu_has_vmx_dt_exiting || cpu_has_svm )
> +__set_bit(X86_FEATURE_UMIP, hvm_featureset);
 I don't think I understand how this is going to work for processors that
 don't support UMIP.

 How, for example, can guest_cr[4] have X86_CR4_UMIP set on these
 processors when CPUID will not show the feature being there?
>>> What we allow the guest to see and what we store into hardware
>>> registers are two different things: Note how svm_update_guest_cr()
>>> masks off X86_CR4_UMIP from the vale to be put into the VMCB.
>> So that was kind of my question --- why would a guest ever try to set
>> this bit? As far as it is concerned, UMIP is not available and the guest
>> is then trying to set an unsupported bit in cr4. And that should result
>> in a #GP.
> But the code fragment above adds the respective CPUID bit to the
> permitted features. Believe me, I've tried this with a UMIP-enabled
> Linux (including proper CPUID based detection).

Are you referring to these patches: https://lkml.org/lkml/2016/11/8/68 ?
If yes then they look to be Intel-specific.

If AMD decides to use CPUID0x7.ecx[2] for something else --- won't this
be a problem for this patch?

-boris



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

Re: [Xen-devel] megaraid_sas regression in linux-3.18 [and 1 more messages]

[Ian Jackson]

alexander.le...@verizon.com writes ("RE: megaraid_sas regression in linux-3.18 
[and 1 more messages]"):
> On Fri, Dec 02, 2016 at 02:36:22PM +, Ian Jackson wrote:
> > Stable maintainers, could you please incorporate 5e5ec1759dd6 into
> > linux-3.18.y ?
> 
> Added 5e5ec1759dd6 to the 3.18 queue, thanks!

It looks like we're missing it from linux-4.1.y too ?

Do we need to request backports explicitly for all the affected
trees ?  The Xen Project osstest CI/bisector only gives us a partial
view.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH 4/6] x86emul: reduce FPU handling code size

[Andrew Cooper]

On 07/12/16 15:16, Jan Beulich wrote:
 On 07.12.16 at 16:06,  wrote:
>> On 06/12/16 14:13, Jan Beulich wrote:
>>> @@ -3670,6 +3652,7 @@ x86_emulate(
>>>  
>>>  case 0xd8: /* FPU 0xd8 */
>>>  host_and_vcpu_must_have(fpu);
>>> +get_fpu(X86EMUL_FPU_fpu, );
>>>  switch ( modrm )
>>>  {
>>>  case 0xc0 ... 0xc7: /* fadd %stN,%st */
>>> @@ -3715,10 +3698,12 @@ x86_emulate(
>>>  break;
>>>  }
>>>  }
>>> +put_fpu();
>>>  break;
>> This repositioning does mean that we might skip the put_fpu() call,
>> although we still retain the catch-all _put_fpu().
>>
>> I think this is still safe as we only skip this put_fpu() in cases where
>> we didn't emulate an instruction, and there isn't the risk of missing a
>> pending FPU exception.
> Correct - the catch-all one is sufficient for all cases.

Ok.  Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] INSTALL: remove stale coverage build instruction

[Andrew Cooper]

On 07/12/16 15:10, Wei Liu wrote:
> Now it is controlled by Kconfig.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 6/6] x86emul: simplify FPU handling asm() constraints

[Andrew Cooper]

On 06/12/16 14:14, Jan Beulich wrote:
> The memory clobber is rather harsh here.

Does removing it actually make a difference?  I can't spot anything
which could reasonably be reordered around the asm() blocks.

> However, fic.exn_raised may be
> modified as a side effect, so we need to let the compiler know that all
> of "fic" may be changed (preventing it from moving around accesses to
> the exn_raised field).
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/x86_emulate/x86_emulate.c
> +++ b/xen/arch/x86/x86_emulate/x86_emulate.c
> @@ -784,7 +784,7 @@ do {
>  })
>  
>  struct fpu_insn_ctxt {
> -uint8_t insn_bytes;
> +uint8_t insn_bytes; /* Must be first! */

And one single byte.  The compiler would previously have caught an
accidental breaking of this requirement.

As an alternative, how about using ACCESS_ONCE() to read exn_raised?  It
would allow you to drop the memory clobber and also not generalise the
fic.insn_bytes memory parameter to fic.

~Andrew

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

Re: [Xen-devel] [PATCH 4/6] x86emul: reduce FPU handling code size

[Jan Beulich]

>>> On 07.12.16 at 16:06,  wrote:
> On 06/12/16 14:13, Jan Beulich wrote:
>> @@ -3670,6 +3652,7 @@ x86_emulate(
>>  
>>  case 0xd8: /* FPU 0xd8 */
>>  host_and_vcpu_must_have(fpu);
>> +get_fpu(X86EMUL_FPU_fpu, );
>>  switch ( modrm )
>>  {
>>  case 0xc0 ... 0xc7: /* fadd %stN,%st */
>> @@ -3715,10 +3698,12 @@ x86_emulate(
>>  break;
>>  }
>>  }
>> +put_fpu();
>>  break;
> 
> This repositioning does mean that we might skip the put_fpu() call,
> although we still retain the catch-all _put_fpu().
> 
> I think this is still safe as we only skip this put_fpu() in cases where
> we didn't emulate an instruction, and there isn't the risk of missing a
> pending FPU exception.

Correct - the catch-all one is sufficient for all cases.

Jan


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

[Xen-devel] [PATCH v2 2/2] x86emul: correct 64-bit mode repeated string insn handling with zero count

[Jan Beulich]

When a 32-bit address override is in effect these zero-extend all
registers which would also get updated in case of non-zero repeat
count.

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

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -933,15 +933,24 @@ static inline void put_loop_count(
 regs->ecx = ad_bytes == 4 ? (uint32_t)count : count;
 }
 
-#define get_rep_prefix() ({ \
+#define get_rep_prefix(using_si, using_di) ({   \
 unsigned long max_reps = 1; \
 if ( rep_prefix() ) \
 max_reps = get_loop_count(&_regs, ad_bytes);\
 if ( max_reps == 0 )\
 {   \
-/* Skip the instruction if no repetitions are required. */  \
-dst.type = OP_NONE; \
-goto writeback; \
+/*  \
+ * Skip the instruction if no repetitions are required, but \
+ * zero extend involved registers first when using 32-bit   \
+ * addressing in 64-bit mode.   \
+ */ \
+if ( mode_64bit() && ad_bytes == 4 )\
+{   \
+_regs.ecx = 0;  \
+if ( using_si ) _regs.esi = (uint32_t)_regs.esi;\
+if ( using_di ) _regs.edi = (uint32_t)_regs.edi;\
+}   \
+goto no_writeback;  \
 }   \
 max_reps;   \
 })
@@ -2911,7 +2920,7 @@ x86_emulate(
 goto imul;
 
 case 0x6c ... 0x6d: /* ins %dx,%es:%edi */ {
-unsigned long nr_reps = get_rep_prefix();
+unsigned long nr_reps = get_rep_prefix(false, true);
 unsigned int port = (uint16_t)_regs.edx;
 dst.bytes = !(b & 1) ? 1 : (op_bytes == 8) ? 4 : op_bytes;
 dst.mem.seg = x86_seg_es;
@@ -2943,7 +2952,7 @@ x86_emulate(
 }
 
 case 0x6e ... 0x6f: /* outs %esi,%dx */ {
-unsigned long nr_reps = get_rep_prefix();
+unsigned long nr_reps = get_rep_prefix(true, false);
 unsigned int port = (uint16_t)_regs.edx;
 dst.bytes = !(b & 1) ? 1 : (op_bytes == 8) ? 4 : op_bytes;
 ea.mem.off = truncate_ea_and_reps(_regs.esi, nr_reps, dst.bytes);
@@ -3187,7 +3196,8 @@ x86_emulate(
 break;
 
 case 0xa4 ... 0xa5: /* movs */ {
-unsigned long nr_reps = get_rep_prefix();
+unsigned long nr_reps = get_rep_prefix(true, true);
+
 dst.bytes = (d & ByteOp) ? 1 : op_bytes;
 dst.mem.seg = x86_seg_es;
 dst.mem.off = truncate_ea_and_reps(_regs.edi, nr_reps, dst.bytes);
@@ -3220,7 +3230,8 @@ x86_emulate(
 
 case 0xa6 ... 0xa7: /* cmps */ {
 unsigned long next_eip = _regs.eip;
-get_rep_prefix();
+
+get_rep_prefix(true, true);
 src.bytes = dst.bytes = (d & ByteOp) ? 1 : op_bytes;
 if ( (rc = read_ulong(ea.mem.seg, truncate_ea(_regs.esi),
   , dst.bytes, ctxt, ops)) ||
@@ -3241,7 +3252,8 @@ x86_emulate(
 }
 
 case 0xaa ... 0xab: /* stos */ {
-unsigned long nr_reps = get_rep_prefix();
+unsigned long nr_reps = get_rep_prefix(false, true);
+
 dst.bytes = (d & ByteOp) ? 1 : op_bytes;
 dst.mem.seg = x86_seg_es;
 dst.mem.off = truncate_ea(_regs.edi);
@@ -3264,8 +3276,8 @@ x86_emulate(
 break;
 }
 
-case 0xac ... 0xad: /* lods */ {
-/* unsigned long max_reps = */get_rep_prefix();
+case 0xac ... 0xad: /* lods */
+get_rep_prefix(true, false);
 dst.type  = OP_REG;
 dst.bytes = (d & ByteOp) ? 1 : op_bytes;
 dst.reg   = (unsigned long *)&_regs.eax;
@@ -3276,11 +3288,11 @@ x86_emulate(
 _regs.esi, (_regs.eflags & EFLG_DF) ? -dst.bytes : dst.bytes);
 put_rep_prefix(1);
 break;
-}
 
 case 0xae ... 0xaf: /* scas */ {
 unsigned long next_eip = _regs.eip;
-get_rep_prefix();
+
+get_rep_prefix(false, true);
 src.bytes = dst.bytes = (d & ByteOp) ? 1 : op_bytes;
 dst.val = _regs.eax;
 if ( (rc = read_ulong(x86_seg_es, truncate_ea(_regs.edi),
@@ -5443,7 +5455,6 @@ x86_emulate(
 goto cannot_emulate;
 

Re: [Xen-devel] [PATCH 2/3] x86/HVM: support (emulate) UMIP

[Boris Ostrovsky]

On 12/07/2016 06:29 AM, Jan Beulich wrote:
 On 06.12.16 at 17:23,  wrote:
>> On 12/06/2016 06:44 AM, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -154,6 +154,13 @@ static void __init calculate_hvm_feature
>>>  __set_bit(X86_FEATURE_APIC, hvm_featureset);
>>>  
>>>  /*
>>> + * Xen can often provide UMIP emulation to HVM guests even if the host
>>> + * doesn't have such functionality.
>>> + */
>>> +if ( cpu_has_vmx_dt_exiting || cpu_has_svm )
>>> +__set_bit(X86_FEATURE_UMIP, hvm_featureset);
>> I don't think I understand how this is going to work for processors that
>> don't support UMIP.
>>
>> How, for example, can guest_cr[4] have X86_CR4_UMIP set on these
>> processors when CPUID will not show the feature being there?
> What we allow the guest to see and what we store into hardware
> registers are two different things: Note how svm_update_guest_cr()
> masks off X86_CR4_UMIP from the vale to be put into the VMCB.

So that was kind of my question --- why would a guest ever try to set
this bit? As far as it is concerned, UMIP is not available and the guest
is then trying to set an unsupported bit in cr4. And that should result
in a #GP.

-boris

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

[Xen-devel] [PATCH v2 1/2] x86emul: consolidate loop counter handling

[Jan Beulich]

Rename _get_rep_prefix() to make it more visibly fit other use cases
and introduce a companion "put". Use them for repeated string insn
handling as well as LOOP/J?CXZ instead of open coding the same logic a
couple of times.

Signed-off-by: Jan Beulich 
---
v2: s/int_regs/regs/ in {get,put}_loop_count(). Defer subtraction of 1
in LOOP handling.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -913,19 +913,30 @@ do {
 put_stub(stub); \
 } while (0)
 
-static unsigned long _get_rep_prefix(
-const struct cpu_user_regs *int_regs,
+static inline unsigned long get_loop_count(
+const struct cpu_user_regs *regs,
 int ad_bytes)
 {
-return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
-   (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
-   int_regs->ecx;
+return (ad_bytes == 2) ? (uint16_t)regs->ecx :
+   (ad_bytes == 4) ? (uint32_t)regs->ecx :
+   regs->ecx;
+}
+
+static inline void put_loop_count(
+struct cpu_user_regs *regs,
+int ad_bytes,
+unsigned long count)
+{
+if ( ad_bytes == 2 )
+*(uint16_t *)>ecx = count;
+else
+regs->ecx = ad_bytes == 4 ? (uint32_t)count : count;
 }
 
 #define get_rep_prefix() ({ \
 unsigned long max_reps = 1; \
 if ( rep_prefix() ) \
-max_reps = _get_rep_prefix(&_regs, ad_bytes);   \
+max_reps = get_loop_count(&_regs, ad_bytes);\
 if ( max_reps == 0 )\
 {   \
 /* Skip the instruction if no repetitions are required. */  \
@@ -941,21 +952,14 @@ static void __put_rep_prefix(
 int ad_bytes,
 unsigned long reps_completed)
 {
-unsigned long ecx = ((ad_bytes == 2) ? (uint16_t)int_regs->ecx :
- (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
- int_regs->ecx);
+unsigned long ecx = get_loop_count(int_regs, ad_bytes);
 
 /* Reduce counter appropriately, and repeat instruction if non-zero. */
 ecx -= reps_completed;
 if ( ecx != 0 )
 int_regs->eip = ext_regs->eip;
 
-if ( ad_bytes == 2 )
-*(uint16_t *)_regs->ecx = ecx;
-else if ( ad_bytes == 4 )
-int_regs->ecx = (uint32_t)ecx;
-else
-int_regs->ecx = ecx;
+put_loop_count(int_regs, ad_bytes, ecx);
 }
 
 #define put_rep_prefix(reps_completed) ({   \
@@ -4007,33 +4011,21 @@ x86_emulate(
 break;
 
 case 0xe0 ... 0xe2: /* loop{,z,nz} */ {
+unsigned long count = get_loop_count(&_regs, ad_bytes);
 int do_jmp = !(_regs.eflags & EFLG_ZF); /* loopnz */
 
 if ( b == 0xe1 )
 do_jmp = !do_jmp; /* loopz */
 else if ( b == 0xe2 )
 do_jmp = 1; /* loop */
-switch ( ad_bytes )
-{
-case 2:
-do_jmp &= --(*(uint16_t *)&_regs.ecx) != 0;
-break;
-case 4:
-do_jmp &= --(*(uint32_t *)&_regs.ecx) != 0;
-_regs.ecx = (uint32_t)_regs.ecx; /* zero extend in x86/64 mode */
-break;
-default: /* case 8: */
-do_jmp &= --_regs.ecx != 0;
-break;
-}
-if ( do_jmp )
+if ( count != 1 && do_jmp )
 jmp_rel((int32_t)src.val);
+put_loop_count(&_regs, ad_bytes, count - 1);
 break;
 }
 
 case 0xe3: /* jcxz/jecxz (short) */
-if ( (ad_bytes == 2) ? !(uint16_t)_regs.ecx :
- (ad_bytes == 4) ? !(uint32_t)_regs.ecx : !_regs.ecx )
+if ( !get_loop_count(&_regs, ad_bytes) )
 jmp_rel((int32_t)src.val);
 break;
 



x86emul: consolidate loop counter handling

Rename _get_rep_prefix() to make it more visibly fit other use cases
and introduce a companion "put". Use them for repeated string insn
handling as well as LOOP/J?CXZ instead of open coding the same logic a
couple of times.

Signed-off-by: Jan Beulich 
---
v2: s/int_regs/regs/ in {get,put}_loop_count(). Defer subtraction of 1
in LOOP handling.

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -913,19 +913,30 @@ do {
 put_stub(stub); \
 } while (0)
 
-static unsigned long _get_rep_prefix(
-const struct cpu_user_regs *int_regs,
+static inline unsigned long get_loop_count(
+const struct cpu_user_regs *regs,
 int ad_bytes)
 {
-return (ad_bytes == 2) ? (uint16_t)int_regs->ecx :
-   (ad_bytes == 4) ? (uint32_t)int_regs->ecx :
-   int_regs->ecx;
+return (ad_bytes == 2) ? (uint16_t)regs->ecx :
+   (ad_bytes == 4) ? (uint32_t)regs->ecx :