[Xen-devel] [xen-unstable-smoke test] 114059: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl  10 debian-install fail pass in 114056

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 13 migrate-support-check fail in 114056 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 114056 never pass

version targeted for testing:
 xen  2b668a84e52a8999d93c438fb259ddf0ec0f62fe
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z2 days
Failing since113979  2017-10-04 00:10:13 Z2 days   29 attempts
Testing same since   114047  2017-10-05 16:08:51 Z0 days6 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Not pushing.

(No revision log; it would be 653 lines long.)

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

Re: [Xen-devel] [PATCH v2 12/13] fuzz/x86_emulate: Set and fuzz more CPU state

[Jan Beulich]

>>> George Dunlap  10/05/17 7:08 PM >>>
>On 10/04/2017 09:28 AM, Jan Beulich wrote:
> On 25.09.17 at 16:26,  wrote:
>>> @@ -597,6 +599,47 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>>>  };
>>>  #undef SET
>>>  
>>> +static void _set_fpu_state(char *fxsave, bool store)
>>> +{
>>> +if ( cpu_has_fxsr )
>>> +{
>>> +static union __attribute__((__aligned__(16))) {
>>> +char x[464];
>> 
>> The final part of the save area isn't being written, yes, but is it
>> really worth saving the few bytes of stack space here, rather than
>> having the expected 512 as array dimension?
>
>So I didn't actually look into this very much; I mainly just hacked at
>it until it seemed to work.  I copied-and-pasted emul_test_init() from
>x86_emulate.c (which is where the 464 came from), then copied some
>scraps of asm from stackoverflow.

Oh, so it looks like I'm guilty here, as I think it was me who wrote it that
way there. I have to admit I don't really see why I wanted to save on stack
consumption there. In any event I'm then fine for you to leave it that way,
so the two places remain in sync (but I would also be fine if you changed
it here, and I'd then try to remember to clean it up on the other side).

>>> +}
>>> +
>>> +asm volatile( "fxsave %0" : "=m" (*fxs) );
>> 
>> This is pretty confusing, the more with the different variable names
>> used which point to the same piece of memory. You basically store back
>> into the area you've read from. Is the caller expecting the memory area
>> to change? Is this being done other than for convenience to not have
>> another instance of scratch space on the stack? Some comment on the
>> intentions may be helpful here.
>
>Yes, sorry for the different variable names.  I should have done a
>better clean-up of this patch.
>
>As for why it's doing an fxsave after just doing an fxrstor: I had the
>idea that what came out via fxsave might not be the same as what was
>written via fxrstor (i.e., the instruction would "interpret" the data),
>particularly as what went in would be completely random fuzzed state.
>The idea behind doing the restore / save was to "sanitize" the state in
>the state struct to look more like real input data.

Okay, that's what I had guessed. As said, please put this in a comment, the
more that you've realized this doesn't work all by itself (due to the MXCSR 
field
causing #GP when not sanitized _before_ doing the fxrstor). And the restore
from null then is to pre-init any (theoretical) fields the subsequent restore 
may
not touch at all?

>> The function's parameter name being "store" adds to the confusion,
>> since what it controls is actually what we call "load" on x86 (or
>> "restore" following the insn mnemonics).
>
>I chose 'store' as the argument name before I realized that fxrstor was
>"fx restore" and not "fxr store".
>
>Do you think 'write' would be suitable?  Names like "restore" or "load"
>make sense if you're thinking about things from the processor's
>perspective (as the architects certainly were); but they make less sense
>from a programmer's perspective, since (to me anyway) it seems like I'm
>writing to or reading from the FPU unit (rather than loading/restoring
>or saving).
>
>If you don't like 'write' I'll change it to 'restore'.

"write" is fine, I think, as would be "ro" or "readonly".

>> And then - what about YMM register state? Other more exotic registers
>> (like the BND* ones) may indeed not be that relevant to fuzz yet.
>
>I can look into that if you want, or if you want to give me some runes
>to copy in I'm happy to do that as well.

As that's not as simple as FXSAVE/FXRSTOR (due to first needing to
discover area sizes) it's perhaps best to simply leave a TODO comment for
now.

>>> @@ -737,6 +780,17 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
>>>  printf("Setting cpu_user_regs offset %x\n", offset);
>>>  continue;
>>>  }
>>> +offset -= sizeof(struct cpu_user_regs);
>>> +
>>> +/* Fuzz fxsave state */
>>> +if ( offset < 128 )
>>> +{
>>> +if ( !input_read(s, s->fxsave + (offset * 4), 4) )
>>> +return;
>>> +printf("Setting fxsave offset %x\n", offset * 4);
>> 
>> What's this 32-bit granularity derived from?
>
>Just seemed like a good-sized chunk.  Doing it byte-by-byte seemed to be
>"wasting" input on offsets (as in the input you'd have a 2-byte 'offset'
>followed by a one-byte bit of data).  This way you have a 2-byte offset
>and a 4-byte chunk of data that you write.

Well, ideally individual pieces would be taken all-or-nothing, but due to the
varying sizes this would be rather cumbersome. So with the comment about
this being arbitrary add, I think this will be fine for the time being.

Jan


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

Re: [Xen-devel] [PATCH v2 11/13] fuzz/x86_emulate: Add --rerun option to try to track down instability

[Jan Beulich]

>>> George Dunlap  10/05/17 6:13 PM >>>
>On 10/04/2017 09:27 AM, Jan Beulich wrote:
> On 25.09.17 at 16:26,  wrote:
>>> +if ( memcmp(&state[0], &state[1], sizeof(struct fuzz_state)) )
>>> +{
>>> +int i;
>> 
>> unsigned int (and then %u in the format strings below)
>
>Is there really an advantage to specifying 'unsigned int' for something
>like a loop variable?  It hardly seems worth the effort to consider
>signed / unsigned in such a case.

The latest when a loop variable is being used as array index it does matter on
most 64-bit architectures: Zero-extension (to machine word size) is often 
implied
by other operations, while sign-extension frequently requires an extra insn. 
This
may not matter much here, but I think it's better to follow the same common
pattern everywhere.

>>> @@ -908,7 +1035,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, 
>>> size_t size)
>>>  return 1;
>>>  }
>>>  
>>> -if ( size > sizeof(input) )
>>> +if ( size > sizeof(struct fuzz_corpus) )
>> 
>> What's the difference between the two variants?
>
>One fewer 'dereferences'.  Rather than input -> struct fuzz_corpus ->
>[structure definition], you can just do struct fuzz_corpus -> [structure
>definition].

;-)

>>> @@ -916,25 +1043,24 @@ int LLVMFuzzerTestOneInput(const uint8_t *data_p, 
>>> size_t size)
>>>  
>>>  memcpy(&input, data_p, size);
>>>  
>>> -state.corpus = &input;
>>> -state.data_num = size;
>>> -
>>> -setup_state(&ctxt);
>>> +setup_fuzz_state(&state[0], data_p, size);
>>> +
>>> +if ( opt_rerun )
>>> +printf("||| INITIAL RUN |||\n");
>>> +
>>> +runtest(&state[0]);
>>>  
>>> -sanitize_input(&ctxt);
>>> +if ( !opt_rerun )
>>> +return 0;
>> 
>> Could I talk you into inverting the condition such that there'll be
>> only a single "return 0" at the end of the function?
>
>Why is that valuable?
>
>If I don't return here, then the rerun code has to be indented, which to
>me makes it slightly more difficult to see that it's identical to the
>state setup & running code above.

Then leave it this way, as being a matter of taste. I generally think that it is
helpful for functions to only have a single "main" return point (i.e. not
counting error paths), for readers to easily see the normal flow.

>> And then - has this patch actually helped pinpoint any problems? The
>> ones deaslt with by the next patch perhaps?
>
>Yes, it helped find the one dealt with in the subsequent patch.
>Surprisingly, it didn't find anything else.
>
>Since the patch represented a non-trivial amount of work, I thought it
>might be useful to include so nobody would have to re-implement it again
>in the future.  But I'd also be happy discarding this patch, as it's
>fairly invasive and I don't expect it to be used very often.

Oh, I'm certainly in favor of keeping this patch. I was rather trying to
understand whether with it in use the main (or all?) source(s) of instability
were found (and taken care of).

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 113974

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

version targeted for testing:
 qemuu5456c6a4ec9cd8fc314ddc303e88bf85c110975c
baseline version:
 qemuud147f7e815f97cb477e223586bcb80c316ae10ea

Last test of basis   113974  2017-10-03 21:49:11 Z2 days
Testing same since   114042  2017-10-05 12:15:47 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Peter Xu 
  Stefan Hajnoczi 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64

Re: [Xen-devel] [PATCH v3 5/9] x86/vvmx: make updating shadow EPTP value more efficient

[Nakajima, Jun]

On 10/5/17, 6:13 AM, "Andrew Cooper" wrote:

On 05/10/17 14:04, Sergey Dyasli wrote:
> On Thu, 2017-10-05 at 03:27 -0600, Jan Beulich wrote:
> On 05.10.17 at 10:18,  wrote:
>>> --- a/xen/arch/x86/hvm/vmx/entry.S
>>> +++ b/xen/arch/x86/hvm/vmx/entry.S
>>> @@ -80,7 +80,7 @@ UNLIKELY_END(realmode)
>>>  mov  %rsp,%rdi
>>>  call vmx_vmenter_helper
>>>  cmp  $0,%eax
>>> -jne .Lvmx_vmentry_restart
>>> +je .Lvmx_vmentry_restart
>> If you make the function return bool, the cmp above also needs
>> changing (and then preferably to "test %al, %al", in which case
>> it would then also better be "jz" instead of "je").
> Here's the updated delta:
>
> diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
> index 9fb8f89220..47cd674260 100644
> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -79,8 +79,8 @@ UNLIKELY_END(realmode)
>  
>  mov  %rsp,%rdi
>  call vmx_vmenter_helper
> -cmp  $0,%eax
> -jne .Lvmx_vmentry_restart
> +test %al, %al
> +jz .Lvmx_vmentry_restart
>  mov  VCPU_hvm_guest_cr2(%rbx),%rax
>  
>  pop  %r15
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index c9a4111267..a5c2bd71cd 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4197,7 +4197,8 @@ static void lbr_fixup(void)
>  bdw_erratum_bdf14_fixup();
>  }
>  
> -int vmx_vmenter_helper(const struct cpu_user_regs *regs)
> +/* Returns false if the vmentry has to be restarted */
> +bool vmx_vmenter_helper(const struct cpu_user_regs *regs)
>  {
>  struct vcpu *curr = current;
>  u32 new_asid, old_asid;
> @@ -4206,7 +4207,7 @@ int vmx_vmenter_helper(const struct cpu_user_regs 
*regs)
>  
>  /* Shadow EPTP can't be updated here because irqs are disabled */
>   if ( nestedhvm_vcpu_in_guestmode(curr) && 
vcpu_nestedhvm(curr).stale_np2m )
> - return 1;
> + return false;
>  
>  if ( curr->domain->arch.hvm_domain.pi_ops.do_resume )
>  curr->domain->arch.hvm_domain.pi_ops.do_resume(curr);
> @@ -4269,7 +4270,7 @@ int vmx_vmenter_helper(const struct cpu_user_regs 
*regs)
>  __vmwrite(GUEST_RSP,regs->rsp);
>  __vmwrite(GUEST_RFLAGS, regs->rflags | X86_EFLAGS_MBS);
>  
> -return 0;
> +return true;
>  }

With this, the whole series is Acked-by: Andrew Cooper


Acked-by: Jun Nakajima 
  
---
Jun
Intel Open Source Technology Center
 


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

[Xen-devel] [xen-unstable-smoke test] 114056: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972

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

version targeted for testing:
 xen  2b668a84e52a8999d93c438fb259ddf0ec0f62fe
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z2 days
Failing since113979  2017-10-04 00:10:13 Z2 days   28 attempts
Testing same since   114047  2017-10-05 16:08:51 Z0 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  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 fail



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

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

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

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


Not pushing.

(No revision log; it would be 653 lines long.)

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

[Xen-devel] [qemu-upstream-4.8-testing test] 114038: regressions - FAIL

[osstest service owner]

flight 114038 qemu-upstream-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114038/

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 114019

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

version targeted for testing:
 qemuu1ebb5a1c9894bac00c213050f2fc45c8c28fb407
baseline version:
 qemuu29383f4fb3c266d1ffcf627bb8329ab60cf4b6a6

Last test of basis   111049  2017-06-25 03:50:19 Z  103 days
Testing same since   114019  2017-10-04 18:47:39 Z1 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

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

[Xen-devel] [qemu-upstream-unstable baseline-only test] 72204: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72204 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72204/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
72142

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail blocked in 72142
 test-armhf-armhf-libvirt14 saverestore-support-check fail blocked in 72142
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail blocked in 72142
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 72142
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 72142
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu7434775abf8fb2ca3b9e805d30656f4da8c08816
baseline version:
 qemuu0b157f8d977a9425e2d8d510aa011c5d4f3ec247

Last test of basis72142  2017-09-22 11:44:49 Z   13 days
Testing same since72204  2017-10-05 21:25:26 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

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

[Xen-devel] [linux-4.9 test] 114036: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 113872

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

version targeted for testing:
 linux1852eae92c460813692808234da35d142a405ab7
baseline version:
 linuxd59dabdc4cb380b79c965af28cd4ba001f04834b

Last test of basis   113872  2017-09-28 01:48:13 Z8 days
Testing same since   114036  2017-10-05 08:21:13 Z0 days1 attempts


People who touched revisions under test:
  Alex Deucher 
  Andreas Gruenbacher 
  Andrew Donnellan 
  Andrii Anisov 
  Avraham Stern 
  Bartlomiej Zolnierkiewicz 
  Beni Lev 
  Bjorn Helgaas 
  Bo Yan 
  Bob Peterson 
  Boqun Feng 
  Catalin Marinas 
  Chris Leech 
  Christoph Hellwig 
  Christophe Leroy 
  Darrick J. Wong 
  Dave Hansen 
  David Howells 
  David Sterba 
  Dennis Yang 
  Doug Ledford 
  Eric Biggers 
  Frederic Barrat 
  Gerald Schaefer 
  Greg Kroah-Hartman 
  Gustavo Romero 
  Haozhong Zhang 
  Herbert Xu 
  Ingo Molnar 
  Jan H. Schönherr 
  Jason A. Donenfeld 
  Jens Axboe 
  Jim Mattson 
  Johannes Berg 
  John Ogness 
  Kees Cook 
  Konrad Rzeszutek Wilk 
  Laurent Dufour 
  LEROY Christophe 
  Linus Torvalds 
  Longpeng (Mike) 
  Luca Coelho 
  Lucas Stach 
  Marc Zyngier 
  Mark Rutland 
  Martin K. Petersen 
  Martin Schwidefsky 
  Michael Ellerman 
  Myungho Jung 
  Naohiro Aot

[Xen-devel] [xen-unstable-smoke test] 114054: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972

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

version targeted for testing:
 xen  2b668a84e52a8999d93c438fb259ddf0ec0f62fe
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z2 days
Failing since113979  2017-10-04 00:10:13 Z2 days   27 attempts
Testing same since   114047  2017-10-05 16:08:51 Z0 days4 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  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 fail



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

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

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

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


Not pushing.

(No revision log; it would be 653 lines long.)

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

[Xen-devel] [linux-3.18 test] 114034: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 113869

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

version targeted for testing:
 linuxffc97d4dde1d3c77beebddbbd2a0be5f8f18236a
baseline version:
 linux0e13335254d5d54933969dba1d7625f55e657f52

Last test of basis   113869  2017-09-27 22:27:47 Z8 days
Testing same since   114034  2017-10-05 07:56:53 Z0 days1 attempts


People who touched revisions under test:
  Andreas Gruenbacher 
  Andrii Anisov 
  Arnd Bergmann 
  Avraham Stern 
  Bartlomiej Zolnierkiewicz 
  Bjorn Helgaas 
  Bo Yan 
  Catalin Marinas 
  Chris Leech 
  Christoph Hellwig 
  Christophe Leroy 
  Dave Hansen 
  David Howells 
  David Sterba 
  Eric Biggers 
  Greg Kroah-Hartman 
  Herbert Xu 
  Ingo Molnar 
  Jens Axboe 
  Jim Mattson 
  Johannes Berg 
  Konrad Rzeszutek Wilk 
  LEROY Christophe 
  Linus Torvalds 
  Luca Coelho 
  Marc Zyngier 
  Mark Rutland 
  Martin K. Petersen 
  Michael Ellerman 
  Nicolai Stange 
  Oleksandr Dmytryshyn 
  Paolo Bonzini 
  Paul Mackerras 
  Satoru Takeuchi 
  Shu Wang 
  Stefan Metzmacher 
  Stefano Stabellini 
  Steve French 
  Steven Rostedt (VMware) 
  Tahsin Erdogan 
  Tyrel Datwyler 
  Vladis Dronov 
  Will Deacon 
  Xin Long 

job

[Xen-devel] [qemu-upstream-4.7-testing baseline-only test] 72202: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72202 qemu-upstream-4.7-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72202/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-intel 18 capture-logs/l1(18) fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 17 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass

version targeted for testing:
 qemuuc21d63ec23de80b267cd34f887b229b3763ffc47
baseline version:
 qemuucdba5ba9710255e14b5652eca17a62f32f435b86

Last test of basis71605  2017-06-27 09:48:01 Z  100 days
Testing same since72202  2017-10-05 08:20:01 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

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

[Xen-devel] [xen-unstable-smoke test] 114053: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972

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

version targeted for testing:
 xen  2b668a84e52a8999d93c438fb259ddf0ec0f62fe
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z2 days
Failing since113979  2017-10-04 00:10:13 Z1 days   26 attempts
Testing same since   114047  2017-10-05 16:08:51 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  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 fail



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

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

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

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


Not pushing.

(No revision log; it would be 653 lines long.)

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  000e95045595ab5fd974e08dcc71b70a491965ed
baseline version:
 libvirt  4ddb4bb861e90170e1354195b11337abd009f6a4

Last test of basis   113990  2017-10-04 04:30:10 Z1 days
Testing same since   114030  2017-10-05 04:20:21 Z0 days1 attempts


People who touched revisions under test:
  Daniel Veillard 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Kothapally Madhu Pavan 
  Lin Ma 
  Luyao Huang 
  Michal Privoznik 
  Pavel Hrdina 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=000e95045595ab5fd974e08dcc71b70a491965ed
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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-pus

Re: [Xen-devel] PROBLEM: Kernel BUG with raid5 soft + Xen + DRBD - invalid opcode

[MasterPrenium]

Hi Shaohua,

It seems this patch fixed my issue ! Had the issue remaining in 4.13.3, 
after patched with the following patch, issue seems to be gone. I can't 
reproduce it anymore.


Thanks anyway ;)

From: Shaohua Li

commit 3664847d95e60a9a943858b7800f8484669740fc upstream.

We have a race condition in below scenario, say have 3 continuous stripes, sh1,
sh2 and sh3, sh1 is the stripe_head of sh2 and sh3:

CPU1CPU2CPU3
handle_stripe(sh3)
stripe_add_to_batch_list(sh3)
-> lock(sh2, sh3)
-> lock batch_lock(sh1)
-> add sh3 to batch_list of sh1
-> unlock batch_lock(sh1)

clear_batch_ready(sh1)
-> lock(sh1) 
and batch_lock(sh1)
-> clear 
STRIPE_BATCH_READY for all stripes in batch_list
-> unlock(sh1) 
and batch_lock(sh1)
->clear_batch_ready(sh3)
-->test_and_clear_bit(STRIPE_BATCH_READY, sh3)
--->return 0 as sh->batch == NULL
-> sh3->batch_head = sh1
-> unlock (sh2, sh3)

In CPU1, handle_stripe will continue handle sh3 even it's in batch stripe list
of sh1. By moving sh3->batch_head assignment in to batch_lock, we make it
impossible to clear STRIPE_BATCH_READY before batch_head is set.

Thanks Stephane for helping debug this tricky issue.

Reported-and-tested-by: Stephane Thiell
Signed-off-by: Shaohua Li
Signed-off-by: Greg Kroah-Hartman

---
 drivers/md/raid5.c |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -812,6 +812,14 @@ static void stripe_add_to_batch_list(str
spin_unlock(&head->batch_head->batch_lock);
goto unlock_out;
}
+   /*
+* We must assign batch_head of this stripe within the
+* batch_lock, otherwise clear_batch_ready of batch head
+* stripe could clear BATCH_READY bit of this stripe and
+* this stripe->batch_head doesn't get assigned, which
+* could confuse clear_batch_ready for this stripe
+*/
+   sh->batch_head = head->batch_head;
 
 		/*

 * at this point, head's BATCH_READY could be cleared, but we
@@ -819,8 +827,6 @@ static void stripe_add_to_batch_list(str
 */
list_add(&sh->batch_list, &head->batch_list);
spin_unlock(&head->batch_head->batch_lock);
-
-   sh->batch_head = head->batch_head;
} else {
head->batch_head = head;
sh->batch_head = head->batch_head;


Le 09/01/2017 à 23:44, Shaohua Li a écrit :

On Sun, Jan 08, 2017 at 02:31:15PM +0100, MasterPrenium wrote:

Hello,

Replies below + :
- I don't know if this can help but after the crash, when the system
reboots, the Raid 5 stack is re-synchronizing
[   37.028239] md10: Warning: Device sdc1 is misaligned
[   37.028541] created bitmap (15 pages) for device md10
[   37.030433] md10: bitmap initialized from disk: read 1 pages, set 59 of
29807 bits

- Sometimes the kernel completely crash (lost serial + network connection),
sometimes only got the "BUG" dump, but still have network access (but a
reboot is impossible, need to reset the system).

- You can find blktrace here (while running fio), I hope it's complete since
the end of the file is when the kernel crashed : https://goo.gl/X9jZ50

Looks most are normal full stripe writes.
  

I'm trying to reproduce, but no success. So
ext4->btrfs->raid5, crash
btrfs->raid5, no crash
right? does subvolume matter? When you create the raid5 array, does adding
'--assume-clean' option change the behavior? I'd like to narrow down the issue.
If you can capture the blktrace to the raid5 array, it would be great to hint
us what kind of IO it is.

Yes Correct.
The subvolume doesn't matter.
-- assume-clean doesn't change the behaviour.

so it's not a resync issue.


Don't forget that the system needs to be running on xen to crash, without
(on native kernel) it doesn't crash (or at least, I was not able to make it
crash).

Regarding your patch, I can't find it. Is it the one sent by Konstantin
Khlebnikov ?

Right.

It doesn't help :(. Maybe the crash is happening a little bit later.

ok, the patch is unlikely helpful, since the IO size isn't very big.

Don't have good idea yet. My best guess so far is virtual machine introduces
extra delay, which might trigger some race conditions which aren't seen in
native.  I'll check if I could find something locally.

Thanks,
Shaohua

Re: [Xen-devel] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.1~B

[Sebastian Andrzej Siewior]

On 2017-10-05 12:58:32 [-0700], Stefano Stabellini wrote:
> Let me know if you want this patch to go via the xen tree.
Yes, please.

Sebastian

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

[Xen-devel] [xen-unstable-smoke test] 114049: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972

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

version targeted for testing:
 xen  2b668a84e52a8999d93c438fb259ddf0ec0f62fe
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z1 days
Failing since113979  2017-10-04 00:10:13 Z1 days   25 attempts
Testing same since   114047  2017-10-05 16:08:51 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  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 fail



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

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

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

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


Not pushing.

(No revision log; it would be 653 lines long.)

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

[Xen-devel] [qemu-upstream-unstable test] 114029: tolerable FAIL - PUSHED

[osstest service owner]

flight 114029 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114029/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 114014 pass 
in 114029
 test-armhf-armhf-xl-rtds  7 xen-boot   fail pass in 114014

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 114014 like 
113699
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 114014 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 114014 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113668
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113699
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113699
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu7434775abf8fb2ca3b9e805d30656f4da8c08816
baseline version:
 qemuu0b157f8d977a9425e2d8d510aa011c5d4f3ec247

Last test of basis   113699  2017-09-22 00:47:51 Z   13 days
Testing same since   114014  2017-10-04 17:49:35 Z1 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 te

Re: [Xen-devel] [PATCH 11/13] x86/paravirt: Add paravirt alternatives infrastructure

[Boris Ostrovsky]

>  #ifdef CONFIG_PARAVIRT
> +/*
> + * Paravirt alternatives are applied much earlier than normal alternatives.
> + * They are only applied when running on a hypervisor.  They replace some
> + * native instructions with calls to pv ops.
> + */
> +void __init apply_pv_alternatives(void)
> +{
> + setup_force_cpu_cap(X86_FEATURE_PV_OPS);

Not for Xen HVM guests.

> + apply_alternatives(__pv_alt_instructions, __pv_alt_instructions_end);
> +}


This is a problem (at least for Xen PV guests):
apply_alternatives()->text_poke_early()->local_irq_save()->...'cli'->death.

It might be possible not to turn off/on the interrupts in this
particular case since the guest probably won't be able to handle an
interrupt at this point anyway.


> +
>  void __init_or_module apply_paravirt(struct paravirt_patch_site *start,
>struct paravirt_patch_site *end)
>  {
> diff --git a/arch/x86/kernel/cpu/hypervisor.c 
> b/arch/x86/kernel/cpu/hypervisor.c
> index 4fa90006ac68..17243fe0f5ce 100644
> --- a/arch/x86/kernel/cpu/hypervisor.c
> +++ b/arch/x86/kernel/cpu/hypervisor.c
> @@ -71,6 +71,8 @@ void __init init_hypervisor_platform(void)
>   if (!x86_hyper)
>   return;
>  
> + apply_pv_alternatives();

Not for Xen PV guests who have already done this.

-boris


> +
>   if (x86_hyper->init_platform)
>   x86_hyper->init_platform();
>  }
>


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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 linux42b76d0e6b1fe0fcb90e0ff6b4d053d50597b031
baseline version:
 linuxd81fa669e3de7eb8a631d7d95dac5fbcb2bf9d4e

Last test of basis   113982  2017-10-04 01:01:34 Z1 days
Failing since114012  2017-10-04 17:20:45 Z1 days2 attempts
Testing same since   114027  2017-10-05 03:22:29 Z0 days1 attempts


People who touched revisions under test:
  Alexandre Belloni 
  Alexandre Bounine 
  Alexandre Torgue 
  Alexandru Moise <00moses.alexande...@gmail.com>
  Andrea Arcangeli 
  Andrei Vagin 
  Andrew F. Davis 
  Andrew Morton 
  Arnd Bergmann 
  Artem Savkov 
  Arve Hjønnevåg 
  Baruch Siach 
  Casey Schaufler 
  Christophe Leroy 
  Claudiu Beznea 
  Colin Ian King 
  Cyrill Gorcunov 
  Cyrill Gorcunov 
  Davidlohr Bueso 
  Davidlohr Bueso 
  Eric Biggers 
  Eugeniy Paltsev 
  Frank Kunz 
  Geert Uytterhoeven 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Gregory CLEMENT 
  H. Nikolaus Schaller 
  Heiko Stuebner 
  Ingo Molnar 
  Ioan Nicu 
  Jacopo Mondi 
  Jakub Kicinski 
  James Hogan 
  James Morris 
  Jean Delvare 
  Jeff Layton 
  Jerome Brunet 
  Joe Perches 
  Johannes Thumshirn 
  Johannes Weiner 
  Jérôme Glisse 
  Karthik Tummala 
  Keerthy 
  Kees Cook 
  Kevin Hilman 
  Kirill A. S

Re: [Xen-devel] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.1~B

[Stefano Stabellini]

On Thu, 5 Oct 2017, Sebastian Andrzej Siewior wrote:
> rwlock.h should not be included directly. Instead linux/splinlock.h
> should be included. One thing it does is to break the RT build.
> 
> Cc: Stefano Stabellini 
> Cc: xen-de...@lists.xenproject.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Sebastian Andrzej Siewior 

Reviewed-by: Stefano Stabellini 

Let me know if you want this patch to go via the xen tree.

> ---
>  arch/arm/xen/p2m.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
> index e71eefa2e427..0641ba54ab62 100644
> --- a/arch/arm/xen/p2m.c
> +++ b/arch/arm/xen/p2m.c
> @@ -1,7 +1,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.14.2
> 

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

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 72200: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72200 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72200/

Regressions :-(

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

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

version targeted for testing:
 qemuu9e879690ecc702c271fda4cb48663bb83fdf1832
baseline version:
 qemuu4e35ab1edd74b7d24b7a4aaebe75fe68222a2f2b

Last test of basis71608  2017-06-27 16:47:26 Z  100 days
Testing same since72200  2017-10-05 06:46:10 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-d

[Xen-devel] [distros-debian-wheezy test] 72201: tolerable trouble: broken/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 build-arm64   2 hosts-allocate   broken like 72167
 build-arm64-pvops 2 hosts-allocate   broken like 72167
 build-arm64   3 capture-logs broken like 72167
 build-arm64-pvops 3 capture-logs broken like 72167

baseline version:
 flight   72167

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


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

Re: [Xen-devel] [PATCH v2 9/9] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

[Razvan Cojocaru]

On 10/05/2017 08:42 PM, Julien Grall wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
> 
> So make __page_to_mfn and __mfn_to_page return mfn_t by default.
> 
> Only reasonable clean-ups are done in this patch because it is
> already quite big. So some of the files now override page_to_mfn and
> mfn_to_page to avoid using mfn_t.
> 
> Lastly, domain_page_to_mfn is also converted to use mfn_t given that
> most of the callers are now switched to _mfn(domain_page_to_mfn(...)).
> 
> Signed-off-by: Julien Grall 

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

[Xen-devel] [PATCH for-4.10 2/5] tools/dombuilder: Remove clear_page() from xc_dom_boot.c

[Andrew Cooper]

pfn 0 is a legitimate (albeit unlikely) frame to use for translated domains,
so skipping it is wrong.  (This behaviour appears to exists simply to cover
the fact that zero is the default value of an uninitialised field in dom.)

ARM already clears the frames at the point that the pfns are allocated,
meaning that the added clear_page() is wasteful.  Alter x86 to match ARM and
clear the page when it is allocated.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libxc/xc_dom_arm.c  |  3 ++-
 tools/libxc/xc_dom_boot.c | 26 --
 tools/libxc/xc_dom_x86.c  |  8 
 3 files changed, 10 insertions(+), 27 deletions(-)

diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 98200ae..2aeb287 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -91,7 +91,8 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
MEMACCESS_PFN_OFFSET);
-xc_clear_domain_page(dom->xch, dom->guest_domid, base + VUART_PFN_OFFSET);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->vuart_gfn);
+
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
 dom->console_pfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 8a376d0..ce3c22e 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -62,25 +62,6 @@ static int setup_hypercall_page(struct xc_dom_image *dom)
 return rc;
 }
 
-static int clear_page(struct xc_dom_image *dom, xen_pfn_t pfn)
-{
-xen_pfn_t dst;
-int rc;
-
-if ( pfn == 0 )
-return 0;
-
-dst = xc_dom_p2m(dom, pfn);
-DOMPRINTF("%s: pfn 0x%" PRIpfn ", mfn 0x%" PRIpfn "",
-  __FUNCTION__, pfn, dst);
-rc = xc_clear_domain_page(dom->xch, dom->guest_domid, dst);
-if ( rc != 0 )
-xc_dom_panic(dom->xch, XC_INTERNAL_ERROR,
- "%s: xc_clear_domain_page failed (pfn 0x%" PRIpfn
- ", rc=%d)", __FUNCTION__, pfn, rc);
-return rc;
-}
-
 
 /*  */
 
@@ -222,13 +203,6 @@ int xc_dom_boot_image(struct xc_dom_image *dom)
 if ( (rc = dom->arch_hooks->setup_pgtables(dom)) != 0 )
 return rc;
 
-if ( (rc = clear_page(dom, dom->console_pfn)) != 0 )
-return rc;
-if ( (rc = clear_page(dom, dom->xenstore_pfn)) != 0 )
-return rc;
-if ( (rc = clear_page(dom, dom->vuart_gfn)) != 0 )
-return rc;
-
 /* start info page */
 if ( dom->arch_hooks->start_info )
 dom->arch_hooks->start_info(dom);
diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index 885ca1b..0c80b59 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -543,10 +543,14 @@ static int alloc_magic_pages_pv(struct xc_dom_image *dom)
 dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore");
 if ( dom->xenstore_pfn == INVALID_PFN )
 return -1;
+xc_clear_domain_page(dom->xch, dom->guest_domid,
+ xc_dom_p2m(dom, dom->xenstore_pfn));
 
 dom->console_pfn = xc_dom_alloc_page(dom, "console");
 if ( dom->console_pfn == INVALID_PFN )
 return -1;
+xc_clear_domain_page(dom->xch, dom->guest_domid,
+ xc_dom_p2m(dom, dom->console_pfn));
 
 dom->alloc_bootstack = 1;
 
@@ -696,7 +700,11 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
  special_pfn(SPECIALPAGE_IDENT_PT) << PAGE_SHIFT);
 
 dom->console_pfn = special_pfn(SPECIALPAGE_CONSOLE);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
+
 dom->xenstore_pfn = special_pfn(SPECIALPAGE_XENSTORE);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
+
 dom->parms.virt_hypercall = -1;
 
 rc = 0;
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 4/5] tools/dombuilder: Fix asymetry when setting up console and xenstore rings

[Andrew Cooper]

libxl always uses xc_dom_gnttab_init(), which internally calls
xc_dom_gnttab{_hvm,}_seed() to set up the grants point at the console and
xenstore rings.  For HVM guests, libxl then asks Xen for the information set
up previously, and calls xc_dom_gnttab_hvm_seed() a second time, which is
wasteful.  ARM construction expects libxl to have set up
dom->{console,xenstore}_evtchn earlier, so only actually functions because of
this second call.

Rationalise everything and make it consistent for all guests.

 1) Users of the domain builder are expected to provide
dom->{console,xenstore}_{evtchn,domid} unconditionally.  This is checked
by setting invalid values in xc_dom_allocate(), and checking in
xc_dom_boot_image().

 2) For x86 HVM and ARM guests, the event channels are given to Xen at the
same time as the ring gfns.  ARM already did this, but x86 is updated to
match.  x86 PV already provides this information in the start_info page.

 3) Libxl is updated to drop all relevent functionality from
hvm_build_set_params(), and behave consistently with PV guests when it
comes to the handling of dom->{console,xenstore}_{evtchn,domid,gfn}.

This removes several redundant hypercalls (including a foreign mapping) from
the x86 HVM and ARM construction paths.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libxc/include/xc_dom.h  | 12 
 tools/libxc/xc_dom_arm.c  |  2 +-
 tools/libxc/xc_dom_boot.c | 36 
 tools/libxc/xc_dom_compat_linux.c |  2 ++
 tools/libxc/xc_dom_core.c |  5 +
 tools/libxc/xc_dom_x86.c  |  4 
 tools/libxl/libxl_dom.c   | 28 ++--
 tools/libxl/libxl_internal.h  |  1 -
 8 files changed, 66 insertions(+), 24 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 80b4fbd..790869b 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -20,6 +20,8 @@
 #include 
 
 #define INVALID_PFN ((xen_pfn_t)-1)
+#define INVALID_EVTCHN (~0u)
+#define INVALID_DOMID  (-1)
 #define X86_HVM_NR_SPECIAL_PAGES8
 #define X86_HVM_END_SPECIAL_REGION  0xff000u
 
@@ -104,10 +106,16 @@ struct xc_dom_image {
  * Details for the toolstack-prepared rings.
  *
  * *_gfn fields are allocated by the domain builder.
+ * *_{evtchn,domid} fields must be provided by the caller.
  */
 xen_pfn_t console_gfn;
 xen_pfn_t xenstore_gfn;
 
+unsigned int console_evtchn;
+unsigned int xenstore_evtchn;
+domid_t console_domid;
+domid_t xenstore_domid;
+
 /*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
@@ -165,10 +173,6 @@ struct xc_dom_image {
 
 /* misc xen domain config stuff */
 unsigned long flags;
-unsigned int console_evtchn;
-unsigned int xenstore_evtchn;
-domid_t console_domid;
-domid_t xenstore_domid;
 xen_pfn_t shared_info_mfn;
 
 xc_interface *xch;
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index c7aa44a..d668df1 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -99,7 +99,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 dom->xenstore_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
 base + MEMACCESS_PFN_OFFSET);
-/* allocated by toolstack */
+
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
 dom->console_evtchn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index a84a95e..8d4fefa 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -163,6 +163,39 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 return ptr;
 }
 
+static int xc_dom_check_required_fields(struct xc_dom_image *dom)
+{
+int rc = 0;
+
+if ( dom->console_evtchn == INVALID_EVTCHN )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->console_evtchn", __func__);
+rc = -1;
+}
+if ( dom->console_domid == INVALID_DOMID )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->console_domid", __func__);
+rc = -1;
+}
+
+if ( dom->xenstore_evtchn == INVALID_EVTCHN )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->xenstore_evtchn", __func__);
+rc = -1;
+}
+if ( dom->xenstore_domid == INVALID_DOMID )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->xenstore_domid", __func__);
+rc = -1;
+}
+
+return rc;
+}
+
 int xc_dom_boot_image(struct xc_dom_image *dom)
 {
 xc_dominfo_t info;
@

[Xen-devel] [PATCH for-4.10 5/5] tools/dombuilder: Prevent failures of xc_dom_gnttab_init()

[Andrew Cooper]

Recent changes in grant table configuration have caused calls to
xc_dom_gnttab_init() to fail if not proceeded with a call to
xc_domain_set_gnttab_limits().  This is backwards from the point of view of
3rd party dombuilder users.

Add max_{grant,maptrack}_frames parameters to struct xc_dom_image, and require
them to be set by callers using xc_dom_gnttab_init().  Libxl, which uses
xc_dom_gnttab_init() itself is updated appropriately.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libxc/include/xc_dom.h |  4 
 tools/libxc/xc_dom_boot.c| 14 ++
 tools/libxc/xc_dom_core.c|  3 +++
 tools/libxl/libxl_dom.c  | 12 ++--
 4 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 790869b..8e673fb 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -116,6 +116,10 @@ struct xc_dom_image {
 domid_t console_domid;
 domid_t xenstore_domid;
 
+/* Grant limit configuration; mandatory if calling xc_dom_gnttab_init(). */
+unsigned int max_grant_frames;
+unsigned int max_maptrack_frames;
+
 /*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 8d4fefa..7cb9e40 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -419,6 +419,20 @@ int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t 
domid,
 
 int xc_dom_gnttab_init(struct xc_dom_image *dom)
 {
+int rc;
+
+if ( dom->max_grant_frames == -1 || dom->max_maptrack_frames == -1 )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set grant limit information", 
__func__);
+return -1;
+}
+
+if ( (rc = xc_domain_set_gnttab_limits(dom->xch, dom->guest_domid,
+   dom->max_grant_frames,
+   dom->max_maptrack_frames)) != 0 )
+return rc;
+
 if ( xc_dom_translated(dom) ) {
 return xc_dom_gnttab_hvm_seed(dom->xch, dom->guest_domid,
   dom->console_gfn, dom->xenstore_gfn,
diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
index 7087c50..d660651 100644
--- a/tools/libxc/xc_dom_core.c
+++ b/tools/libxc/xc_dom_core.c
@@ -784,6 +784,9 @@ struct xc_dom_image *xc_dom_allocate(xc_interface *xch,
 dom->console_domid = INVALID_DOMID;
 dom->xenstore_domid = INVALID_DOMID;
 
+dom->max_grant_frames = -1;
+dom->max_maptrack_frames = -1;
+
 dom->flags = SIF_VIRT_P2M_4TOOLS;
 
 dom->alloc_malloc += sizeof(*dom);
diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
index fcdeef0..fa5319d 100644
--- a/tools/libxl/libxl_dom.c
+++ b/tools/libxl/libxl_dom.c
@@ -358,12 +358,6 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
 return ERROR_FAIL;
 }
 
-if (xc_domain_set_gnttab_limits(ctx->xch, domid, info->max_grant_frames,
-info->max_maptrack_frames) != 0) {
-LOG(ERROR, "Couldn't set grant table limits");
-return ERROR_FAIL;
-}
-
 /*
  * Check if the domain has any CPU or node affinity already. If not, try
  * to build up the latter via automatic NUMA placement. In fact, in case
@@ -815,6 +809,9 @@ int libxl__build_pv(libxl__gc *gc, uint32_t domid,
 dom->xenstore_domid = state->store_domid;
 dom->claim_enabled = libxl_defbool_val(info->claim_mode);
 
+dom->max_grant_frames= info->max_grant_frames;
+dom->max_maptrack_frames = info->max_maptrack_frames;
+
 if (info->num_vnuma_nodes != 0) {
 unsigned int i;
 
@@ -1151,6 +1148,9 @@ int libxl__build_hvm(libxl__gc *gc, uint32_t domid,
 dom->xenstore_evtchn = state->store_port;
 dom->xenstore_domid = state->store_domid;
 
+dom->max_grant_frames= info->max_grant_frames;
+dom->max_maptrack_frames = info->max_maptrack_frames;
+
 /* The params from the configuration file are in Mb, which are then
  * multiplied by 1 Kb. This was then divided off when calling
  * the old xc_hvm_build_target_mem() which then turned them to bytes.
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 1/5] tools/dombuilder: Drop more PVH v1 leftovers

[Andrew Cooper]

alloc_magic_pages() is renamed to alloc_magic_pages_pv() to mirror its
alloc_magic_pages_hvm() counterpart.  Delete a redundant comment, introduce
some newlines clarity, and remove a logically dead allocation of shared info.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libxc/xc_dom_x86.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
index cb68efc..885ca1b 100644
--- a/tools/libxc/xc_dom_x86.c
+++ b/tools/libxc/xc_dom_x86.c
@@ -534,24 +534,20 @@ static int alloc_p2m_list_x86_64(struct xc_dom_image *dom)
 
 /*  */
 
-static int alloc_magic_pages(struct xc_dom_image *dom)
+static int alloc_magic_pages_pv(struct xc_dom_image *dom)
 {
-/* allocate special pages */
 dom->start_info_pfn = xc_dom_alloc_page(dom, "start info");
 if ( dom->start_info_pfn == INVALID_PFN )
 return -1;
+
 dom->xenstore_pfn = xc_dom_alloc_page(dom, "xenstore");
 if ( dom->xenstore_pfn == INVALID_PFN )
 return -1;
+
 dom->console_pfn = xc_dom_alloc_page(dom, "console");
 if ( dom->console_pfn == INVALID_PFN )
 return -1;
-if ( xc_dom_translated(dom) )
-{
-dom->shared_info_pfn = xc_dom_alloc_page(dom, "shared info");
-if ( dom->shared_info_pfn == INVALID_PFN )
-return -1;
-}
+
 dom->alloc_bootstack = 1;
 
 return 0;
@@ -1756,7 +1752,7 @@ static struct xc_dom_arch xc_dom_32_pae = {
 .sizeof_pfn = 4,
 .p2m_base_supported = 0,
 .arch_private_size = sizeof(struct xc_dom_image_x86),
-.alloc_magic_pages = alloc_magic_pages,
+.alloc_magic_pages = alloc_magic_pages_pv,
 .alloc_pgtables = alloc_pgtables_x86_32_pae,
 .alloc_p2m_list = alloc_p2m_list_x86_32,
 .setup_pgtables = setup_pgtables_x86_32_pae,
@@ -1775,7 +1771,7 @@ static struct xc_dom_arch xc_dom_64 = {
 .sizeof_pfn = 8,
 .p2m_base_supported = 1,
 .arch_private_size = sizeof(struct xc_dom_image_x86),
-.alloc_magic_pages = alloc_magic_pages,
+.alloc_magic_pages = alloc_magic_pages_pv,
 .alloc_pgtables = alloc_pgtables_x86_64,
 .alloc_p2m_list = alloc_p2m_list_x86_64,
 .setup_pgtables = setup_pgtables_x86_64,
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 4/5] tools/dombuilder: Fix asymmetry when setting up console and xenstore rings

[Andrew Cooper]

libxl always uses xc_dom_gnttab_init(), which internally calls
xc_dom_gnttab{_hvm,}_seed() to set up the grants point at the console and
xenstore rings.  For HVM guests, libxl then asks Xen for the information set
up previously, and calls xc_dom_gnttab_hvm_seed() a second time, which is
wasteful.  ARM construction expects libxl to have set up
dom->{console,xenstore}_evtchn earlier, so only actually functions because of
this second call.

Rationalise everything and make it consistent for all guests.

 1) Users of the domain builder are expected to provide
dom->{console,xenstore}_{evtchn,domid} unconditionally.  This is checked
by setting invalid values in xc_dom_allocate(), and checking in
xc_dom_boot_image().

 2) For x86 HVM and ARM guests, the event channels are given to Xen at the
same time as the ring gfns.  ARM already did this, but x86 is updated to
match.  x86 PV already provides this information in the start_info page.

 3) Libxl is updated to drop all relevant functionality from
hvm_build_set_params(), and behave consistently with PV guests when it
comes to the handling of dom->{console,xenstore}_{evtchn,domid,gfn}.

This removes several redundant hypercalls (including a foreign mapping) from
the x86 HVM and ARM construction paths.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libxc/include/xc_dom.h  | 12 
 tools/libxc/xc_dom_arm.c  |  2 +-
 tools/libxc/xc_dom_boot.c | 36 
 tools/libxc/xc_dom_compat_linux.c |  2 ++
 tools/libxc/xc_dom_core.c |  5 +
 tools/libxc/xc_dom_x86.c  |  4 
 tools/libxl/libxl_dom.c   | 28 ++--
 tools/libxl/libxl_internal.h  |  1 -
 8 files changed, 66 insertions(+), 24 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 80b4fbd..790869b 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -20,6 +20,8 @@
 #include 
 
 #define INVALID_PFN ((xen_pfn_t)-1)
+#define INVALID_EVTCHN (~0u)
+#define INVALID_DOMID  (-1)
 #define X86_HVM_NR_SPECIAL_PAGES8
 #define X86_HVM_END_SPECIAL_REGION  0xff000u
 
@@ -104,10 +106,16 @@ struct xc_dom_image {
  * Details for the toolstack-prepared rings.
  *
  * *_gfn fields are allocated by the domain builder.
+ * *_{evtchn,domid} fields must be provided by the caller.
  */
 xen_pfn_t console_gfn;
 xen_pfn_t xenstore_gfn;
 
+unsigned int console_evtchn;
+unsigned int xenstore_evtchn;
+domid_t console_domid;
+domid_t xenstore_domid;
+
 /*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
@@ -165,10 +173,6 @@ struct xc_dom_image {
 
 /* misc xen domain config stuff */
 unsigned long flags;
-unsigned int console_evtchn;
-unsigned int xenstore_evtchn;
-domid_t console_domid;
-domid_t xenstore_domid;
 xen_pfn_t shared_info_mfn;
 
 xc_interface *xch;
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index c7aa44a..d668df1 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -99,7 +99,7 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 dom->xenstore_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
 base + MEMACCESS_PFN_OFFSET);
-/* allocated by toolstack */
+
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_EVTCHN,
 dom->console_evtchn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_EVTCHN,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index a84a95e..8d4fefa 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -163,6 +163,39 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 return ptr;
 }
 
+static int xc_dom_check_required_fields(struct xc_dom_image *dom)
+{
+int rc = 0;
+
+if ( dom->console_evtchn == INVALID_EVTCHN )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->console_evtchn", __func__);
+rc = -1;
+}
+if ( dom->console_domid == INVALID_DOMID )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->console_domid", __func__);
+rc = -1;
+}
+
+if ( dom->xenstore_evtchn == INVALID_EVTCHN )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->xenstore_evtchn", __func__);
+rc = -1;
+}
+if ( dom->xenstore_domid == INVALID_DOMID )
+{
+xc_dom_panic(dom->xch, XC_INVALID_PARAM,
+ "%s: Caller didn't set dom->xenstore_domid", __func__);
+rc = -1;
+}
+
+return rc;
+}
+
 int xc_dom_boot_image(struct xc_dom_image *dom)
 {
 xc_dominfo_t info;
@

[Xen-devel] [PATCH for-4.10 0/5] tools/dombuilder: Fixes and improvements to grant handling

[Andrew Cooper]

A git tree version is available:

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

Andrew Cooper (5):
  tools/dombuilder: Drop more PVH v1 leftovers
  tools/dombuilder: Remove clear_page() from xc_dom_boot.c
  tools/dombuilder: Switch to using gfn terminology for console and
xenstore rings
  tools/dombuilder: Fix asymetry when setting up console and xenstore
rings
  tools/dombuilder: Prevent failures of xc_dom_gnttab_init()

 tools/libxc/include/xc_dom.h  |  26 ++--
 tools/libxc/xc_dom_arm.c  |  17 +++---
 tools/libxc/xc_dom_boot.c | 121 +++---
 tools/libxc/xc_dom_compat_linux.c |   6 +-
 tools/libxc/xc_dom_core.c |   8 +++
 tools/libxc/xc_dom_x86.c  |  57 ++
 tools/libxl/libxl_dom.c   |  51 ++--
 tools/libxl/libxl_internal.h  |   1 -
 8 files changed, 165 insertions(+), 122 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH for-4.10 3/5] tools/dombuilder: Switch to using gfn terminology for console and xenstore rings

[Andrew Cooper]

The sole use of xc_dom_translated() and xc_dom_p2m() outside of the domain
builder is for libxl_dom() to translate the console and xenstore pfns back
into useful values.  PV guest pfns are only interesting to the domain builder,
and gfns are the address space used by all other hypercalls.

Renaming the fields in xc_dom_image is deliberate, as it will cause
out-of-tree users of the dombuilder to notice the different semantics.

Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which are all
using gfns despite the existing variable names.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 
---
 tools/libxc/include/xc_dom.h  | 10 +++--
 tools/libxc/xc_dom_arm.c  | 12 +--
 tools/libxc/xc_dom_boot.c | 45 +++
 tools/libxc/xc_dom_compat_linux.c |  4 ++--
 tools/libxc/xc_dom_x86.c  | 45 ---
 tools/libxl/libxl_dom.c   | 11 +++---
 6 files changed, 64 insertions(+), 63 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index 6e06ef1..80b4fbd 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -94,8 +94,6 @@ struct xc_dom_image {
 struct xc_dom_seg devicetree_seg;
 struct xc_dom_seg start_info_seg; /* HVMlite only */
 xen_pfn_t start_info_pfn;
-xen_pfn_t console_pfn;
-xen_pfn_t xenstore_pfn;
 xen_pfn_t shared_info_pfn;
 xen_pfn_t bootstack_pfn;
 xen_pfn_t pfn_alloc_end;
@@ -103,6 +101,14 @@ struct xc_dom_image {
 xen_vaddr_t bsd_symtab_start;
 
 /*
+ * Details for the toolstack-prepared rings.
+ *
+ * *_gfn fields are allocated by the domain builder.
+ */
+xen_pfn_t console_gfn;
+xen_pfn_t xenstore_gfn;
+
+/*
  * initrd parameters as specified in start_info page
  * Depending on capabilities of the booted kernel this may be a virtual
  * address or a pfn. Type is neutral and large enough to hold a virtual
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 2aeb287..c7aa44a 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -84,19 +84,19 @@ static int alloc_magic_pages(struct xc_dom_image *dom)
 if ( rc < 0 )
 return rc;
 
-dom->console_pfn = base + CONSOLE_PFN_OFFSET;
-dom->xenstore_pfn = base + XENSTORE_PFN_OFFSET;
+dom->console_gfn = base + CONSOLE_PFN_OFFSET;
+dom->xenstore_gfn = base + XENSTORE_PFN_OFFSET;
 dom->vuart_gfn = base + VUART_PFN_OFFSET;
 
-xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_pfn);
-xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_pfn);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->console_gfn);
+xc_clear_domain_page(dom->xch, dom->guest_domid, dom->xenstore_gfn);
 xc_clear_domain_page(dom->xch, dom->guest_domid, base + 
MEMACCESS_PFN_OFFSET);
 xc_clear_domain_page(dom->xch, dom->guest_domid, dom->vuart_gfn);
 
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_CONSOLE_PFN,
-dom->console_pfn);
+dom->console_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_STORE_PFN,
-dom->xenstore_pfn);
+dom->xenstore_gfn);
 xc_hvm_param_set(dom->xch, dom->guest_domid, HVM_PARAM_MONITOR_RING_PFN,
 base + MEMACCESS_PFN_OFFSET);
 /* allocated by toolstack */
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index ce3c22e..a84a95e 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -257,24 +257,24 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
domid_t domid)
 }
 
 int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
+   xen_pfn_t console_gfn,
+   xen_pfn_t xenstore_gfn,
domid_t console_domid,
domid_t xenstore_domid)
 {
 
-xen_pfn_t gnttab_gmfn;
+xen_pfn_t gnttab_gfn;
 grant_entry_v1_t *gnttab;
 
-gnttab_gmfn = xc_dom_gnttab_setup(xch, domid);
-if ( gnttab_gmfn == -1 )
+gnttab_gfn = xc_dom_gnttab_setup(xch, domid);
+if ( gnttab_gfn == -1 )
 return -1;
 
 gnttab = xc_map_foreign_range(xch,
   domid,
   PAGE_SIZE,
   PROT_READ|PROT_WRITE,
-  gnttab_gmfn);
+  gnttab_gfn);
 if ( gnttab == NULL )
 {
 xc_dom_panic(xch, XC_INTERNAL_ERROR,
@@ -284,17 +284,17 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return -1;
 }
 
-if ( domid != console_domid  && console_gmfn != -1)
+if ( domid != console_domid  && console_gfn != -1 )
 {
 gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
 g

[Xen-devel] [xen-unstable-smoke test] 114047: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972

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

version targeted for testing:
 xen  2b668a84e52a8999d93c438fb259ddf0ec0f62fe
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z1 days
Failing since113979  2017-10-04 00:10:13 Z1 days   24 attempts
Testing same since   114047  2017-10-05 16:08:51 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  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 fail



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

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

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

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


Not pushing.

(No revision log; it would be 653 lines long.)

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

Re: [Xen-devel] [PATCH v2 9/9] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

[Andrew Cooper]

On 05/10/17 18:42, Julien Grall wrote:
> @@ -1114,7 +1115,7 @@ int arch_set_info_guest(
>  l4_pgentry_t *l4tab;
>  
>  l4tab = 
> map_domain_page(_mfn(pagetable_get_pfn(v->arch.guest_table)));
> -*l4tab = l4e_from_pfn(page_to_mfn(cr3_page),
> +*l4tab = l4e_from_pfn(mfn_x(page_to_mfn(cr3_page)),

Apologies for missing this before.  You can use l4e_from_mfn() and avoid
the unboxing.

Otherwise, Acked-by: Andrew Cooper  
Everything else seems in order (but I've only skimmed it).

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

Re: [Xen-devel] 4.9.52: INFO: task XXX blocked for more than 300 seconds.

[Ankur Arora]

On 2017-10-05 06:20 AM, Konrad Rzeszutek Wilk wrote:

On Wed, Oct 04, 2017 at 08:26:27PM +0200, Philipp Hahn wrote:

Hello,



Adding Ankur to this as I think he saw something similar.

But in the meantime - do you see this with the latest version of Linux?

with linux-4.9.52 running on Debian-Wheezy with Xen-4.1 I observed
several stuck processes: Here is one (truncated) dump of the Linux
kernel messages:


  [] ? __schedule+0x23d/0x6d0
  [] ? bit_wait_timeout+0x90/0x90
  [] ? schedule+0x32/0x80
  [] ? schedule_timeout+0x1ec/0x360
  [] ? __blk_mq_run_hw_queue+0x327/0x3e0* see below
  [] ? xen_clocksource_get_cycles+0x11/0x20
  [] ? bit_wait_timeout+0x90/0x90
  [] ? io_schedule_timeout+0xb4/0x130
  [] ? prepare_to_wait+0x57/0x80
  [] ? bit_wait_io+0x17/0x60
  [] ? __wait_on_bit+0x5c/0x90
  [] ? bit_wait_timeout+0x90/0x90
  [] ? out_of_line_wait_on_bit+0x7e/0xa0
  [] ? autoremove_wake_function+0x40/0x40
  [] ? jbd2_journal_commit_transaction+0xd48/0x17e0 [jbd2]
  [] ? __switch_to+0x2c9/0x720
  [] ? try_to_del_timer_sync+0x4d/0x80
  [] ? kjournald2+0xdd/0x280 [jbd2]
  [] ? wake_up_atomic_t+0x30/0x30
  [] ? commit_timeout+0x10/0x10 [jbd2]
  [] ? kthread+0xf0/0x110
  [] ? __switch_to+0x2c9/0x720
  [] ? kthread_park+0x60/0x60
  [] ? ret_from_fork+0x25/0x30

This looks like this race: https://patchwork.kernel.org/patch/9853443/

Can you dump the output of: cat /sys/block/$xen-frontend-device/mq/*/tags

If you've hit this bug, one or more of the MQs would be wedged and
the nr_free in one or more of the queues would be 0 and will not
change.

Ankur


NMI backtrace for cpu 2
CPU: 2 PID: 35 Comm: khungtaskd Not tainted 4.9.0-ucs105-amd64 #1 Debian 
4.9.30-2A~4.2.0.201709271649
   81331935  0002
  81335e60 0002 8104cb70 8801f0c90e80
  81335f6a 8801f0c90e80 003fffbc 81128048
Call Trace:
  [] ? dump_stack+0x5c/0x77
  [] ? nmi_cpu_backtrace+0x90/0xa0
  [] ? irq_force_complete_move+0x140/0x140
  [] ? nmi_trigger_cpumask_backtrace+0xfa/0x130
  [] ? watchdog+0x2b8/0x330
  [] ? reset_hung_task_detector+0x10/0x10
  [] ? kthread+0xf0/0x110
  [] ? __switch_to+0x2c9/0x720
  [] ? kthread_park+0x60/0x60
  [] ? ret_from_fork+0x25/0x30
Sending NMI from CPU 2 to CPUs 0-1,3:
NMI backtrace for cpu 1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0-ucs105-amd64 #1 Debian 
4.9.30-2A~4.2.0.201709271649
task: 8801f4a02ec0 task.stack: c90040ca4000
RIP: e030:[]  [] 
xen_hypercall_sched_op+0xa/0x20
RSP: e02b:c90040ca7ed0  EFLAGS: 0246
RAX:  RBX: 8801f4a02ec0 RCX: 810013aa
RDX: 81c4ba70 RSI:  RDI: 0001
RBP: 0001 R08:  R09: 
R10: 7ff0 R11: 0246 R12: 
R13:  R14: 8801f4a02ec0 R15: 8801f4a02ec0
FS:  7f23ac595700() GS:8801f5a8() knlGS:
CS:  e033 DS: 002b ES: 002b CR0: 80050033
CR2: 7f52537d6d46 CR3: 0001bba23000 CR4: 2660
Stack:
  8801bb832201 0001 8101b55c 81611ec8
  8801f4a02ec0 0001 810bc280 8801f4a02ec0
  8801f4a02ec0 c0a995961d41240f addce6dcadd009c9 
Call Trace:
  [] ? xen_safe_halt+0xc/0x20
  [] ? default_idle+0x18/0xd0
  [] ? cpu_startup_entry+0x1f0/0x260
Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc 
cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc
NMI backtrace for cpu 3
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.0-ucs105-amd64 #1 Debian 
4.9.30-2A~4.2.0.201709271649
task: 8801f4a24f00 task.stack: c90040cb4000
RIP: e030:[]  [] 
xen_hypercall_sched_op+0xa/0x20
RSP: e02b:c90040cb7ed0  EFLAGS: 0246
RAX:  RBX: 8801f4a24f00 RCX: 810013aa
RDX: 81c4ba70 RSI:  RDI: 0001
RBP: 0003 R08:  R09: 
R10: 7ff0 R11: 0246 R12: 
R13:  R14: 8801f4a24f00 R15: 8801f4a24f00
FS:  7f1a2af19700() GS:8801f5b8() knlGS:
CS:  e033 DS: 002b ES: 002b CR0: 80050033
CR2: 7f4a5416b000 CR3: 0001d83ec000 CR4: 2660
Stack:
  0001 0001 8101b55c 81611ec8
  8801f4a24f00 0003 810bc280 8801f4a24f00
  8801f4a24f00 77816deb133b9979 addce6dcadd009c9 
Call Trace:
  [] ? xen_safe_halt+0xc/0x20
  [] ? default_idle+0x18/0xd0
  [] ? cpu_startup_entry+0x1f0/0x260
Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc cc cc cc 
cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 cc cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc
NMI backtrace for cpu 0
CPU: 0 PID: 0 Comm: swapper/0 

Re: [Xen-devel] [PATCH v2 3/9] xen/x86: mem_sharing: Use copy_domain_page in __mem_sharing_unshare_page

[Tamas K Lengyel]

On Thu, Oct 5, 2017 at 11:42 AM, Julien Grall  wrote:
> The function __mem_sharing_unshare_page contains an open-code version of
> copy_domain_page. Use the function to simplify a bit the code.
>
> At the same time replace _mfn(__page_to_mfn(...)) by page_to_mfn(...)
> given that the file given already provides a typesafe version of page_to_mfn.
>
> Signed-off-by: Julien Grall 

Acked-by: Tamas K Lengyel 

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

Re: [Xen-devel] [PATCH v2 6/9] xen/kexec, kimage: Convert kexec and kimage to use typesafe mfn_t

[Andrew Cooper]

On 05/10/17 18:42, Julien Grall wrote:
> At the same time, correctly align one the prototype changed.
>
> Signed-off-by: Julien Grall 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v2 3/9] xen/x86: mem_sharing: Use copy_domain_page in __mem_sharing_unshare_page

[Andrew Cooper]

On 05/10/17 18:42, Julien Grall wrote:
> The function __mem_sharing_unshare_page contains an open-code version of
> copy_domain_page. Use the function to simplify a bit the code.
>
> At the same time replace _mfn(__page_to_mfn(...)) by page_to_mfn(...)
> given that the file given already provides a typesafe version of page_to_mfn.
>
> Signed-off-by: Julien Grall 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH v2 4/9] xen/x86: Use maddr_to_page and maddr_to_mfn to avoid open-coded >> PAGE_SHIFT

[Julien Grall]

The constructions _mfn(... > PAGE_SHIFT) and mfn_to_page(... >> PAGE_SHIFT)
could respectively be replaced by maddr_to_mfn(...) and
maddr_to_page(...).

Signed-off-by: Julien Grall 
Reviewed-by: Andrew Cooper 

---

Cc: Elena Ufimtseva 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Tim Deegan 
Cc: George Dunlap 

Changes in v2:
- Add Andrew's reviewed-by
---
 xen/arch/x86/debug.c| 2 +-
 xen/arch/x86/mm/shadow/common.c | 2 +-
 xen/arch/x86/mm/shadow/multi.c  | 6 +++---
 xen/common/kimage.c | 6 +++---
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/debug.c b/xen/arch/x86/debug.c
index 1c10b84a16..9159f32db4 100644
--- a/xen/arch/x86/debug.c
+++ b/xen/arch/x86/debug.c
@@ -98,7 +98,7 @@ dbg_pv_va2mfn(dbgva_t vaddr, struct domain *dp, uint64_t 
pgd3val)
 l2_pgentry_t l2e, *l2t;
 l1_pgentry_t l1e, *l1t;
 unsigned long cr3 = (pgd3val ? pgd3val : dp->vcpu[0]->arch.cr3);
-mfn_t mfn = _mfn(cr3 >> PAGE_SHIFT);
+mfn_t mfn = maddr_to_mfn(cr3);
 
 DBGP2("vaddr:%lx domid:%d cr3:%lx pgd3:%lx\n", vaddr, dp->domain_id, 
   cr3, pgd3val);
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index 86186cccdf..f65d2a6523 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -2640,7 +2640,7 @@ static int sh_remove_shadow_via_pointer(struct domain *d, 
mfn_t smfn)
 ASSERT(sh_type_has_up_pointer(d, sp->u.sh.type));
 
 if (sp->up == 0) return 0;
-pmfn = _mfn(sp->up >> PAGE_SHIFT);
+pmfn = maddr_to_mfn(sp->up);
 ASSERT(mfn_valid(pmfn));
 vaddr = map_domain_page(pmfn);
 ASSERT(vaddr);
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 28030acbf6..1e42e1d8ab 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -2425,7 +2425,7 @@ int sh_safe_not_to_sync(struct vcpu *v, mfn_t gl1mfn)
 sp = mfn_to_page(smfn);
 if ( sp->u.sh.count != 1 || !sp->up )
 return 0;
-smfn = _mfn(sp->up >> PAGE_SHIFT);
+smfn = maddr_to_mfn(sp->up);
 ASSERT(mfn_valid(smfn));
 
 #if (SHADOW_PAGING_LEVELS == 4)
@@ -2434,7 +2434,7 @@ int sh_safe_not_to_sync(struct vcpu *v, mfn_t gl1mfn)
 ASSERT(sh_type_has_up_pointer(d, SH_type_l2_shadow));
 if ( sp->u.sh.count != 1 || !sp->up )
 return 0;
-smfn = _mfn(sp->up >> PAGE_SHIFT);
+smfn = maddr_to_mfn(sp->up);
 ASSERT(mfn_valid(smfn));
 
 /* up to l4 */
@@ -2442,7 +2442,7 @@ int sh_safe_not_to_sync(struct vcpu *v, mfn_t gl1mfn)
 if ( sp->u.sh.count != 1
  || !sh_type_has_up_pointer(d, SH_type_l3_64_shadow) || !sp->up )
 return 0;
-smfn = _mfn(sp->up >> PAGE_SHIFT);
+smfn = maddr_to_mfn(sp->up);
 ASSERT(mfn_valid(smfn));
 #endif
 
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index cf624d10fd..ebc71affd1 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -504,7 +504,7 @@ static void kimage_free_entry(kimage_entry_t entry)
 {
 struct page_info *page;
 
-page = mfn_to_page(entry >> PAGE_SHIFT);
+page = maddr_to_page(entry);
 free_domheap_page(page);
 }
 
@@ -636,8 +636,8 @@ static struct page_info *kimage_alloc_page(struct 
kexec_image *image,
 if ( old )
 {
 /* If so move it. */
-mfn_t old_mfn = _mfn(*old >> PAGE_SHIFT);
-mfn_t mfn = _mfn(addr >> PAGE_SHIFT);
+mfn_t old_mfn = maddr_to_mfn(*old);
+mfn_t mfn = maddr_to_mfn(addr);
 
 copy_domain_page(mfn, old_mfn);
 clear_domain_page(old_mfn);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 2/9] xen/arm32: mm: Rework is_xen_heap_page to avoid nameclash

[Julien Grall]

The arm32 version of the function is_xen_heap_page currently define a
variable _mfn. This will lead to a compiler when use typesafe MFN in a
folow-up patch:

called object '_mfn' is not a function or function pointer

Fix it by renaming the local variable _mfn to mfn_.

Signed-off-by: Julien Grall 

---

Cc: Stefano Stabellini 
---
 xen/include/asm-arm/mm.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h
index cd6dfb54b9..737a429409 100644
--- a/xen/include/asm-arm/mm.h
+++ b/xen/include/asm-arm/mm.h
@@ -140,9 +140,9 @@ extern vaddr_t xenheap_virt_start;
 #ifdef CONFIG_ARM_32
 #define is_xen_heap_page(page) is_xen_heap_mfn(page_to_mfn(page))
 #define is_xen_heap_mfn(mfn) ({ \
-unsigned long _mfn = (mfn); \
-(_mfn >= mfn_x(xenheap_mfn_start) &&\
- _mfn < mfn_x(xenheap_mfn_end));\
+unsigned long mfn_ = (mfn); \
+(mfn_ >= mfn_x(xenheap_mfn_start) &&\
+ mfn_ < mfn_x(xenheap_mfn_end));\
 })
 #else
 #define is_xen_heap_page(page) ((page)->count_info & PGC_xen_heap)
-- 
2.11.0


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

[Xen-devel] [PATCH v2 5/9] xen/kimage: Remove defined but unused variables

[Julien Grall]

In the function kimage_alloc_normal_control_page, the variables mfn and
emfn are defined but not used. Remove them.

Signed-off-by: Julien Grall 
Reviewed-by: Andrew Cooper 

---

Cc: Andrew Cooper 

Changes in v3:
- Add Andrew's reviewed-by
---
 xen/common/kimage.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index ebc71affd1..07587896a4 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -310,14 +310,11 @@ static struct page_info *kimage_alloc_normal_control_page(
  * destination page.
  */
 do {
-unsigned long mfn, emfn;
 paddr_t addr, eaddr;
 
 page = kimage_alloc_zeroed_page(memflags);
 if ( !page )
 break;
-mfn   = page_to_mfn(page);
-emfn  = mfn + 1;
 addr  = page_to_maddr(page);
 eaddr = addr + PAGE_SIZE;
 if ( kimage_is_destination_range(image, addr, eaddr) )
-- 
2.11.0


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

[Xen-devel] [PATCH v2 9/9] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

[Julien Grall]

Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn because the
rest of the function use mfn_t.

So make __page_to_mfn and __mfn_to_page return mfn_t by default.

Only reasonable clean-ups are done in this patch because it is
already quite big. So some of the files now override page_to_mfn and
mfn_to_page to avoid using mfn_t.

Lastly, domain_page_to_mfn is also converted to use mfn_t given that
most of the callers are now switched to _mfn(domain_page_to_mfn(...)).

Signed-off-by: Julien Grall 

---

Andrew suggested to drop IS_VALID_PAGE in xen/tmem_xen.h. His comment
was:

"/sigh  This is tautological.  The definition of a "valid mfn" in this
case is one for which we have frametable entry, and by having a struct
page_info in our hands, this is by definition true (unless you have a
wild pointer, at which point your bug is elsewhere).

IS_VALID_PAGE() is only ever used in assertions and never usefully, so
instead I would remove it entirely rather than trying to fix it up."

I can remove the function in a separate patch at the begining of the
series if Konrad (TMEM maintainer) is happy with that.

Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Paul Durrant 
Cc: Boris Ostrovsky 
Cc: Suravee Suthikulpanit 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Gang Wei 
Cc: Shane Wang 

Changes in v2:
- Some part have been moved in separate patch
- Remove one spurious comment
- Convert domain_page_to_mfn to use mfn_t
---
 xen/arch/arm/domain_build.c |  2 --
 xen/arch/arm/kernel.c   |  2 +-
 xen/arch/arm/mem_access.c   |  2 +-
 xen/arch/arm/mm.c   |  8 
 xen/arch/arm/p2m.c  |  8 +---
 xen/arch/x86/cpu/vpmu.c |  4 ++--
 xen/arch/x86/domain.c   | 21 +++--
 xen/arch/x86/domain_page.c  |  6 +++---
 xen/arch/x86/domctl.c   |  2 +-
 xen/arch/x86/hvm/dm.c   |  2 +-
 xen/arch/x86/hvm/dom0_build.c   |  6 +++---
 xen/arch/x86/hvm/hvm.c  | 14 +++---
 xen/arch/x86/hvm/ioreq.c|  6 +++---
 xen/arch/x86/hvm/stdvga.c   |  2 +-
 xen/arch/x86/hvm/svm/svm.c  |  4 ++--
 xen/arch/x86/hvm/viridian.c |  6 +++---
 xen/arch/x86/hvm/vmx/vmcs.c |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c  | 10 +-
 xen/arch/x86/hvm/vmx/vvmx.c |  6 +++---
 xen/arch/x86/mm.c   |  6 --
 xen/arch/x86/mm/guest_walk.c|  6 +++---
 xen/arch/x86/mm/hap/guest_walk.c|  2 +-
 xen/arch/x86/mm/hap/hap.c   |  6 --
 xen/arch/x86/mm/hap/nested_ept.c|  2 +-
 xen/arch/x86/mm/mem_sharing.c   |  5 -
 xen/arch/x86/mm/p2m-ept.c   |  4 
 xen/arch/x86/mm/p2m-pod.c   |  6 --
 xen/arch/x86/mm/p2m.c   |  6 --
 xen/arch/x86/mm/paging.c|  6 --
 xen/arch/x86/mm/shadow/private.h| 16 ++--
 xen/arch/x86/numa.c |  2 +-
 xen/arch/x86/physdev.c  |  2 +-
 xen/arch/x86/pv/callback.c  |  6 --
 xen/arch/x86/pv/descriptor-tables.c | 10 --
 xen/arch/x86/pv/dom0_build.c|  6 ++
 xen/arch/x86/pv/domain.c|  6 --
 xen/arch/x86/pv/emul-gate-op.c  |  6 --
 xen/arch/x86/pv/emul-priv-op.c  | 10 --
 xen/arch/x86/pv/grant_table.c   |  6 --
 xen/arch/x86/pv/mm.c|  2 +-
 xen/arch/x86/pv/ro-page-fault.c |  6 --
 xen/arch/x86/smpboot.c  |  6 --
 xen/arch/x86/tboot.c|  4 ++--
 xen/arch/x86/traps.c|  2 +-
 xen/arch/x86/x86_64/mm.c|  6 ++
 xen/common/domain.c |  4 ++--
 xen/common/grant_table.c|  6 ++
 xen/common/kimage.c |  6 --
 xen/common/memory.c |  6 ++
 xen/common/page_alloc.c |  6 ++
 xen/common/tmem.c   |  2 +-
 xen/common/tmem_xen.c   |  4 
 xen/common/trace.c  |  6 ++
 xen/common/vmap.c   |  9 +
 xen/common/xenoprof.c   |  2 --
 xen/drivers/passthrough/amd/iommu_map.c |  6 ++
 xen/drivers/passthrough/iommu.c |  2 +-
 xen/drivers/passthrough/x86/iommu.c |  2 +-
 xen/include/asm-arm/mm.h| 16 +---
 xen/include/asm-arm/p2m.h   |  4 ++--
 xen/include/asm-x86/mm.h| 12 ++--
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/a

[Xen-devel] [PATCH v2 0/9] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

[Julien Grall]

Hi all,

Most of the users of page_to_mfn and mfn_to_page are either overriding
the macros to make them work with mfn_t or use mfn_x/_mfn becaue the rest
of the function use mfn_t.

So I think it is time to make __page_to_mfn and __mfn_to_page using typesafe
MFN.

The first 8 patches will convert of the code to use typesafe MFN, easing
the tree-wide conversion in patch 8.

Note that this was only build tested it on x86.

Cheers,

Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: Elena Ufimtseva 
Cc: Gang Wei 
Cc: George Dunlap 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Julien Grall 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: Konrad Rzeszutek Wilk 
Cc: Paul Durrant 
Cc: Razvan Cojocaru 
Cc: Shane Wang 
Cc: Stefano Stabellini 
Cc: Suravee Suthikulpanit 
Cc: Tamas K Lengyel 
Cc: Tim Deegan 
Cc: Wei Liu 

Julien Grall (9):
  xen/arm: domain_build: Clean-up insert_11_bank
  xen/arm32: mm: Rework is_xen_heap_page to avoid nameclash
  xen/x86: mem_sharing: Use copy_domain_page in
__mem_sharing_unshare_page
  xen/x86: Use maddr_to_page and maddr_to_mfn to avoid open-coded >>
PAGE_SHIFT
  xen/kimage: Remove defined but unused variables
  xen/kexec,kimage: Convert kexec and kimage to use typesafe mfn_t
  xen/xenoprof: Convert the file to use typesafe MFN
  xen/tmem: Convert the file common/tmem_xen.c to use typesafe MFN
  xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

 xen/arch/arm/domain_build.c | 15 ---
 xen/arch/arm/kernel.c   |  2 +-
 xen/arch/arm/mem_access.c   |  2 +-
 xen/arch/arm/mm.c   |  8 
 xen/arch/arm/p2m.c  |  8 +---
 xen/arch/x86/cpu/vpmu.c |  4 ++--
 xen/arch/x86/debug.c|  2 +-
 xen/arch/x86/domain.c   | 21 +++--
 xen/arch/x86/domain_page.c  |  6 +++---
 xen/arch/x86/domctl.c   |  2 +-
 xen/arch/x86/hvm/dm.c   |  2 +-
 xen/arch/x86/hvm/dom0_build.c   |  6 +++---
 xen/arch/x86/hvm/hvm.c  | 14 +++---
 xen/arch/x86/hvm/ioreq.c|  6 +++---
 xen/arch/x86/hvm/stdvga.c   |  2 +-
 xen/arch/x86/hvm/svm/svm.c  |  4 ++--
 xen/arch/x86/hvm/viridian.c |  6 +++---
 xen/arch/x86/hvm/vmx/vmcs.c |  2 +-
 xen/arch/x86/hvm/vmx/vmx.c  | 10 +-
 xen/arch/x86/hvm/vmx/vvmx.c |  6 +++---
 xen/arch/x86/mm.c   |  6 --
 xen/arch/x86/mm/guest_walk.c|  6 +++---
 xen/arch/x86/mm/hap/guest_walk.c|  2 +-
 xen/arch/x86/mm/hap/hap.c   |  6 --
 xen/arch/x86/mm/hap/nested_ept.c|  2 +-
 xen/arch/x86/mm/mem_sharing.c   | 12 +---
 xen/arch/x86/mm/p2m-ept.c   |  4 
 xen/arch/x86/mm/p2m-pod.c   |  6 --
 xen/arch/x86/mm/p2m.c   |  6 --
 xen/arch/x86/mm/paging.c|  6 --
 xen/arch/x86/mm/shadow/common.c |  2 +-
 xen/arch/x86/mm/shadow/multi.c  |  6 +++---
 xen/arch/x86/mm/shadow/private.h| 16 ++--
 xen/arch/x86/numa.c |  2 +-
 xen/arch/x86/physdev.c  |  2 +-
 xen/arch/x86/pv/callback.c  |  6 --
 xen/arch/x86/pv/descriptor-tables.c | 10 --
 xen/arch/x86/pv/dom0_build.c|  6 ++
 xen/arch/x86/pv/domain.c|  6 --
 xen/arch/x86/pv/emul-gate-op.c  |  6 --
 xen/arch/x86/pv/emul-priv-op.c  | 10 --
 xen/arch/x86/pv/grant_table.c   |  6 --
 xen/arch/x86/pv/mm.c|  2 +-
 xen/arch/x86/pv/ro-page-fault.c |  6 --
 xen/arch/x86/smpboot.c  |  6 --
 xen/arch/x86/tboot.c|  4 ++--
 xen/arch/x86/traps.c|  2 +-
 xen/arch/x86/x86_64/mm.c|  6 ++
 xen/common/domain.c |  4 ++--
 xen/common/grant_table.c|  6 ++
 xen/common/kexec.c  | 16 
 xen/common/kimage.c | 33 +++--
 xen/common/memory.c |  6 ++
 xen/common/page_alloc.c |  6 ++
 xen/common/tmem.c   |  2 +-
 xen/common/tmem_xen.c   | 26 ++
 xen/common/trace.c  |  6 ++
 xen/common/vmap.c   |  9 +
 xen/common/xenoprof.c   | 19 +--
 xen/drivers/passthrough/amd/iommu_map.c |  6 ++
 xen/drivers/passthrough/iommu.c |  2 +-
 xen/drivers/passthrough/x86/iommu.c |  2 +-
 xen/include/asm-arm/mm.h| 22 --
 xen/include/asm-arm/p2m.h   |  4 ++--
 xen/include/asm-x86/mm.h| 12 ++--
 xen/include/asm-x86/p2m.h   |  2 +-
 xen/include/a

[Xen-devel] [PATCH v2 3/9] xen/x86: mem_sharing: Use copy_domain_page in __mem_sharing_unshare_page

[Julien Grall]

The function __mem_sharing_unshare_page contains an open-code version of
copy_domain_page. Use the function to simplify a bit the code.

At the same time replace _mfn(__page_to_mfn(...)) by page_to_mfn(...)
given that the file given already provides a typesafe version of page_to_mfn.

Signed-off-by: Julien Grall 

---

Cc: Tamas K Lengyel 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes in v2:
- New patch
---
 xen/arch/x86/mm/mem_sharing.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index b856028c02..6f4be95515 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -1106,7 +1106,6 @@ int __mem_sharing_unshare_page(struct domain *d,
 p2m_type_t p2mt;
 mfn_t mfn;
 struct page_info *page, *old_page;
-void *s, *t;
 int last_gfn;
 gfn_info_t *gfn_info = NULL;

@@ -1185,11 +1184,7 @@ int __mem_sharing_unshare_page(struct domain *d,
 return -ENOMEM;
 }
 
-s = map_domain_page(_mfn(__page_to_mfn(old_page)));
-t = map_domain_page(_mfn(__page_to_mfn(page)));
-memcpy(t, s, PAGE_SIZE);
-unmap_domain_page(s);
-unmap_domain_page(t);
+copy_domain_page(page_to_mfn(page), page_to_mfn(old_page));
 
 BUG_ON(set_shared_p2m_entry(d, gfn, page_to_mfn(page)));
 mem_sharing_gfn_destroy(old_page, d, gfn_info);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 8/9] xen/tmem: Convert the file common/tmem_xen.c to use typesafe MFN

[Julien Grall]

The file common/tmem_xen.c is now converted to use typesafe. This is
requiring to override the macro page_to_mfn to make it work with mfn_t.

Note that all variables converted to mfn_t havem there initial value,
when set, switch from 0 to INVALID_MFN. This is fine because the initial
values was always overriden before used.

Also add a couple of missing newlines suggested by Andrew in the code.

Signed-off-by: Julien Grall 
Reviewed-by: Andrew Cooper 

---

Cc: Konrad Rzeszutek Wilk 

Changes in v2:
- Add missing newlines
- Add Andrew's reviewed-by
---
 xen/common/tmem_xen.c | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/xen/common/tmem_xen.c b/xen/common/tmem_xen.c
index 20f74b268f..bd52e44faf 100644
--- a/xen/common/tmem_xen.c
+++ b/xen/common/tmem_xen.c
@@ -14,6 +14,10 @@
 #include 
 #include 
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef page_to_mfn
+#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
+
 bool __read_mostly opt_tmem;
 boolean_param("tmem", opt_tmem);
 
@@ -31,7 +35,7 @@ static DEFINE_PER_CPU_READ_MOSTLY(unsigned char *, dstmem);
 static DEFINE_PER_CPU_READ_MOSTLY(void *, scratch_page);
 
 #if defined(CONFIG_ARM)
-static inline void *cli_get_page(xen_pfn_t cmfn, unsigned long *pcli_mfn,
+static inline void *cli_get_page(xen_pfn_t cmfn, mfn_t *pcli_mfn,
  struct page_info **pcli_pfp, bool cli_write)
 {
 ASSERT_UNREACHABLE();
@@ -39,14 +43,14 @@ static inline void *cli_get_page(xen_pfn_t cmfn, unsigned 
long *pcli_mfn,
 }
 
 static inline void cli_put_page(void *cli_va, struct page_info *cli_pfp,
-unsigned long cli_mfn, bool mark_dirty)
+mfn_t cli_mfn, bool mark_dirty)
 {
 ASSERT_UNREACHABLE();
 }
 #else
 #include 
 
-static inline void *cli_get_page(xen_pfn_t cmfn, unsigned long *pcli_mfn,
+static inline void *cli_get_page(xen_pfn_t cmfn, mfn_t *pcli_mfn,
  struct page_info **pcli_pfp, bool cli_write)
 {
 p2m_type_t t;
@@ -68,16 +72,17 @@ static inline void *cli_get_page(xen_pfn_t cmfn, unsigned 
long *pcli_mfn,
 
 *pcli_mfn = page_to_mfn(page);
 *pcli_pfp = page;
-return map_domain_page(_mfn(*pcli_mfn));
+
+return map_domain_page(*pcli_mfn);
 }
 
 static inline void cli_put_page(void *cli_va, struct page_info *cli_pfp,
-unsigned long cli_mfn, bool mark_dirty)
+mfn_t cli_mfn, bool mark_dirty)
 {
 if ( mark_dirty )
 {
 put_page_and_type(cli_pfp);
-paging_mark_dirty(current->domain, _mfn(cli_mfn));
+paging_mark_dirty(current->domain, cli_mfn);
 }
 else
 put_page(cli_pfp);
@@ -88,14 +93,14 @@ static inline void cli_put_page(void *cli_va, struct 
page_info *cli_pfp,
 int tmem_copy_from_client(struct page_info *pfp,
 xen_pfn_t cmfn, tmem_cli_va_param_t clibuf)
 {
-unsigned long tmem_mfn, cli_mfn = 0;
+mfn_t tmem_mfn, cli_mfn = INVALID_MFN;
 char *tmem_va, *cli_va = NULL;
 struct page_info *cli_pfp = NULL;
 int rc = 1;
 
 ASSERT(pfp != NULL);
 tmem_mfn = page_to_mfn(pfp);
-tmem_va = map_domain_page(_mfn(tmem_mfn));
+tmem_va = map_domain_page(tmem_mfn);
 if ( guest_handle_is_null(clibuf) )
 {
 cli_va = cli_get_page(cmfn, &cli_mfn, &cli_pfp, 0);
@@ -125,7 +130,7 @@ int tmem_compress_from_client(xen_pfn_t cmfn,
 unsigned char *wmem = this_cpu(workmem);
 char *scratch = this_cpu(scratch_page);
 struct page_info *cli_pfp = NULL;
-unsigned long cli_mfn = 0;
+mfn_t cli_mfn = INVALID_MFN;
 void *cli_va = NULL;
 
 if ( dmem == NULL || wmem == NULL )
@@ -152,7 +157,7 @@ int tmem_compress_from_client(xen_pfn_t cmfn,
 int tmem_copy_to_client(xen_pfn_t cmfn, struct page_info *pfp,
 tmem_cli_va_param_t clibuf)
 {
-unsigned long tmem_mfn, cli_mfn = 0;
+mfn_t tmem_mfn, cli_mfn = INVALID_MFN;
 char *tmem_va, *cli_va = NULL;
 struct page_info *cli_pfp = NULL;
 int rc = 1;
@@ -165,7 +170,8 @@ int tmem_copy_to_client(xen_pfn_t cmfn, struct page_info 
*pfp,
 return -EFAULT;
 }
 tmem_mfn = page_to_mfn(pfp);
-tmem_va = map_domain_page(_mfn(tmem_mfn));
+tmem_va = map_domain_page(tmem_mfn);
+
 if ( cli_va )
 {
 memcpy(cli_va, tmem_va, PAGE_SIZE);
@@ -181,7 +187,7 @@ int tmem_copy_to_client(xen_pfn_t cmfn, struct page_info 
*pfp,
 int tmem_decompress_to_client(xen_pfn_t cmfn, void *tmem_va,
 size_t size, tmem_cli_va_param_t clibuf)
 {
-unsigned long cli_mfn = 0;
+mfn_t cli_mfn = INVALID_MFN;
 struct page_info *cli_pfp = NULL;
 void *cli_va = NULL;
 char *scratch = this_cpu(scratch_page);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 7/9] xen/xenoprof: Convert the file to use typesafe MFN

[Julien Grall]

The file common/xenoprof.c is now converted to use typesafe. This is
requiring to override the macros virt_to_mfn and mfn_to_page to make
them work with mfn_t.

Also, add a couple of missing newlines in the code modified.

Signed-off-by: Julien Grall 
Reviewed-by: Andrew Cooper 

---

Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v2:
- Add missing newlines
- Add Andrew's reviewed-by
---
 xen/common/xenoprof.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/xen/common/xenoprof.c b/xen/common/xenoprof.c
index a5fe6204a5..5acdde5691 100644
--- a/xen/common/xenoprof.c
+++ b/xen/common/xenoprof.c
@@ -19,6 +19,12 @@
 #include 
 #include 
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef virt_to_mfn
+#define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+#undef mfn_to_page
+#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
+
 /* Limit amount of pages used for shared buffer (per domain) */
 #define MAX_OPROF_SHARED_PAGES 32
 
@@ -134,25 +140,27 @@ static void xenoprof_reset_buf(struct domain *d)
 }
 
 static int
-share_xenoprof_page_with_guest(struct domain *d, unsigned long mfn, int npages)
+share_xenoprof_page_with_guest(struct domain *d, mfn_t mfn, int npages)
 {
 int i;
 
 /* Check if previous page owner has released the page. */
 for ( i = 0; i < npages; i++ )
 {
-struct page_info *page = mfn_to_page(mfn + i);
+struct page_info *page = mfn_to_page(mfn_add(mfn, i));
+
 if ( (page->count_info & (PGC_allocated|PGC_count_mask)) != 0 )
 {
 printk(XENLOG_G_INFO "dom%d mfn %#lx page->count_info %#lx\n",
-   d->domain_id, mfn + i, page->count_info);
+   d->domain_id, mfn_x(mfn_add(mfn, i)), page->count_info);
 return -EBUSY;
 }
 page_set_owner(page, NULL);
 }
 
 for ( i = 0; i < npages; i++ )
-share_xen_page_with_guest(mfn_to_page(mfn + i), d, XENSHARE_writable);
+share_xen_page_with_guest(mfn_to_page(mfn_add(mfn, i)),
+  d, XENSHARE_writable);
 
 return 0;
 }
@@ -161,11 +169,12 @@ static void
 unshare_xenoprof_page_with_guest(struct xenoprof *x)
 {
 int i, npages = x->npages;
-unsigned long mfn = virt_to_mfn(x->rawbuf);
+mfn_t mfn = virt_to_mfn(x->rawbuf);
 
 for ( i = 0; i < npages; i++ )
 {
-struct page_info *page = mfn_to_page(mfn + i);
+struct page_info *page = mfn_to_page(mfn_add(mfn, i));
+
 BUG_ON(page_get_owner(page) != current->domain);
 if ( test_and_clear_bit(_PGC_allocated, &page->count_info) )
 put_page(page);
-- 
2.11.0


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

[Xen-devel] [PATCH v2 1/9] xen/arm: domain_build: Clean-up insert_11_bank

[Julien Grall]

- Remove spurious ()
- Add missing spaces
- Turn 1 << to 1UL <<
- Rename spfn to smfn and switch to mfn_t

Signed-off-by: Julien Grall 

---

Cc: Stefano Stabellini 

Changes in v2:
- Remove double space
- s/spfn/smfn/ and switch to mfn_t
---
 xen/arch/arm/domain_build.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 3723dc3f78..167711b4fa 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -50,6 +50,8 @@ struct map_range_data
 /* Override macros from asm/page.h to make them work with mfn_t */
 #undef virt_to_mfn
 #define virt_to_mfn(va) _mfn(__virt_to_mfn(va))
+#undef page_to_mfn
+#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
 
 //#define DEBUG_11_ALLOCATION
 #ifdef DEBUG_11_ALLOCATION
@@ -104,16 +106,16 @@ static bool insert_11_bank(struct domain *d,
unsigned int order)
 {
 int res, i;
-paddr_t spfn;
+mfn_t smfn;
 paddr_t start, size;
 
-spfn = page_to_mfn(pg);
-start = pfn_to_paddr(spfn);
-size = pfn_to_paddr((1 << order));
+smfn = page_to_mfn(pg);
+start = mfn_to_maddr(smfn);
+size = pfn_to_paddr(1UL << order);
 
 D11PRINT("Allocated %#"PRIpaddr"-%#"PRIpaddr" (%ldMB/%ldMB, order %d)\n",
  start, start + size,
- 1UL << (order+PAGE_SHIFT-20),
+ 1UL << (order + PAGE_SHIFT - 20),
  /* Don't want format this as PRIpaddr (16 digit hex) */
  (unsigned long)(kinfo->unassigned_mem >> 20),
  order);
@@ -126,7 +128,7 @@ static bool insert_11_bank(struct domain *d,
 goto fail;
 }
 
-res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
+res = guest_physmap_add_page(d, _gfn(mfn_x(smfn)), smfn, order);
 if ( res )
 panic("Failed map pages to DOM0: %d", res);
 
@@ -167,7 +169,8 @@ static bool insert_11_bank(struct domain *d,
  */
 if ( start + size < bank->start && kinfo->mem.nr_banks < NR_MEM_BANKS )
 {
-memmove(bank + 1, bank, sizeof(*bank)*(kinfo->mem.nr_banks - i));
+memmove(bank + 1, bank,
+sizeof(*bank) * (kinfo->mem.nr_banks - i));
 kinfo->mem.nr_banks++;
 bank->start = start;
 bank->size = size;
-- 
2.11.0


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

[Xen-devel] [PATCH v2 6/9] xen/kexec, kimage: Convert kexec and kimage to use typesafe mfn_t

[Julien Grall]

At the same time, correctly align one the prototype changed.

Signed-off-by: Julien Grall 
---
 xen/common/kexec.c   | 16 
 xen/common/kimage.c  | 30 ++
 xen/include/xen/kimage.h |  4 ++--
 3 files changed, 28 insertions(+), 22 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index fcc68bd4d8..c14cbb2b9c 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -905,11 +905,11 @@ static uint16_t kexec_load_v1_arch(void)
 #endif
 }
 
-static int kexec_segments_add_segment(
-unsigned int *nr_segments, xen_kexec_segment_t *segments,
-unsigned long mfn)
+static int kexec_segments_add_segment(unsigned int *nr_segments,
+  xen_kexec_segment_t *segments,
+  mfn_t mfn)
 {
-paddr_t maddr = (paddr_t)mfn << PAGE_SHIFT;
+paddr_t maddr = mfn_to_maddr(mfn);
 unsigned int n = *nr_segments;
 
 /* Need a new segment? */
@@ -930,7 +930,7 @@ static int kexec_segments_add_segment(
 return 0;
 }
 
-static int kexec_segments_from_ind_page(unsigned long mfn,
+static int kexec_segments_from_ind_page(mfn_t mfn,
 unsigned int *nr_segments,
 xen_kexec_segment_t *segments,
 bool_t compat)
@@ -939,7 +939,7 @@ static int kexec_segments_from_ind_page(unsigned long mfn,
 kimage_entry_t *entry;
 int ret = 0;
 
-page = map_domain_page(_mfn(mfn));
+page = map_domain_page(mfn);
 
 /*
  * Walk the indirection page list, adding destination pages to the
@@ -961,7 +961,7 @@ static int kexec_segments_from_ind_page(unsigned long mfn,
 break;
 case IND_INDIRECTION:
 unmap_domain_page(page);
-entry = page = map_domain_page(_mfn(mfn));
+entry = page = map_domain_page(mfn);
 continue;
 case IND_DONE:
 goto done;
@@ -990,7 +990,7 @@ static int kexec_do_load_v1(xen_kexec_load_v1_t *load, int 
compat)
 xen_kexec_segment_t *segments;
 uint16_t arch;
 unsigned int nr_segments = 0;
-unsigned long ind_mfn = load->image.indirection_page >> PAGE_SHIFT;
+mfn_t ind_mfn = maddr_to_mfn(load->image.indirection_page);
 int ret;
 
 arch = kexec_load_v1_arch();
diff --git a/xen/common/kimage.c b/xen/common/kimage.c
index 07587896a4..afd8292cc1 100644
--- a/xen/common/kimage.c
+++ b/xen/common/kimage.c
@@ -23,6 +23,12 @@
 
 #include 
 
+/* Override macros from asm/page.h to make them work with mfn_t */
+#undef mfn_to_page
+#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
+#undef page_to_mfn
+#define page_to_mfn(pg)  _mfn(__page_to_mfn(pg))
+
 /*
  * When kexec transitions to the new kernel there is a one-to-one
  * mapping between physical and virtual addresses.  On processors
@@ -76,7 +82,7 @@ static struct page_info *kimage_alloc_zeroed_page(unsigned 
memflags)
 if ( !page )
 return NULL;
 
-clear_domain_page(_mfn(page_to_mfn(page)));
+clear_domain_page(page_to_mfn(page));
 
 return page;
 }
@@ -405,7 +411,7 @@ static struct page_info 
*kimage_alloc_crash_control_page(struct kexec_image *ima
 if ( page )
 {
 image->next_crash_page = hole_end;
-clear_domain_page(_mfn(page_to_mfn(page)));
+clear_domain_page(page_to_mfn(page));
 }
 
 return page;
@@ -641,7 +647,7 @@ static struct page_info *kimage_alloc_page(struct 
kexec_image *image,
 *old = (addr & ~PAGE_MASK) | IND_SOURCE;
 unmap_domain_page(old);
 
-page = mfn_to_page(mfn_x(old_mfn));
+page = mfn_to_page(old_mfn);
 break;
 }
 else
@@ -840,11 +846,11 @@ kimage_entry_t *kimage_entry_next(kimage_entry_t *entry, 
bool_t compat)
 return entry + 1;
 }
 
-unsigned long kimage_entry_mfn(kimage_entry_t *entry, bool_t compat)
+mfn_t kimage_entry_mfn(kimage_entry_t *entry, bool_t compat)
 {
 if ( compat )
-return *(uint32_t *)entry >> PAGE_SHIFT;
-return *entry >> PAGE_SHIFT;
+return maddr_to_mfn(*(uint32_t *)entry);
+return maddr_to_mfn(*entry);
 }
 
 unsigned long kimage_entry_ind(kimage_entry_t *entry, bool_t compat)
@@ -854,7 +860,7 @@ unsigned long kimage_entry_ind(kimage_entry_t *entry, 
bool_t compat)
 return *entry & 0xf;
 }
 
-int kimage_build_ind(struct kexec_image *image, unsigned long ind_mfn,
+int kimage_build_ind(struct kexec_image *image, mfn_t ind_mfn,
  bool_t compat)
 {
 void *page;
@@ -862,7 +868,7 @@ int kimage_build_ind(struct kexec_image *image, unsigned 
long ind_mfn,
 int ret = 0;
 paddr_t dest = KIMAGE_NO_DEST;
 
-page = map_domain_page(_mfn(ind_mfn));
+page = map_domain_page(ind_mfn);
 if ( !page )
 return -ENOMEM;
 
@@ -873,7 +879,7 @@ int kimage_build_ind(struct kexec_image *image, unsigned 
long ind_mfn,
 for ( entry = page; ;  )
 {
   

Re: [Xen-devel] [PATCH] MAINTAINERS: update entries to new email address.

[Stefano Stabellini]

On Thu, 5 Oct 2017, Dario Faggioli wrote:
> Replace, in the 'M:' fields of the components I co-maintain
> ('CPU POOLS', 'SCHEDULING' and 'RTDS SCHEDULER'), the Citrix
> email, to which I don't have access any longer, with my
> personal email.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: Stefano Stabellini 


> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
> ---
>  MAINTAINERS |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 12dbad130c..4d7092324a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -183,7 +183,7 @@ F:tools/blktap2/
>  
>  CPU POOLS
>  M:   Juergen Gross 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/cpupool.c
>  
> @@ -335,14 +335,14 @@ F:  tools/hotplug/Linux/remus-netbuf-setup
>  F:   tools/hotplug/Linux/block-drbd-probe
>  
>  RTDS SCHEDULER
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  M:   Meng Xu 
>  S:   Supported
>  F:   xen/common/sched_rt.c
>  
>  SCHEDULING
>  M:   George Dunlap 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/sched*
>  
> 

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

[Xen-devel] [xen-unstable test] 114024: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-installfail pass in 114003

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

version targeted for testing:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   114024  2017-10-05 01:59:50 Z0 days
Testing same since  (not found) 0 attempts

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  

Re: [Xen-devel] [PATCH] Changing my email address

[Meng Xu]

Hi Dario,

On Thu, Oct 5, 2017 at 10:28 AM, Dario Faggioli  wrote:
>
> Hello,
>
> Soon I won't have access to dario.faggi...@citrix.com email address.

It's sad to hear this. :(

>
> Therefore, replace it, in my entries in MAINTAINERS, with an email address 
> that
> I actually can, and will actually read.
>
> One thing about RTDS. Meng, which one of the following two sentences, better
> describes your situation?
>
>  a) Supported:   Someone is actually paid to look after this.
>  b) Maintained:  Someone actually looks after it.
>
> If it's a (you're currently paied to look after RTDS) then we're fine.

I'm paid to look after RTDS at least before I graduate. :)

Best regards,

Meng

-- 
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v2 12/13] fuzz/x86_emulate: Set and fuzz more CPU state

[George Dunlap]

On 10/04/2017 09:28 AM, Jan Beulich wrote:
 On 25.09.17 at 16:26,  wrote:
>> @@ -597,6 +599,47 @@ static const struct x86_emulate_ops all_fuzzer_ops = {
>>  };
>>  #undef SET
>>  
>> +static void _set_fpu_state(char *fxsave, bool store)
>> +{
>> +if ( cpu_has_fxsr )
>> +{
>> +static union __attribute__((__aligned__(16))) {
>> +char x[464];
> 
> The final part of the save area isn't being written, yes, but is it
> really worth saving the few bytes of stack space here, rather than
> having the expected 512 as array dimension?

So I didn't actually look into this very much; I mainly just hacked at
it until it seemed to work.  I copied-and-pasted emul_test_init() from
x86_emulate.c (which is where the 464 came from), then copied some
scraps of asm from stackoverflow.

>> +struct {
>> +uint32_t other[6];
>> +uint32_t mxcsr;
>> +uint32_t mxcsr_mask;
>> +/* ... */
>> +};
>> +} *fxs;
>> +
>> +fxs = (typeof(fxs)) fxsave;
>> +
>> +if ( store ) {
> 
> Style.
> 
>> +char null[512] __attribute__((aligned(16))) = { 0 };
> 
> No need for the 0 and a blank line between declaration and statements
> please.
> 
>> +asm volatile(" fxrstor %0; "::"m"(*null));
>> +asm volatile(" fxrstor %0; "::"m"(*fxsave));
> 
> Style again - these want to follow the
> 
> asm volatile ( "..." :: "m" (...) )
> 
> form. No need for the ; following the instructions.
>
>> +}
>> +
>> +asm volatile( "fxsave %0" : "=m" (*fxs) );
> 
> This is pretty confusing, the more with the different variable names
> used which point to the same piece of memory. You basically store back
> into the area you've read from. Is the caller expecting the memory area
> to change? Is this being done other than for convenience to not have
> another instance of scratch space on the stack? Some comment on the
> intentions may be helpful here.

Yes, sorry for the different variable names.  I should have done a
better clean-up of this patch.

As for why it's doing an fxsave after just doing an fxrstor: I had the
idea that what came out via fxsave might not be the same as what was
written via fxrstor (i.e., the instruction would "interpret" the data),
particularly as what went in would be completely random fuzzed state.
The idea behind doing the restore / save was to "sanitize" the state in
the state struct to look more like real input data.

> The function's parameter name being "store" adds to the confusion,
> since what it controls is actually what we call "load" on x86 (or
> "restore" following the insn mnemonics).

I chose 'store' as the argument name before I realized that fxrstor was
"fx restore" and not "fxr store".

Do you think 'write' would be suitable?  Names like "restore" or "load"
make sense if you're thinking about things from the processor's
perspective (as the architects certainly were); but they make less sense
from a programmer's perspective, since (to me anyway) it seems like I'm
writing to or reading from the FPU unit (rather than loading/restoring
or saving).

If you don't like 'write' I'll change it to 'restore'.

> And then - what about YMM register state? Other more exotic registers
> (like the BND* ones) may indeed not be that relevant to fuzz yet.

I can look into that if you want, or if you want to give me some runes
to copy in I'm happy to do that as well.

>> @@ -737,6 +780,17 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
>>  printf("Setting cpu_user_regs offset %x\n", offset);
>>  continue;
>>  }
>> +offset -= sizeof(struct cpu_user_regs);
>> +
>> +/* Fuzz fxsave state */
>> +if ( offset < 128 )
>> +{
>> +if ( !input_read(s, s->fxsave + (offset * 4), 4) )
>> +return;
>> +printf("Setting fxsave offset %x\n", offset * 4);
> 
> What's this 32-bit granularity derived from?

Just seemed like a good-sized chunk.  Doing it byte-by-byte seemed to be
"wasting" input on offsets (as in the input you'd have a 2-byte 'offset'
followed by a one-byte bit of data).  This way you have a 2-byte offset
and a 4-byte chunk of data that you write.

Let me know if you think there's a better size for chunks of data to
write.  In any case I'll add a comment in here to let people know that
the size is arbitrary.

>> @@ -883,6 +937,9 @@ static void sanitize_state(struct x86_emulate_ctxt *ctxt)
>>  s->segments[x86_seg_cs].db = 0;
>>  s->segments[x86_seg_ss].db = 0;
>>  }
>> +
>> +/* Setting this value seems to cause crashes in fxrstor */
>> +*((unsigned int *)(s->fxsave) + 6) = 0;
> 
> That's the MXCSR field - instead of storing zero you want to mask with
> mxcsr_mask. To avoid the ugly literal 6 (and to make clear what it is
> that needs adjustment here) it may also be worthwhile widening the
> scope of the type declared in _set

Re: [Xen-devel] [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

[Thomas Garnier]

On Thu, Oct 5, 2017 at 9:11 AM, Steven Rostedt  wrote:
> On Thu, 5 Oct 2017 09:01:14 -0700
> Thomas Garnier  wrote:
>
>> On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt  wrote:
>> > On Wed,  4 Oct 2017 14:19:56 -0700
>> > Thomas Garnier  wrote:
>> >
>> >> When using -fPIE/PIC with function tracing, the compiler generates a
>> >> call through the GOT (call *__fentry__@GOTPCREL). This instruction
>> >> takes 6 bytes instead of 5 on the usual relative call.
>> >>
>> >> With this change, function tracing supports 6 bytes on traceable
>> >> function and can still replace relative calls on the ftrace assembly
>> >> functions.
>> >>
>> >> Position Independent Executable (PIE) support will allow to extended the
>> >> KASLR randomization range below the -2G memory limit.
>> >
>> > Question: This 6 bytes is only the initial call that gcc creates. When
>> > function tracing is enabled, the calls are back to the normal call to
>> > the ftrace trampoline?
>>
>> That is correct.
>>
>
> Then I think a better idea is to simply nop them out at compile time,
> and have the code that updates them to nops to know about it.
>
> See scripts/recordmcount.c
>
> Could we simply add a 5 byte nop followed by a 1 byte nop, and treat it
> the same as if it didn't exist? This code can be a little complex, and
> can cause really nasty side effects if things go wrong. I would like to
> keep from adding more variables to the changes here.

Sure, I will simplify it for the next iteration.

Thanks for the feedback.

>
> -- Steve



-- 
Thomas

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

Re: [Xen-devel] [PATCH v2 11/13] fuzz/x86_emulate: Add --rerun option to try to track down instability

[George Dunlap]

On 10/04/2017 09:27 AM, Jan Beulich wrote:
 On 25.09.17 at 16:26,  wrote:
>> --- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
>> +++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
>> @@ -14,6 +14,7 @@ extern unsigned int fuzz_minimal_input_size(void);
>>  static uint8_t input[INPUT_SIZE];
>>  
>>  extern bool opt_compact;
>> +extern bool opt_rerun;
> 
> Seeing a second such variable appear, I think it would really be better
> to introduce a local header, included by both producer and consumer.

Yes, sounds good.

> 
>> @@ -886,21 +896,138 @@ int LLVMFuzzerInitialize(int *argc, char ***argv)
>>  return 0;
>>  }
>>  
>> -int LLVMFuzzerTestOneInput(const uint8_t *data_p, size_t size)
>> +void setup_fuzz_state(struct fuzz_state *state, const uint8_t *data_p, 
>> size_t size)
> 
> static (also for other new helper functions)?

Ack

> 
>>  {
>> -struct fuzz_state state = {
>> -.ops = all_fuzzer_ops,
>> -};
>> -struct x86_emulate_ctxt ctxt = {
>> -.data = &state,
>> -.regs = &state.regs,
>> -.addr_size = 8 * sizeof(void *),
>> -.sp_size = 8 * sizeof(void *),
>> -};
>> +memset(state, 0, sizeof(*state));
>> +state->corpus = (struct fuzz_corpus *)data_p;
> 
> Please don't cast away constness here. Perhaps best to make the parameter
> const void *, allowing for the cast to be dropped altogether.

Didn't notice that I was casting away const-ness, because state->corpus
is const. :-)  But I like `const void *`.

> 
>> +int runtest(struct fuzz_state *state) {
>>  int rc;
>>  
>> -/* Reset all global state variables */
>> -memset(&input, 0, sizeof(input));
>> +struct x86_emulate_ctxt *ctxt = &state->ctxt;
>> +
>> +state->ops = all_fuzzer_ops;
>> +
>> +ctxt->data = state;
>> +ctxt->regs = &state->regs;
>> +ctxt->addr_size = ctxt->sp_size = 8 * sizeof(void *);
> 
> Is this actually necessary? I don't see a way for set_sizes() to be
> bypassed.

I was just duplicating the functionality that was already there (these
were initialized at declaration).  My instinct is to want to leave these
initialize these for safety, but the code definitely should call
set_sizes() first, so I'll take this out.

> 
>> +void compare_states(struct fuzz_state state[2])
>> +{
>> +// First zero any "internal" pointers
>> +state[0].corpus = state[1].corpus = NULL;
>> +state[0].ctxt.data = state[1].ctxt.data = NULL;
>> +state[0].ctxt.regs = state[1].ctxt.regs = NULL;
>> +
>> +
> 
> No double blank lines please.
> 
>> +if ( memcmp(&state[0], &state[1], sizeof(struct fuzz_state)) )
>> +{
>> +int i;
> 
> unsigned int (and then %u in the format strings below)

Is there really an advantage to specifying 'unsigned int' for something
like a loop variable?  It hardly seems worth the effort to consider
signed / unsigned in such a case.

>> +printf("State mismatch\n");
>> +
>> +for ( i=0; i<5; i++)
> 
> Blanks missing and please use ARRAY_SIZE() again (also further down).

Ack.

> 
>> +if ( state[0].cr[i] != state[1].cr[i] )
>> +printf("cr[%d]: %lx != %lx\n",
>> +   i, state[0].cr[i], state[1].cr[i]);
>> +
>> +for ( i=0; i> +if ( state[0].msr[i] != state[1].msr[i] )
>> +printf("msr[%d]: %lx != %lx\n",
>> +   i, state[0].msr[i], state[1].msr[i]);
>> +
>> +for ( i=0; i> +if ( memcmp(&state[0].segments[i], &state[1].segments[i],
>> +sizeof(state[0].segments[0])) )
>> +printf("segments[%d] differ!\n", i);
> 
> The actual values would likely be helpful to be printed here, just like
> you do for all other state elements.

Sure.

> 
>> +if ( state[0].data_num != state[1].data_num )
>> +printf("data_num: %lx !=  %lx\n", state[0].data_num,
>> +   state[1].data_num);
>> +if ( state[0].data_index != state[1].data_index )
>> +printf("data_index: %lx !=  %lx\n", state[0].data_index,
>> +   state[1].data_index);
>> +
>> +if ( memcmp(&state[0].regs, &state[1].regs, sizeof(state[0].regs)) )
>> +{
>> +printf("registers differ!\n");
>> +/* Print If Not Equal */
>> +#define PINE(elem)\
>> +if ( state[0].elem != state[1].elem ) \
>> +printf(#elem " differ: %lx != %lx\n", \
>> +   (unsigned long)state[0].elem, \
>> +   (unsigned long)state[1].elem)
>> +PINE(regs.r15);
>> +PINE(regs.r14);
>> +PINE(regs.r13);
>> +PINE(regs.r12);
>> +PINE(regs.rbp);
>> +PINE(regs.rbx);
>> +PINE(regs.r10);
>> +PINE(regs.r11);
>> +PINE(regs.r9);
>> +PINE(regs.r8);
>> +PINE(regs.rax);
>> +PINE(regs.rcx);
>> +PINE(regs.rdx);
>> + 

Re: [Xen-devel] SRIOV VF reset problems

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 October 2017 17:02
> To: Paul Durrant 
> Cc: xen-devel (xen-de...@lists.xenproject.org)  de...@lists.xenproject.org>
> Subject: Re: [Xen-devel] SRIOV VF reset problems
> 
> >>> On 05.10.17 at 16:00,  wrote:
> > I'm currently looking at a problem with a pass-through SR-IOV device
> where
> > the guest driver triggers a VF reset via a back-door interface to the PF. 
> > The
> > reset completes successfully but, in this scenario, it is up to the PF 
> > driver
> > running in dom0 to restore the VF's config space. This is done by simply
> > writing the bytes of config space saved prior to the reset (which may or
> may
> > not be against the PCI spec) but causes a particular problem with MSI...
> >
> > Because Xen has code to intercept writes to the capability, and vetoes any
> > writes other than those which go to the MSI control register or the mask,
> the
> > PF driver cannot restore the content MSI address register(s) after the
> reset.
> > So, the question is how best to deal with this issue? For the moment I have
> a
> > hack in place which calls pci_restore_msi_state() if an attempt is made to
> > write the address which seems to work around the problem for me, but
> does not
> > exactly seem like a proper solution. Thoughts anyone?
> 
> Using pci_restore_msi_state() for this is probably a reasonable
> approach considering the odd behavior (I generally consider it
> wrong for Dom0 to do anything with the config space of a device
> in use by a guest, but one might argue that here the guest is
> sort of aware, and it's hence at least not "behind its back").
> 
> What I'd like to see change though is the trigger pattern - merely
> checking for address writes seems too weak. I would try to make
> this as tight a condition as possible, so ideally you'd watch for the
> entire config space being written sequentially, and trigger the
> function call after the last (conventional) word was written.
> Question of course if whether the driver tries to avoid r/o fields
> or anything else it considers "special".

I don't believe it does but I'd have to check again... IIRC it simply 
byte-writes the base config space and then does the same for capabilities it 
knows it needs to restore.
Thanks... I'll try to narrow it down as much as I can.

  Paul

> 
> Jan


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

Re: [Xen-devel] [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

[Steven Rostedt]

On Thu, 5 Oct 2017 09:01:14 -0700
Thomas Garnier  wrote:

> On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt  wrote:
> > On Wed,  4 Oct 2017 14:19:56 -0700
> > Thomas Garnier  wrote:
> >  
> >> When using -fPIE/PIC with function tracing, the compiler generates a
> >> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> >> takes 6 bytes instead of 5 on the usual relative call.
> >>
> >> With this change, function tracing supports 6 bytes on traceable
> >> function and can still replace relative calls on the ftrace assembly
> >> functions.
> >>
> >> Position Independent Executable (PIE) support will allow to extended the
> >> KASLR randomization range below the -2G memory limit.  
> >
> > Question: This 6 bytes is only the initial call that gcc creates. When
> > function tracing is enabled, the calls are back to the normal call to
> > the ftrace trampoline?  
> 
> That is correct.
> 

Then I think a better idea is to simply nop them out at compile time,
and have the code that updates them to nops to know about it.

See scripts/recordmcount.c

Could we simply add a 5 byte nop followed by a 1 byte nop, and treat it
the same as if it didn't exist? This code can be a little complex, and
can cause really nasty side effects if things go wrong. I would like to
keep from adding more variables to the changes here.

-- Steve

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

Re: [Xen-devel] SRIOV VF reset problems

[Jan Beulich]

>>> On 05.10.17 at 16:00,  wrote:
> I'm currently looking at a problem with a pass-through SR-IOV device where 
> the guest driver triggers a VF reset via a back-door interface to the PF. The 
> reset completes successfully but, in this scenario, it is up to the PF driver 
> running in dom0 to restore the VF's config space. This is done by simply 
> writing the bytes of config space saved prior to the reset (which may or may 
> not be against the PCI spec) but causes a particular problem with MSI...
> 
> Because Xen has code to intercept writes to the capability, and vetoes any 
> writes other than those which go to the MSI control register or the mask, the 
> PF driver cannot restore the content MSI address register(s) after the reset. 
> So, the question is how best to deal with this issue? For the moment I have a 
> hack in place which calls pci_restore_msi_state() if an attempt is made to 
> write the address which seems to work around the problem for me, but does not 
> exactly seem like a proper solution. Thoughts anyone?

Using pci_restore_msi_state() for this is probably a reasonable
approach considering the odd behavior (I generally consider it
wrong for Dom0 to do anything with the config space of a device
in use by a guest, but one might argue that here the guest is
sort of aware, and it's hence at least not "behind its back").

What I'd like to see change though is the trigger pattern - merely
checking for address writes seems too weak. I would try to make
this as tight a condition as possible, so ideally you'd watch for the
entire config space being written sequentially, and trigger the
function call after the last (conventional) word was written.
Question of course if whether the driver tries to avoid r/o fields
or anything else it considers "special".

Jan


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

Re: [Xen-devel] [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

[Thomas Garnier]

On Thu, Oct 5, 2017 at 6:06 AM, Steven Rostedt  wrote:
> On Wed,  4 Oct 2017 14:19:56 -0700
> Thomas Garnier  wrote:
>
>> When using -fPIE/PIC with function tracing, the compiler generates a
>> call through the GOT (call *__fentry__@GOTPCREL). This instruction
>> takes 6 bytes instead of 5 on the usual relative call.
>>
>> With this change, function tracing supports 6 bytes on traceable
>> function and can still replace relative calls on the ftrace assembly
>> functions.
>>
>> Position Independent Executable (PIE) support will allow to extended the
>> KASLR randomization range below the -2G memory limit.
>
> Question: This 6 bytes is only the initial call that gcc creates. When
> function tracing is enabled, the calls are back to the normal call to
> the ftrace trampoline?

That is correct.

>
> -- Steve
>



-- 
Thomas

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

[Xen-devel] [PATCH v3] x86/altp2m: Added xc_altp2m_set_mem_access_multi()

[Petre Pircalabu]

From: Razvan Cojocaru 

For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addresses the gap.

Signed-off-by: Razvan Cojocaru 
Signed-off-by: Petre Pircalabu 

---

Changed since v2:
* Added support for compat arguments translation
---
 tools/libxc/include/xenctrl.h|  3 ++
 tools/libxc/xc_altp2m.c  | 41 ++
 xen/arch/x86/hvm/hvm.c   | 76 +++-
 xen/include/Makefile |  1 +
 xen/include/public/hvm/hvm_op.h  | 30 +---
 xen/include/xlat.lst |  1 +
 xen/tools/compat-build-header.py |  1 +
 7 files changed, 147 insertions(+), 6 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3bcab3c..4e2ce64 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1971,6 +1971,9 @@ int xc_altp2m_switch_to_view(xc_interface *handle, 
domid_t domid,
 int xc_altp2m_set_mem_access(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t gfn,
  xenmem_access_t access);
+int xc_altp2m_set_mem_access_multi(xc_interface *handle, domid_t domid,
+   uint16_t view_id, uint8_t *access,
+   uint64_t *pages, uint32_t nr);
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn);
diff --git a/tools/libxc/xc_altp2m.c b/tools/libxc/xc_altp2m.c
index 0639632..f202ca1 100644
--- a/tools/libxc/xc_altp2m.c
+++ b/tools/libxc/xc_altp2m.c
@@ -188,6 +188,47 @@ int xc_altp2m_set_mem_access(xc_interface *handle, domid_t 
domid,
 return rc;
 }
 
+int xc_altp2m_set_mem_access_multi(xc_interface *xch, domid_t domid,
+   uint16_t view_id, uint8_t *access,
+   uint64_t *pages, uint32_t nr)
+{
+int rc;
+
+DECLARE_HYPERCALL_BUFFER(xen_hvm_altp2m_op_t, arg);
+DECLARE_HYPERCALL_BOUNCE(access, nr, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(pages, nr * sizeof(uint64_t),
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+arg->version = HVMOP_ALTP2M_INTERFACE_VERSION;
+arg->cmd = HVMOP_altp2m_set_mem_access_multi;
+arg->domain = domid;
+arg->u.set_mem_access_multi.view = view_id;
+arg->u.set_mem_access_multi.nr = nr;
+
+if ( xc_hypercall_bounce_pre(xch, pages) ||
+ xc_hypercall_bounce_pre(xch, access) )
+{
+PERROR("Could not bounce memory for 
HVMOP_altp2m_set_mem_access_multi");
+return -1;
+}
+
+set_xen_guest_handle(arg->u.set_mem_access_multi.pfn_list, pages);
+set_xen_guest_handle(arg->u.set_mem_access_multi.access_list, access);
+
+rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op, HVMOP_altp2m,
+ HYPERCALL_BUFFER_AS_ARG(arg));
+
+xc_hypercall_buffer_free(xch, arg);
+xc_hypercall_bounce_post(xch, access);
+xc_hypercall_bounce_post(xch, pages);
+
+return rc;
+}
+
 int xc_altp2m_change_gfn(xc_interface *handle, domid_t domid,
  uint16_t view_id, xen_pfn_t old_gfn,
  xen_pfn_t new_gfn)
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 205b4cb..1f4358c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -73,6 +73,8 @@
 #include 
 #include 
 
+#include 
+
 bool_t __read_mostly hvm_enabled;
 
 #ifdef DBG_LEVEL_0
@@ -4451,6 +4453,7 @@ static int do_altp2m_op(
 case HVMOP_altp2m_destroy_p2m:
 case HVMOP_altp2m_switch_p2m:
 case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_set_mem_access_multi:
 case HVMOP_altp2m_change_gfn:
 break;
 default:
@@ -4568,6 +4571,30 @@ static int do_altp2m_op(
 a.u.set_mem_access.view);
 break;
 
+case HVMOP_altp2m_set_mem_access_multi:
+if ( a.u.set_mem_access_multi.pad ||
+ a.u.set_mem_access_multi.opaque >= a.u.set_mem_access_multi.nr )
+{
+rc = -EINVAL;
+break;
+}
+rc = p2m_set_mem_access_multi(d, a.u.set_mem_access_multi.pfn_list,
+  a.u.set_mem_access_multi.access_list,
+  a.u.set_mem_access_multi.nr,
+  a.u.set_mem_access_multi.opaque,
+  MEMOP_CMD_MASK,
+  a.u.set_mem_access_multi.view);
+if ( rc > 0 )
+{
+a.u.set_mem_access_multi.o

Re: [Xen-devel] [PATCH v2 10/13] fuzz/x86_emulate: Make input more compact

[Jan Beulich]

>>> On 05.10.17 at 17:04,  wrote:
> On 10/04/2017 09:26 AM, Jan Beulich wrote:
> On 25.09.17 at 16:26,  wrote:
>>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>>> @@ -53,6 +53,15 @@ struct fuzz_state
>>>  };
>>>  #define DATA_OFFSET offsetof(struct fuzz_state, corpus)
>>>  
>>> +bool opt_compact;
>>> +
>>> +unsigned int fuzz_minimal_input_size(void)
>>> +{
>>> +if ( opt_compact )
>>> +return sizeof(unsigned long) + 1;
>> 
>> What is this value choice based on / derived from? Oh, judging from
>> code further down it may be one more than the size of the options
>> field, in which case it should be sizeof(...->options) here.
> 
> What about renaming DATA_OFFSET to DATA_SIZE_FULL, and adding
> DATA_SIZE_COMPACT?
> 
> Then is could be:
> 
> return (opt_compact ? DATA_SIZE_COMPACT : DATA_SIZE_FULL) + 1;

Looks fine.

>>> +exit(-1);
>>> +return;
>>> +}
>>> +
>>> +/* Modify only select bits of state */
>>> +
>>> +/* Always read 'options' */
>>> +if ( !input_read(s, &s->options, sizeof(s->options)) )
>>> +return;
>>> +
>>> +while(1) {
>> 
>> Style. And for compatibility (read: no warnings) with as wide a range
>> of compilers as possible, generally for ( ; ; ) is better to use.
> 
> I can do that; but would you mind explaining?  What kinds of compilers
> don't like while(1)?

In various projects of my own I have on (and targeting) Windows
I see this with almost every compiler I happen to use there. Hence
I've started to avoid the construct many years ago.

>>> +{
>>> +if ( !input_read(s, s->msr + offset, sizeof(*s->msr)) )
>>> +return;
>>> +printf("Setting MSR i%d (%x) to %lx\n", offset,
>>> +   msr_index[offset], s->msr[offset]);
>>> +continue;
>>> +}
>>> +
>>> +offset -= MSR_INDEX_MAX;
>>> +
>>> +/* segments[]? */
>>> +if ( offset < SEG_NUM )
>>> +{
>>> +if ( !input_read(s, s->segments + offset, 
>>> sizeof(*s->segments)) )
>>> +return;
>>> +printf("Setting Segment %d\n", offset);
>>> +continue;
>>> +
>>> +}
>>> +
>>> +offset -= SEG_NUM;
>>> +
>>> +/* regs? */
>>> +if ( offset < sizeof(struct cpu_user_regs)
>>> + && offset + sizeof(uint64_t) <= sizeof(struct cpu_user_regs) )
>>> +{
>>> +if ( !input_read(s, ((char *)ctxt->regs) + offset, 
>>> sizeof(uint64_t)) )
>>> +return;
>>> +printf("Setting cpu_user_regs offset %x\n", offset);
>>> +continue;
>>> +}
>>> +
>>> +/* None of the above -- take that as "start emulating" */
>>> +
>>> +return;
>>> +}
>> 
>> Having come here I wonder whether the use of "byte" in the description
>> is right, and you mean "uint8_t offset" above, as you're far from
>> consuming the entire 256 value range.
> 
> Isn't cpu_user_regs larger than 256 bytes?  And in any case, the offset
> will become larger than 256 bytes one we include the FPU state.

Oh, of course. I've somehow stopped summing at the point 
SEG_NUM is being subtracted.

>> Additionally, was the order of elements here chosen for any specific
>> reason? It would seem to me that elements having a more significant
>> effect on emulation may be worth filling first, and I'm not convinced
>> the "all CRs, all MSRs, all SREGs, all GPRs" order matches that.
> 
> I'm not aware of any particular order; it's probably some combination of
> "the order they were in the cpu_regs struct" and "the order in which I
> found it useful to add them".  Given that the input will be more or less
> random, I don't think the order in the struct will have too much of an
> impact on the order in which AFL explores them.

Well, yes, except for very small input (which will leave "higher"
parts unrandomized).

> If you have an alternative suggestion for an order you think would be
> more logical I'm happy to rearrange the structure.

Generally I'd expect GPRs to be most relevant to change value,
but them going first might be sort of ugly, as they're quite big.
For the others I'd say SREGs, CRs, then MSRs. But if it doesn't
really matter (i.e. if small input isn't of much concern, as you
suggest above), you may as well leave things the way they are.

Jan

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

Re: [Xen-devel] DomD: passthroughing an arbitrary device

[Julien Grall]

Hi,

On 04/10/17 19:10, Oleksandr Andrushchenko wrote:

sorry, pressed send too fast
On 10/04/2017 09:02 PM, Oleksandr Andrushchenko wrote:


On 10/04/2017 08:22 PM, Julien Grall wrote:



On 04/10/17 17:32, Oleksandr Andrushchenko wrote:

Hi, all!


Hello,

We have a use-case where we want to passthrough and arbitrary device 
to driver domain,

e.g. GPIO controller or the like (doesn't do any DMA).


I will assume you are speaking about Xen Arm and not Xen x86. Please 
correct if my assumption is wrong.



you are right, sorry for not being precise enough
I know that for device to be pass throughed it must be tied to an 
IOMMU, but in my case
the controller doesn’t have any. The problem is that it not only has 
MMIO range,
but also has its own interrupt controller, so I have to passthrough 
IRQs as well.
Here comes the limitation I face: as the controller doesn’t have any 
IOMMU I can’t

passthrough its IRQ.


I guess you are saying that when you use "dtdev" it will deny guest 
creation.


at least I used/experimented with dtdev as of now and didn't think it 
is possible not to fill in dtdev's,

but still request IRQs
At the moment, the only purpose of "dtdev" is to setup the SMMU 
correctly. If your device is not protected by an SMMU, then it is not 
necessary. You only need to specific "irqs" and "mmios".



ah, good to know,
could you please confirm that my understanding is correct:
if I put "xen,passthrough" property in guest's device tree node which 
has IRQ(s) and/or MMIO range(s)

it is enough to get that "passive" device passed through?


yes, device will not be hidden from Dom0 and free to be used by any 
other domains.


However, you have to ensure it will not be shared between multiple 
domains (this check was done by "dtdev" you don't use here).





should be
If "xen,passthrough" property in a Dom0 device tree node *together* with 
IRQ(s) and MMIO range(s)

in a *guest config* file is enough to get "passive" device passed through
If you wonder why the documentation does not advertise it. It is 
because I consider that any device not protected by an SMMU should 
not be pass-through unless the user really knows what he is doing.


as they say "the best documentation is the source code itself", I 
should have looked more careful


Possible solutions I see could be:

1. Make it possible that Xen allows passing through devices without 
IOMMU assigned:
the problem here is that one can hack Xen then by saying that her 
device is not MMU

protected and writing/reading arbitrary memory then.

2. Make driver domain be marked somehow as a privileged one, so Xen 
can trust it and

allow passing devices without IOMMU.
Q: What if we need to pass this device to DomU?

3. Workaround by introducing a dummy IOMMU for such devices, but it 
still doesn’t

solve the problem with memory protection.

I'm hoping to hear any possible solutions/suggestions which will not 
break security and allow

passing devices at the same time.


Cheers,


Thank you,
Oleksandr




Cheers,


--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 114044: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972
 build-armhf   6 xen-buildfail REGR. vs. 113972

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  33f2d16690d15f9b34f81fa4d44097d00dedbd42
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z1 days
Failing since113979  2017-10-04 00:10:13 Z1 days   23 attempts
Testing same since   114044  2017-10-05 14:01:20 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Ross Lagerwall 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Not pushing.

(No revision log; it would be 621 lines long.)

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

Re: [Xen-devel] [PATCH v4 5/5] ARM: ITS: Expose ITS in the MADT table

[Andre Przywara]

Hi Manish,

On 21/09/17 14:17, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> Add gicv3_its_make_hwdom_madt to update hwdom MADT ITS information.

Thanks for the rework, that looks much better now!

> Signed-off-by: Manish Jaggi 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> ---
>  xen/arch/arm/gic-v3-its.c| 19 +++
>  xen/arch/arm/gic-v3.c|  1 +
>  xen/include/asm-arm/gic_v3_its.h |  8 
>  3 files changed, 28 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 8697e5b..e3e7e92 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -1062,6 +1062,25 @@ void gicv3_its_acpi_init(void)
>  acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
>  gicv3_its_acpi_probe, 0);
>  }
> +
> +unsigned long gicv3_its_make_hwdom_madt(const struct domain *d, void 
> *base_ptr)
> +{
> +unsigned long i = 0;
> +void *fw_its;
> +struct acpi_madt_generic_translator *hwdom_its;
> +
> +hwdom_its = base_ptr;
> +
> +for ( i = 0; i < vgic_v3_its_count(d); i++ )
> +{
> +fw_its = acpi_table_get_entry_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
> +   i);
> +memcpy(hwdom_its, fw_its, sizeof(struct 
> acpi_madt_generic_translator));
> +hwdom_its++;
> +}
> +
> +return sizeof(struct acpi_madt_generic_translator) * 
> vgic_v3_its_count(d);
> +}
>  #endif
>  
>  /*
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 6e8d580..d29eea6 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1403,6 +1403,7 @@ static int gicv3_make_hwdom_madt(const struct domain 
> *d, u32 offset)
>  table_len += size;
>  }
>  
> +table_len += gicv3_its_make_hwdom_madt(d, base_ptr + table_len);
>  return table_len;
>  }
>  
> diff --git a/xen/include/asm-arm/gic_v3_its.h 
> b/xen/include/asm-arm/gic_v3_its.h
> index 31fca66..fc37776 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -138,6 +138,8 @@ void gicv3_its_dt_init(const struct dt_device_node *node);
>  
>  #ifdef CONFIG_ACPI
>  void gicv3_its_acpi_init(void);
> +unsigned long gicv3_its_make_hwdom_madt(const struct domain *d,
> +void *base_ptr);
>  #endif
>  
>  /* Deny iomem access for its */
> @@ -208,6 +210,12 @@ static inline void gicv3_its_dt_init(const struct 
> dt_device_node *node)
>  static inline void gicv3_its_acpi_init(void)
>  {
>  }
> +
> +static inline unsigned long gicv3_its_make_hwdom_madt(const struct domain *d,
> +  void *base_ptr)
> +{
> +return 0;
> +}
>  #endif
>  
>  static inline int gicv3_its_deny_access(const struct domain *d)
> 

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

Re: [Xen-devel] [PATCH v4 4/5] ARM: Introduce get_hwdom_madt_size in gic_hw_operations

[Andre Przywara]

Hi,

On 21/09/17 14:17, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> estimate_acpi_efi_size needs to be updated to provide correct size of
> hardware domains MADT, which now adds ITS information as well.
> 
> Introducing gic_get_hwdom_madt_size.
> 
> Signed-off-by: Manish Jaggi 
> ---
>  xen/arch/arm/domain_build.c |  7 +--
>  xen/arch/arm/gic-v2.c   |  9 +
>  xen/arch/arm/gic-v3.c   | 19 +++
>  xen/arch/arm/gic.c  | 12 
>  xen/include/asm-arm/gic.h   |  3 +++
>  5 files changed, 44 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index d6f9585..f17fcf1 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1808,12 +1808,7 @@ static int estimate_acpi_efi_size(struct domain *d, 
> struct kernel_info *kinfo)
>  acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
>  acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);
>  
> -madt_size = sizeof(struct acpi_table_madt)
> -+ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
> -+ sizeof(struct acpi_madt_generic_distributor);
> -if ( d->arch.vgic.version == GIC_V3 )
> -madt_size += sizeof(struct acpi_madt_generic_redistributor)
> - * d->arch.vgic.nr_regions;
> +madt_size = gic_get_hwdom_madt_size(d);
>  acpi_size += ROUNDUP(madt_size, 8);
>  
>  addr = acpi_os_get_root_pointer();
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index cbe71a9..2868766 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -1012,6 +1012,14 @@ static int gicv2_iomem_deny_access(const struct domain 
> *d)
>  return iomem_deny_access(d, mfn, mfn + nr);
>  }
>  
> +static unsigned long gicv2_get_hwdom_madt_size(const struct domain *d)
> +{
> +return sizeof(struct acpi_table_madt)
> ++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
> ++ sizeof(struct acpi_madt_generic_distributor);
> +
> +}
> +
>  #ifdef CONFIG_ACPI
>  static int gicv2_make_hwdom_madt(const struct domain *d, u32 offset)
>  {
> @@ -1248,6 +1256,7 @@ const static struct gic_hw_operations gicv2_ops = {
>  .read_apr= gicv2_read_apr,
>  .make_hwdom_dt_node  = gicv2_make_hwdom_dt_node,
>  .make_hwdom_madt = gicv2_make_hwdom_madt,
> +.get_hwdom_madt_size = gicv2_get_hwdom_madt_size,
>  .map_hwdom_extra_mappings = gicv2_map_hwdown_extra_mappings,
>  .iomem_deny_access   = gicv2_iomem_deny_access,
>  .do_LPI  = gicv2_do_LPI,
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index b3d605d..6e8d580 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1406,6 +1406,19 @@ static int gicv3_make_hwdom_madt(const struct domain 
> *d, u32 offset)
>  return table_len;
>  }
>  
> +static unsigned long gicv3_get_hwdom_madt_size(const struct domain *d)
> +{
> +unsigned long size;
> +
> +size  = sizeof(struct acpi_madt_generic_redistributor)
> +* d->arch.vgic.nr_regions;
> +
> +size  += vgic_v3_its_count(d)
> +* sizeof(struct acpi_madt_generic_translator);
> +
> +return size;
> +}
> +
>  static int __init
>  gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
>  const unsigned long end)
> @@ -1597,6 +1610,11 @@ static int gicv3_make_hwdom_madt(const struct domain 
> *d, u32 offset)
>  {
>  return 0;
>  }
> +
> +static unsigned long gicv3_get_hwdom_madt_size(const struct domain *d)
> +{
> +return 0;
> +}
>  #endif
>  
>  /* Set up the GIC */
> @@ -1698,6 +1716,7 @@ static const struct gic_hw_operations gicv3_ops = {
>  .secondary_init  = gicv3_secondary_cpu_init,
>  .make_hwdom_dt_node  = gicv3_make_hwdom_dt_node,
>  .make_hwdom_madt = gicv3_make_hwdom_madt,
> +.get_hwdom_madt_size = gicv3_get_hwdom_madt_size,
>  .iomem_deny_access   = gicv3_iomem_deny_access,
>  .do_LPI  = gicv3_do_LPI,
>  };
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 6c803bf..f3c1f0b 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -851,6 +851,18 @@ int gic_make_hwdom_madt(const struct domain *d, u32 
> offset)
>  return gic_hw_ops->make_hwdom_madt(d, offset);
>  }
>  
> +unsigned long gic_get_hwdom_madt_size(const struct domain *d)
> +{
> +unsigned long madt_size;
> +
> +madt_size = sizeof(struct acpi_table_madt)
> ++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
> ++ sizeof(struct acpi_madt_generic_distributor)
> ++ gic_hw_ops->get_hwdom_madt_size(d);

But this is now doubled for a GICv2? As you already do that calculation
in the GICv2 callback?
So I suggest you drop that *there* and rename the function member to
get_hwdom_extra_madt_size() (or so).
So in the GICv2 version you can now return 0. Kee

Re: [Xen-devel] [PATCH v4 3/5] ARM: ITS: Deny hardware domain access to ITS

[Andre Przywara]

Hi Manish,

On 21/09/17 14:17, mja...@caviumnetworks.com wrote:
> From: Manish Jaggi 
> 
> This patch extends the gicv3_iomem_deny_access functionality by adding
> support for ITS region as well. Add function gicv3_its_deny_access.
> 
> Signed-off-by: Manish Jaggi 

Reviewed-by: Andre Przywara 

Thanks,
Andre.

> ---
>  xen/arch/arm/gic-v3-its.c| 22 ++
>  xen/arch/arm/gic-v3.c|  3 +++
>  xen/include/asm-arm/gic_v3_its.h |  9 +
>  3 files changed, 34 insertions(+)
> 
> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
> index 0f662cf..8697e5b 100644
> --- a/xen/arch/arm/gic-v3-its.c
> +++ b/xen/arch/arm/gic-v3-its.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -905,6 +906,27 @@ struct pending_irq *gicv3_assign_guest_event(struct 
> domain *d,
>  return pirq;
>  }
>  
> +int gicv3_its_deny_access(const struct domain *d)
> +{
> +int rc = 0;
> +unsigned long mfn, nr;
> +const struct host_its *its_data;
> +
> +list_for_each_entry( its_data, &host_its_list, entry )
> +{
> +mfn = paddr_to_pfn(its_data->addr);
> +nr = PFN_UP(GICV3_ITS_SIZE);
> +rc = iomem_deny_access(d, mfn, mfn + nr);
> +if ( rc )
> +{
> +printk( "iomem_deny_access failed for %lx:%lx \r\n", mfn, nr);
> +break;
> +}
> +}
> +
> +return rc;
> +}
> +
>  /*
>   * Create the respective guest DT nodes from a list of host ITSes.
>   * This copies the reg property, so the guest sees the ITS at the same 
> address
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 6f562f4..b3d605d 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -1308,6 +1308,9 @@ static int gicv3_iomem_deny_access(const struct domain 
> *d)
>  if ( rc )
>  return rc;
>  
> +if ( gicv3_its_deny_access(d) )
> +return rc;
> +
>  for ( i = 0; i < gicv3.rdist_count; i++ )
>  {
>  mfn = gicv3.rdist_regions[i].base >> PAGE_SHIFT;
> diff --git a/xen/include/asm-arm/gic_v3_its.h 
> b/xen/include/asm-arm/gic_v3_its.h
> index e1be33c..31fca66 100644
> --- a/xen/include/asm-arm/gic_v3_its.h
> +++ b/xen/include/asm-arm/gic_v3_its.h
> @@ -139,6 +139,10 @@ void gicv3_its_dt_init(const struct dt_device_node 
> *node);
>  #ifdef CONFIG_ACPI
>  void gicv3_its_acpi_init(void);
>  #endif
> +
> +/* Deny iomem access for its */
> +int gicv3_its_deny_access(const struct domain *d);
> +
>  bool gicv3_its_host_has_its(void);
>  
>  unsigned int vgic_v3_its_count(const struct domain *d);
> @@ -206,6 +210,11 @@ static inline void gicv3_its_acpi_init(void)
>  }
>  #endif
>  
> +static inline int gicv3_its_deny_access(const struct domain *d)
> +{
> +return 0;
> +}
> +
>  static inline bool gicv3_its_host_has_its(void)
>  {
>  return false;
> 

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

Re: [Xen-devel] [PATCH v4 2/5] ARM: ITS: Populate host_its_list from ACPI MADT Table

[Andre Przywara]

Hi,

On 04/10/17 06:29, Manish Jaggi wrote:
> Hello Julien,
> 
> On 10/3/2017 7:17 PM, Julien Grall wrote:
>> Hi Manish,
>>
>> On 21/09/17 14:17, mja...@caviumnetworks.com wrote:
>>> From: Manish Jaggi 
>>>
>>> Added gicv3_its_acpi_init to update host_its_list from MADT table.
>>> For ACPI, host_its structure  stores dt_node as NULL.
>>>
>>> Signed-off-by: Manish Jaggi 
>>> ---
>>>   xen/arch/arm/gic-v3-its.c    | 24 
>>>   xen/arch/arm/gic-v3.c    |  2 ++
>>>   xen/include/asm-arm/gic_v3_its.h | 10 ++
>>>   3 files changed, 36 insertions(+)
>>>
>>> diff --git a/xen/arch/arm/gic-v3-its.c b/xen/arch/arm/gic-v3-its.c
>>> index 0610991..0f662cf 100644
>>> --- a/xen/arch/arm/gic-v3-its.c
>>> +++ b/xen/arch/arm/gic-v3-its.c
>>> @@ -18,6 +18,7 @@
>>>    * along with this program; If not, see
>>> .
>>>    */
>>>   +#include 
>>>   #include 
>>>   #include 
>>>   #include 
>>> @@ -1018,6 +1019,29 @@ void gicv3_its_dt_init(const struct
>>> dt_device_node *node)
>>>   }
>>>   }
>>>   +#ifdef CONFIG_ACPI
>>> +static int gicv3_its_acpi_probe(struct acpi_subtable_header *header,
>>> +    const unsigned long end)
>>> +{
>>> +    struct acpi_madt_generic_translator *its;
>>> +
>>> +    its = (struct acpi_madt_generic_translator *)header;
>>> +    if ( BAD_MADT_ENTRY(its, end) )
>>> +    return -EINVAL;
>>> +
>>> +    add_to_host_its_list(its->base_address, GICV3_ITS_SIZE, NULL);
>>
>> After the comment from Andre, I was expecting some rework to avoid
>> store the size of the ITS in host_its. So what's the plan for that?
> GICV3_ITS_SIZE  is now 128K (prev 64k, see below), same as what used in
> linux code, I think andre mentioned that need to add additional 64K.

That was one thing, but I was wondering about why we would need to store
that value as a *variable* in struct host_its when it is actually an
architecture defined constant. But as it was there before and it seems
cleaner to use the DT provided size, it could stay as well. We might fix
that later on.

>>
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +void gicv3_its_acpi_init(void)
>>> +{
>>> +    /* Parse ITS information */
>>> +    acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_TRANSLATOR,
>>> +    gicv3_its_acpi_probe, 0);
>>
>> The indentation still looks wrong here.
> ah.. ok.

So ignoring that "size" thing above and assuming this w/s issue fixed:

Reviewed-by: Andre Przywara 

Cheers,
Andre

>>
>>> +}
>>> +#endif
>>> +
>>>   /*
>>>    * Local variables:
>>>    * mode: C
>>> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
>>> index f990eae..6f562f4 100644
>>> --- a/xen/arch/arm/gic-v3.c
>>> +++ b/xen/arch/arm/gic-v3.c
>>> @@ -1567,6 +1567,8 @@ static void __init gicv3_acpi_init(void)
>>>     gicv3.rdist_stride = 0;
>>>   +    gicv3_its_acpi_init();
>>> +
>>>   /*
>>>    * In ACPI, 0 is considered as the invalid address. However the
>>> rest
>>>    * of the initialization rely on the invalid address to be
>>> diff --git a/xen/include/asm-arm/gic_v3_its.h
>>> b/xen/include/asm-arm/gic_v3_its.h
>>> index 1fac1c7..e1be33c 100644
>>> --- a/xen/include/asm-arm/gic_v3_its.h
>>> +++ b/xen/include/asm-arm/gic_v3_its.h
>>> @@ -20,6 +20,7 @@
>>>   #ifndef __ASM_ARM_ITS_H__
>>>   #define __ASM_ARM_ITS_H__
>>>   +#define GICV3_ITS_SIZE  SZ_128K
>>
>> A less random place for this is close to the ITS_DOORBELL_OFFSET
>> definition.
> ok will do :)
>>
>>>   #define GITS_CTLR 0x000
>>>   #define GITS_IIDR   0x004
>>>   #define GITS_TYPER  0x008
>>> @@ -135,6 +136,9 @@ extern struct list_head host_its_list;
>>>   /* Parse the host DT and pick up all host ITSes. */
>>>   void gicv3_its_dt_init(const struct dt_device_node *node);
>>>   +#ifdef CONFIG_ACPI
>>> +void gicv3_its_acpi_init(void);
>>> +#endif
>>>   bool gicv3_its_host_has_its(void);
>>>     unsigned int vgic_v3_its_count(const struct domain *d);
>>> @@ -196,6 +200,12 @@ static inline void gicv3_its_dt_init(const
>>> struct dt_device_node *node)
>>>   {
>>>   }
>>>   +#ifdef CONFIG_ACPI
>>> +static inline void gicv3_its_acpi_init(void)
>>> +{
>>> +}
>>> +#endif
>>> +
>>>   static inline bool gicv3_its_host_has_its(void)
>>>   {
>>>   return false;
>>>
>>
>> Cheers,
>>
> 

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

Re: [Xen-devel] [PATCH v2 10/13] fuzz/x86_emulate: Make input more compact

[George Dunlap]

On 10/04/2017 09:26 AM, Jan Beulich wrote:
 On 25.09.17 at 16:26,  wrote:
>> @@ -22,13 +25,17 @@ int main(int argc, char **argv)
>>  setbuf(stdin, NULL);
>>  setbuf(stdout, NULL);
>>  
>> +opt_compact = true;
> 
> How about giving the variable an initializer instead?

Actually, if we want fuzz-emul.c to be usable by itself (e.g., for the
Google ossfuz project), we *must* use a static initializer from within
fuzz-emul.c for it to have the correct defaults.  I'll change that...

> 
>> --- a/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>> +++ b/tools/fuzz/x86_instruction_emulator/fuzz-emul.c
>> @@ -53,6 +53,15 @@ struct fuzz_state
>>  };
>>  #define DATA_OFFSET offsetof(struct fuzz_state, corpus)
>>  
>> +bool opt_compact;
>> +
>> +unsigned int fuzz_minimal_input_size(void)
>> +{
>> +if ( opt_compact )
>> +return sizeof(unsigned long) + 1;
> 
> What is this value choice based on / derived from? Oh, judging from
> code further down it may be one more than the size of the options
> field, in which case it should be sizeof(...->options) here.

What about renaming DATA_OFFSET to DATA_SIZE_FULL, and adding
DATA_SIZE_COMPACT?

Then is could be:

return (opt_compact ? DATA_SIZE_COMPACT : DATA_SIZE_FULL) + 1;

>> @@ -647,9 +656,81 @@ static void setup_state(struct x86_emulate_ctxt *ctxt)
>>  {
>>  struct fuzz_state *s = ctxt->data;
>>  
>> -/* Fuzz all of the state in one go */
>> -if (!input_read(s, s, DATA_OFFSET))
>> -exit(-1);
>> +if ( !opt_compact )
>> +{
>> +/* Fuzz all of the state in one go */
>> +if (!input_read(s, s, DATA_OFFSET))
> 
> Missing blanks.

Ack

> 
>> +exit(-1);
>> +return;
>> +}
>> +
>> +/* Modify only select bits of state */
>> +
>> +/* Always read 'options' */
>> +if ( !input_read(s, &s->options, sizeof(s->options)) )
>> +return;
>> +
>> +while(1) {
> 
> Style. And for compatibility (read: no warnings) with as wide a range
> of compilers as possible, generally for ( ; ; ) is better to use.

I can do that; but would you mind explaining?  What kinds of compilers
don't like while(1)?

>> +uint16_t offset;
>> +
>> +/* Read 16 bits to decide what bit of state to modify */
>> +if ( !input_read(s, &offset, sizeof(offset)) )
>> +return;
> 
> Doesn't this suggest minimal input size wants to be one higher than
> what you currently enforce? And isn't the use of uint16_t here in
> conflict with the description talking about reading a byte every time?

Hmm, actually it rather implies that it should be one less... with the
new format there's no way to guarantee that the very first insn_fetch
will have any data to read.

>> +/* 
>> + * Then decide if it's "pointing to" different bits of the
>> + * state 
>> + */
>> +
>> +/* cr[]? */
>> +if ( offset < 5 )
> 
> ARRAY_SIZE()

Ack

>> +{
>> +if ( !input_read(s, s->cr + offset, sizeof(*s->cr)) )
>> +return;
>> +printf("Setting CR %d to %lx\n", offset, s->cr[offset]);
>> +continue;
>> +}
>> +
>> +offset -= 5;
> 
> Same here then.
> 
>> +/* msr[]? */
>> +if ( offset < MSR_INDEX_MAX )
> 
> Even here (and below) use of ARRAY_SIZE() may be better.
> 
>> +{
>> +if ( !input_read(s, s->msr + offset, sizeof(*s->msr)) )
>> +return;
>> +printf("Setting MSR i%d (%x) to %lx\n", offset,
>> +   msr_index[offset], s->msr[offset]);
>> +continue;
>> +}
>> +
>> +offset -= MSR_INDEX_MAX;
>> +
>> +/* segments[]? */
>> +if ( offset < SEG_NUM )
>> +{
>> +if ( !input_read(s, s->segments + offset, sizeof(*s->segments)) 
>> )
>> +return;
>> +printf("Setting Segment %d\n", offset);
>> +continue;
>> +
>> +}
>> +
>> +offset -= SEG_NUM;
>> +
>> +/* regs? */
>> +if ( offset < sizeof(struct cpu_user_regs)
>> + && offset + sizeof(uint64_t) <= sizeof(struct cpu_user_regs) )
>> +{
>> +if ( !input_read(s, ((char *)ctxt->regs) + offset, 
>> sizeof(uint64_t)) )
>> +return;
>> +printf("Setting cpu_user_regs offset %x\n", offset);
>> +continue;
>> +}
>> +
>> +/* None of the above -- take that as "start emulating" */
>> +
>> +return;
>> +}
> 
> Having come here I wonder whether the use of "byte" in the description
> is right, and you mean "uint8_t offset" above, as you're far from
> consuming the entire 256 value range.

Isn't cpu_user_regs larger than 256 bytes?  And in any case, the offset
will become larger than 256 bytes one we include the FPU state.

> Additionally, was the order of elements here chosen for any specific
> reason? It would seem to me that elements having a mo

Re: [Xen-devel] [PATCH] MAINTAINERS: update entries to new email address.

[Meng Xu]

On Thu, Oct 5, 2017 at 10:28 AM, Dario Faggioli  wrote:

> Replace, in the 'M:' fields of the components I co-maintain
> ('CPU POOLS', 'SCHEDULING' and 'RTDS SCHEDULER'), the Citrix
> email, to which I don't have access any longer, with my
> personal email.
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
>

​Acked-by: Meng Xu ​

Meng
-- 
Meng Xu
Ph.D. Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 7/7] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN

[Julien Grall]

Hi Andrew,

On 05/10/17 00:27, Andrew Cooper wrote:

On 04/10/2017 19:15, Julien Grall wrote:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 093ebf1a8e..0753d03aac 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -104,11 +104,11 @@ static bool insert_11_bank(struct domain *d,
 unsigned int order)
  {
  int res, i;
-paddr_t spfn;
+mfn_t smfn;
  paddr_t start, size;
  
-spfn = page_to_mfn(pg);

-start = pfn_to_paddr(spfn);
+smfn = page_to_mfn(pg);
+start = mfn_to_maddr(smfn);
  size = pfn_to_paddr(1UL << order);


Wouldn't it be cleaner to move this renaming into patch 1, along with an
extra set of undef/override, to be taken out here?  (perhaps not given
the rework effort?)


I moved the clean-up to patch #1 and add a temporary override that will 
be dropped in this patch.




  
  D11PRINT("Allocated %#"PRIpaddr"-%#"PRIpaddr" (%ldMB/%ldMB, order %d)\n",

@@ -678,8 +678,8 @@ static void pvpmu_finish(struct domain *d, xen_pmu_params_t 
*params)
  
  if ( xenpmu_data )

  {
-mfn = domain_page_map_to_mfn(xenpmu_data);
-ASSERT(mfn_valid(_mfn(mfn)));
+mfn = _mfn(domain_page_map_to_mfn(xenpmu_data));


Seeing as you convert every(?) call to domain_page_map_to_mfn(), it
would be cleaner to change the return type while making the change. >
I'd be happy for such a change being folded into this patch, because
doing so would be by far the least disruptive way of making the change.


All of them but one are turned to _mfn(domain_page_map_to_mfn()). I have 
folded the conversion in this patch.





+ASSERT(mfn_valid(mfn));
  unmap_domain_page_global(xenpmu_data);
  put_page_and_type(mfn_to_page(mfn));
  }
@@ -1185,8 +1180,8 @@ int __mem_sharing_unshare_page(struct domain *d,
  return -ENOMEM;
  }
  
-s = map_domain_page(_mfn(__page_to_mfn(old_page)));

-t = map_domain_page(_mfn(__page_to_mfn(page)));
+s = map_domain_page(page_to_mfn(old_page));
+t = map_domain_page(page_to_mfn(page));
  memcpy(t, s, PAGE_SIZE);
  unmap_domain_page(s);
  unmap_domain_page(t);


This whole lot could turn into copy_domain_page()


I have added a patch at the beginning of the series to use copy_domain_page.




diff --git a/xen/arch/x86/pv/descriptor-tables.c 
b/xen/arch/x86/pv/descriptor-tables.c
index 81973af124..371221a302 100644
--- a/xen/arch/x86/pv/descriptor-tables.c
+++ b/xen/arch/x86/pv/descriptor-tables.c
@@ -25,12 +25,6 @@
  #include 
  #include 
  
-/* Override macros from asm/page.h to make them work with mfn_t */

-#undef mfn_to_page
-#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
-#undef page_to_mfn
-#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
-
  /***
   * Descriptor Tables
   */


If you're making this change, please take out the Descriptor Tables
comment like you do with I/O below, because the entire file is dedicated
to descriptor table support and it will save me one item on a cleanup
patch :).


It is dropped now.




diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index dd90713acf..9ccbd021ef 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -43,16 +43,6 @@
  #include "emulate.h"
  #include "mm.h"
  
-/* Override macros from asm/page.h to make them work with mfn_t */

-#undef mfn_to_page
-#define mfn_to_page(mfn) __mfn_to_page(mfn_x(mfn))
-#undef page_to_mfn
-#define page_to_mfn(pg) _mfn(__page_to_mfn(pg))
-
-/***
- * I/O emulation support
- */
-
  struct priv_op_ctxt {
  struct x86_emulate_ctxt ctxt;
  struct {
@@ -873,22 +873,22 @@ int kimage_build_ind(struct kexec_image *image, unsigned 
long ind_mfn,
  for ( entry = page; ;  )
  {
  unsigned long ind;
-unsigned long mfn;
+mfn_t mfn;
  
  ind = kimage_entry_ind(entry, compat);

-mfn = kimage_entry_mfn(entry, compat);
+mfn = _mfn(kimage_entry_mfn(entry, compat));


Again, modify the return type of kimage_entry_mfn() ?


I have added a patch at the beginning of the series to switch 
kimage/kexec to mfn_t.





diff --git a/xen/include/asm-x86/page.h b/xen/include/asm-x86/page.h
index 45ca742678..8737ef16ff 100644
--- a/xen/include/asm-x86/page.h
+++ b/xen/include/asm-x86/page.h
@@ -273,8 +273,8 @@ void copy_page_sse2(void *, const void *);
  #define pfn_to_paddr(pfn)   __pfn_to_paddr(pfn)
  #define paddr_to_pfn(pa)__paddr_to_pfn(pa)
  #define paddr_to_pdx(pa)pfn_to_pdx(paddr_to_pfn(pa))
-#define vmap_to_mfn(va) l1e_get_pfn(*virt_to_xen_l1e((unsigned long)(va)))
-#define vmap_to_page(va)mfn_to_page(vmap_to_mfn(va))
+#define vmap_to_mfn(va) _mfn(l1e_get_pfn(*virt_to_xen_l1e((unsigned 
long)(va


l1e_get_mfn(*virt_to_xen_l1e((unsigned long)(va)))


+#define vmap_to_page(va)__mfn_to_page(vmap_to_mfn(va))
  
  #endif /* !defined(__ASSEMBLY__) */
  
diff

Re: [Xen-devel] [PATCH v7 04/11] public: xen.h: add definitions for UUID handling

[Volodymyr Babchuk]

Hi Konrad,

On 05.10.17 16:03, Konrad Rzeszutek Wilk wrote:

On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote:

Added type xen_uuid_t. This type represents UUID as an array of 16
bytes in big endian format.

Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:

  XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)

will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
  {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
   0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}

NB: This is compatible with Linux kernel and with libuuid, but it is not
compatible with Microsoft, as they use mixed-endian encoding (some
components are little-endian, some are big-endian).


Oh boy. What a mess.

Do we care about Microsoft for this or is this more for information
purpose?
This is for information. Problem is that XEN already defines EFI_GUID 
which uses MS-style encoding. It is used in EFI code only, but I think 
it is worth to explain differences.

There was discussion at [1]
[...]

[1] http://markmail.org/message/cawi6f33spqg4hf5

Thanks,

Volodymyr

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update entries to new email address.

[Konrad Rzeszutek Wilk]

On Thu, Oct 05, 2017 at 04:28:46PM +0200, Dario Faggioli wrote:
> Replace, in the 'M:' fields of the components I co-maintain
> ('CPU POOLS', 'SCHEDULING' and 'RTDS SCHEDULER'), the Citrix
> email, to which I don't have access any longer, with my
> personal email.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 

Acked-by: Konrad Rzeszutek Wilk 

> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> Cc: Meng Xu 
> ---
>  MAINTAINERS |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 12dbad130c..4d7092324a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -183,7 +183,7 @@ F:tools/blktap2/
>  
>  CPU POOLS
>  M:   Juergen Gross 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/cpupool.c
>  
> @@ -335,14 +335,14 @@ F:  tools/hotplug/Linux/remus-netbuf-setup
>  F:   tools/hotplug/Linux/block-drbd-probe
>  
>  RTDS SCHEDULER
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  M:   Meng Xu 
>  S:   Supported
>  F:   xen/common/sched_rt.c
>  
>  SCHEDULING
>  M:   George Dunlap 
> -M:   Dario Faggioli 
> +M:   Dario Faggioli 
>  S:   Supported
>  F:   xen/common/sched*
>  
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH] MAINTAINERS: update entries to new email address.

[Wei Liu]

On Thu, Oct 05, 2017 at 04:28:46PM +0200, Dario Faggioli wrote:
> Replace, in the 'M:' fields of the components I co-maintain
> ('CPU POOLS', 'SCHEDULING' and 'RTDS SCHEDULER'), the Citrix
> email, to which I don't have access any longer, with my
> personal email.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH] MAINTAINERS: update entries to new email address.

[Dario Faggioli]

Replace, in the 'M:' fields of the components I co-maintain
('CPU POOLS', 'SCHEDULING' and 'RTDS SCHEDULER'), the Citrix
email, to which I don't have access any longer, with my
personal email.

Signed-off-by: Dario Faggioli 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Juergen Gross 
Cc: Meng Xu 
---
 MAINTAINERS |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 12dbad130c..4d7092324a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -183,7 +183,7 @@ F:  tools/blktap2/
 
 CPU POOLS
 M: Juergen Gross 
-M: Dario Faggioli 
+M: Dario Faggioli 
 S: Supported
 F: xen/common/cpupool.c
 
@@ -335,14 +335,14 @@ F:tools/hotplug/Linux/remus-netbuf-setup
 F: tools/hotplug/Linux/block-drbd-probe
 
 RTDS SCHEDULER
-M: Dario Faggioli 
+M: Dario Faggioli 
 M: Meng Xu 
 S: Supported
 F: xen/common/sched_rt.c
 
 SCHEDULING
 M: George Dunlap 
-M: Dario Faggioli 
+M: Dario Faggioli 
 S: Supported
 F: xen/common/sched*
 


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

[Xen-devel] [PATCH] Changing my email address

[Dario Faggioli]

Hello,

Soon I won't have access to dario.faggi...@citrix.com email address.

Therefore, replace it, in my entries in MAINTAINERS, with an email address that
I actually can, and will actually read.

One thing about RTDS. Meng, which one of the following two sentences, better
describes your situation?

 a) Supported:   Someone is actually paid to look after this.
 b) Maintained:  Someone actually looks after it.

If it's a (you're currently paied to look after RTDS) then we're fine. If it's
b), we need a (followup) patch that changes also the status of the RTDS entry,
from 'S' to 'M'.

Regards,
Dario
---
Dario Faggioli (1):
  MAINTAINERS: update entries to new email address.

 MAINTAINERS |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
--
<< ... ... ... >>

Dario Faggioli, Ph.D, http://about.me/dario.faggioli


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

Re: [Xen-devel] [PATCH v4 01/11] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.

[Konrad Rzeszutek Wilk]

On Thu, Oct 05, 2017 at 02:47:30PM +0100, Ross Lagerwall wrote:
> On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote:
> > If the livepatch has only .rodata sections then it is OK to also
> > apply/revert/apply the livepatch without having to worry about the
> > unforseen consequences.
> > 
> > See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c
> > "livepatch: Disallow applying after an revert" for details.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > ---
> > Cc: Ross Lagerwall 
> > 
> 
> The patch looks OK, but what is the use case for a live patch with only
> .rodata?

A NOP one. This hasn't been an issue in the past, but further patches
change the .livepatch_funcs from RW to RO (to be in line with what
livepatch-build-tools.git do) - and then the xen_nop testcase does not
work anymore.


> 
> Regards,
> -- 
> Ross Lagerwall
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore

[Wei Liu]

On Thu, Oct 05, 2017 at 07:44:17PM +0530, Bhupinder Thakur wrote:
> Hi Wei,
> 
> On 5 October 2017 at 15:07, Wei Liu  wrote:
> > On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote:
> >> I get this when compiling under ARM32 (Ubuntu 15.04,
> >> gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2):
> >>
> >> libxl_console.c: In function ‘libxl__device_vuart_add’:
> >> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
> >> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
> >>  flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
> >>  ^
> >> ;
> >
> > My Wheezy 32bit chroot didn't catch this, sigh.
> >
> > Does the following patch work?
> >
> 
> I verified that with this fix, the arm32 toolstack compiles fine.
> 

Thanks. I will commit this shortly.

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

Re: [Xen-devel] ARM32 - build-issues with xen/arm: vpl011: Add a new vuart node in the xenstore

[Bhupinder Thakur]

Hi Wei,

On 5 October 2017 at 15:07, Wei Liu  wrote:
> On Wed, Oct 04, 2017 at 09:58:32PM -0400, Konrad Rzeszutek Wilk wrote:
>> I get this when compiling under ARM32 (Ubuntu 15.04,
>> gcc (Ubuntu/Linaro 4.9.2-10ubuntu13) 4.9.2):
>>
>> libxl_console.c: In function ‘libxl__device_vuart_add’:
>> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
>> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
>>  flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>>  ^
>> ;
>
> My Wheezy 32bit chroot didn't catch this, sigh.
>
> Does the following patch work?
>

I verified that with this fix, the arm32 toolstack compiles fine.

> From ae531197382bf0bc003606a9712075bdd22cfc24 Mon Sep 17 00:00:00 2001
> From: Wei Liu 
> Date: Thu, 5 Oct 2017 10:35:28 +0100
> Subject: [PATCH] libxl: use correct type modifier for vuart_gfn
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Fixes compilation error like:
>
> libxl_console.c: In function ‘libxl__device_vuart_add’:
> libxl_console.c:379:5: error: format ‘%lu’ expects argument of type ‘long 
> unsigned int’, but argument 3 has type ‘xen_pfn_t’ [-Werror=format=]
>   flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
>
> Reported-by: Konrad Rzeszutek Wilk 
> Signed-off-by: Wei Liu 
> ---
>  tools/libxl/libxl_console.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
> index 13ecf128e2..c05dc28b99 100644
> --- a/tools/libxl/libxl_console.c
> +++ b/tools/libxl/libxl_console.c
> @@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
>  flexarray_append(ro_front, "port");
>  flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
>  flexarray_append(ro_front, "ring-ref");
> -flexarray_append(ro_front, GCSPRINTF("%lu", state->vuart_gfn));
> +flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
>  flexarray_append(ro_front, "limit");
>  flexarray_append(ro_front, GCSPRINTF("%d", LIBXL_XENCONSOLE_LIMIT));
>  flexarray_append(ro_front, "type");
> --
> 2.11.0
>

Regards,
Bhupinder

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

Re: [Xen-devel] [PATCH 4/4] xen/ubsan: Introduce and use CONFIG_UBSAN

[Wei Liu]

On Thu, Oct 05, 2017 at 08:49:36AM -0400, Konrad Rzeszutek Wilk wrote:
> > +config UBSAN
> > +   bool "Undefined behaviour sanitizer"
> > +   depends on X86
> > +   ---help---
> > + Enable undefined behaviour sanitizer.
> > +
> > + If unsure, say N here.
> 
> Could you perhaps expand it a bit? How does it sanitize it? With soap :-)?
> And what 'undefinded behaviour's are we talking about? opcodes? 

It sanitizes undefined behaviour in C.

It does so by using compiler black magic: the code in Xen is
instrumented; appropriate calls to hooks are inserted; hooks are called
once UB is detected during runtime.

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

Re: [Xen-devel] [PATCH v4 07/11] livepatch/x86/arm[32, 64]: Force .livepatch.depends section to be uint32_t aligned.

[Ross Lagerwall]

On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote:

By default when using objcopy we lose the alignment when we copy it from 
xen-syms -
with the result that alignment (on ARM32 for example) can be 1:

   [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
Al
..
   [ 6] .livepatch.depend PROGBITS 93 24 00   A  0   0  
1

That, combined with wacky offset means it will be loaded in
memory with the wrong alignment:

(XEN) livepatch.c:425: livepatch: xen_bye_world: Loaded .livepatch.depends at 
000a08043

And later we crash as the .livepatch.depends is not aligned to four bytes, while
the xen_build_id_check expects the code to be four byte aligned and we
get an hypervisor crash (on ARM32):

(XEN) CPU0: Unexpected Trap: Data Abort
(XEN) [ Xen-4.10Hello World  arm32  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) PC: 002400a0 xen_build_id_check+0x8/0xe8
..snip..
(XEN) Xen call trace:
(XEN)[<002400a0>] xen_build_id_check+0x8/0xe8 (PC)
(XEN)[<0021a9c0>] livepatch_op+0x768/0x1610 (LR)
(XEN)[<0023bbe4>] do_sysctl+0x9c8/0xa9c
(XEN)[<002673c4>] do_trap_guest_sync+0x11e0/0x177c
(XEN)[<0026b6a0>] entry.o#return_from_trap+0/0x4
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort

This fix forces all the test-cases to be built with a
.livepatch.depends structure containing the build-id extracted from
the hypervisor (except the xen_bye_world test-case).

We use the 'mkhex' tool instead of 'xxd' as the end result is an 'unsigned'
instead of 'char' type array - which naturally forces the alignment to be of 
four.
Also the 'mkhex' tools allows us to pass the section name as parameter.

The end result is much better alignment:

   [ 7] .livepatch.depend PROGBITS 94 24 00   A  0   0  
4

Note that thanks to 'unsigned int .. __note_depends' the symbol becomes
global:

$ readelf --symbols *.livepatch | grep depen
 23: 36 OBJECT  GLOBAL HIDDEN 6 note_depends
 49: 36 OBJECT  GLOBAL HIDDEN17 note_depends
 16: 36 OBJECT  GLOBAL HIDDEN 3 note_depends
 21: 36 OBJECT  GLOBAL HIDDEN 6 note_depends

See patch titled: "livepatch/arm/x86: Rename note_depends symbol from 
test-cases."
which fixes this.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 


Acked-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v4 01/11] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.

[Ross Lagerwall]

On 10/05/2017 02:51 PM, Konrad Rzeszutek Wilk wrote:

On Thu, Oct 05, 2017 at 02:47:30PM +0100, Ross Lagerwall wrote:

On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote:

If the livepatch has only .rodata sections then it is OK to also
apply/revert/apply the livepatch without having to worry about the
unforseen consequences.

See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c
"livepatch: Disallow applying after an revert" for details.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Ross Lagerwall 



The patch looks OK, but what is the use case for a live patch with only
.rodata?


A NOP one. This hasn't been an issue in the past, but further patches
change the .livepatch_funcs from RW to RO (to be in line with what
livepatch-build-tools.git do) - and then the xen_nop testcase does not
work anymore.




Thanks, that makes sense.

Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH v4 03/11] livepatch: Include sizes when an mismatch occurs

[Ross Lagerwall]

On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote:

If the .bug.frames.X or .livepatch.funcs sizes are different
than what the hypervisor expects - we fail the payload. To help
in diagnosing this include the expected and the payload
sizes.

Also make it more natural by having "Multiples" in the warning.

Also fix one case where we would fail if the size of the .ex_table
was being zero - but that is OK.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Ross Lagerwall 



Reviewed-by: Ross Lagerwall 

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

[Xen-devel] SRIOV VF reset problems

[Paul Durrant]

Hi,

I'm currently looking at a problem with a pass-through SR-IOV device where the 
guest driver triggers a VF reset via a back-door interface to the PF. The reset 
completes successfully but, in this scenario, it is up to the PF driver running 
in dom0 to restore the VF's config space. This is done by simply writing the 
bytes of config space saved prior to the reset (which may or may not be against 
the PCI spec) but causes a particular problem with MSI...

Because Xen has code to intercept writes to the capability, and vetoes any 
writes other than those which go to the MSI control register or the mask, the 
PF driver cannot restore the content MSI address register(s) after the reset. 
So, the question is how best to deal with this issue? For the moment I have a 
hack in place which calls pci_restore_msi_state() if an attempt is made to 
write the address which seems to work around the problem for me, but does not 
exactly seem like a proper solution. Thoughts anyone?

Cheers,

  Paul

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

Re: [Xen-devel] [PATCH 3/4] xen: sched: improve checking soft-affinity

[Dario Faggioli]

On Wed, 2017-10-04 at 14:23 +0100, George Dunlap wrote:
> On 09/15/2017 06:35 PM, Dario Faggioli wrote:
> > 
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > index 3efbfc8..35d0c98 100644
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -410,8 +410,7 @@ static inline void __runq_tickle(struct
> > csched_vcpu *new)
> >  int new_idlers_empty;
> >  
> >  if ( balance_step == BALANCE_SOFT_AFFINITY
> > - && !has_soft_affinity(new->vcpu,
> > -   new->vcpu-
> > >cpu_hard_affinity) )
> > + && !has_soft_affinity(new->vcpu) )
> >  continue;
> >  
> >  /* Are there idlers suitable for new (for this balance
> > step)? */
> > @@ -743,50 +742,42 @@ __csched_vcpu_is_migrateable(struct vcpu *vc,
> > int dest_cpu, cpumask_t *mask)
> >  static int
> >  _csched_cpu_pick(const struct scheduler *ops, struct vcpu *vc,
> > bool_t commit)
> >  {
> > -cpumask_t cpus;
> 
> Is there a reason you couldn't use cpumask_t
> *cpus=cpumask_scratch_cpu()?
> 
I was about to say "yes, of course". But while double checking that, I
realized that the patch is actually wrong.

So, even if not 100% intentional... good catch! :-P

In fact, in this function (_csched_cpu_pick()), cpu potentially changes
here:

cpu = cpumask_test_cpu(vc->processor, cpumask_scratch_cpu(cpu))
? vc->processor
: cpumask_cycle(vc->processor, cpumask_scratch_cpu(cpu));

and here:

if ( !cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu)) &&
 !cpumask_empty(cpumask_scratch_cpu(cpu)) )
cpu = cpumask_cycle(cpu, cpumask_scratch_cpu(cpu));

And it's therefore not ok to continue to use cpumask_scratch_cpu(cpu).

I now have fixed this, but then, while testing, I discovered more, and
much more serious issues.

I'm not actually sure what happened, but it's quite clear I've made a
mess while testing this series (likely, I must mistakenly have tested a
different version of the series, wrt to that I sent).

So I'll send a v3, with the issues I've found fixed, and this time
properly tested.

Sorry everyone, George in particular. :-(

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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 06/13] fuzz/x86_emulate: Rename the file containing the wrapper code

[George Dunlap]

On 10/05/2017 10:01 AM, Jan Beulich wrote:
 On 04.10.17 at 18:34,  wrote:
>> On 10/04/2017 09:23 AM, Jan Beulich wrote:
>> On 25.09.17 at 16:26,  wrote:
 --- a/tools/fuzz/x86_instruction_emulator/Makefile
 +++ b/tools/fuzz/x86_instruction_emulator/Makefile
 @@ -18,22 +18,22 @@ asm:
  
  asm/%: asm ;
  
 -x86_emulate.c x86_emulate.h: %:
 +x86_emulate_user.c x86_emulate_user.h: %:
>>>
>>> How about avoiding the names getting even longer? E.g. using
>>> x86-emulate.[ch] or x86emul-user.[ch] instead?
>>
>> My original idea was to make it easy to construct the original filename
>> from the long filename.  I don't have super-strong opinions (mostly
>> because I think all the options I've seen are pretty bad), but I still
>> think that this is the least-bad option.
>>
>> If you have strong opinions about one of the other ones, let me know and
>> I'll change it.
> 
> Well, together with the suggested alternatives being shorter,
> they also slightly improve word completion behavior when typing
> in partial file names, so yes, I'd really appreciate renaming them
> (and I've listed the suggestions above in the order of my
> preference).

Ok.

> 
 @@ -42,7 +42,7 @@ all: x86-insn-fuzz-all
  
  .PHONY: distclean
  distclean: clean
 -  rm -f x86_emulate x86_emulate.c x86_emulate.h asm
 +  rm -f x86_emulate x86_emulate_user.c x86_emulate_user.h asm
>>>
>>> If you want to stick to the longer names, would you mind taking the
>>> opportunity to make this just x86_emulate* ?
>>
>> What if you put something in that directly called
>> "x86_emulate_user.c.diff" (or something like that) and then ran "make
>> clean"?
>>
>> I tend to think that 'make clean' should only clean things that it is
>> pretty confident were put there by the build system, and not the user.
> 
> Ah, yes, I see your point, albeit I don't fully agree: I would
> actually prefer "make clean" to leave a clean tree, not one
> with user created files left in. But indeed that's a matter of
> taste.

Well if that's the case we should have a whitelist, and do something
like "ls -a | (filter whitelist) | xargs rm -f".  But I think `git clean
-ffdx` does that job for most people these days.

 -George

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

Re: [Xen-devel] [PATCH v4 01/11] livepatch: Expand check for safe_for_reapply if livepatch has only .rodata.

[Ross Lagerwall]

On 09/20/2017 11:31 PM, Konrad Rzeszutek Wilk wrote:

If the livepatch has only .rodata sections then it is OK to also
apply/revert/apply the livepatch without having to worry about the
unforseen consequences.

See commit 98b728a7b235c67e210f67f789db5d9eb38ca00c
"livepatch: Disallow applying after an revert" for details.

Signed-off-by: Konrad Rzeszutek Wilk 
---
Cc: Ross Lagerwall 



The patch looks OK, but what is the use case for a live patch with only 
.rodata?


Regards,
--
Ross Lagerwall

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

[Xen-devel] [xen-unstable-smoke test] 114041: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 113972
 build-armhf   6 xen-buildfail REGR. vs. 113972

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a

version targeted for testing:
 xen  72b0c19a7040ab8446f16578b094fec8703f8095
baseline version:
 xen  dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e

Last test of basis   113972  2017-10-03 21:02:43 Z1 days
Failing since113979  2017-10-04 00:10:13 Z1 days   22 attempts
Testing same since   114015  2017-10-04 18:01:26 Z0 days   10 attempts


People who touched revisions under test:
  Andrew Cooper 
  Bhupinder Thakur 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 
  Wei Liu 

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



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

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

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

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


Not pushing.

(No revision log; it would be 524 lines long.)

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

Re: [Xen-devel] 4.9.52: INFO: task XXX blocked for more than 300 seconds.

[Konrad Rzeszutek Wilk]

On Wed, Oct 04, 2017 at 08:26:27PM +0200, Philipp Hahn wrote:
> Hello,
> 

Adding Ankur to this as I think he saw something similar. 

But in the meantime - do you see this with the latest version of Linux?
> with linux-4.9.52 running on Debian-Wheezy with Xen-4.1 I observed
> several stuck processes: Here is one (truncated) dump of the Linux
> kernel messages:
> 
> >  [] ? __schedule+0x23d/0x6d0
> >  [] ? bit_wait_timeout+0x90/0x90
> >  [] ? schedule+0x32/0x80
> >  [] ? schedule_timeout+0x1ec/0x360
> >  [] ? __blk_mq_run_hw_queue+0x327/0x3e0* see below
> >  [] ? xen_clocksource_get_cycles+0x11/0x20
> >  [] ? bit_wait_timeout+0x90/0x90
> >  [] ? io_schedule_timeout+0xb4/0x130
> >  [] ? prepare_to_wait+0x57/0x80
> >  [] ? bit_wait_io+0x17/0x60
> >  [] ? __wait_on_bit+0x5c/0x90
> >  [] ? bit_wait_timeout+0x90/0x90
> >  [] ? out_of_line_wait_on_bit+0x7e/0xa0
> >  [] ? autoremove_wake_function+0x40/0x40
> >  [] ? jbd2_journal_commit_transaction+0xd48/0x17e0 [jbd2]
> >  [] ? __switch_to+0x2c9/0x720
> >  [] ? try_to_del_timer_sync+0x4d/0x80
> >  [] ? kjournald2+0xdd/0x280 [jbd2]
> >  [] ? wake_up_atomic_t+0x30/0x30
> >  [] ? commit_timeout+0x10/0x10 [jbd2]
> >  [] ? kthread+0xf0/0x110
> >  [] ? __switch_to+0x2c9/0x720
> >  [] ? kthread_park+0x60/0x60
> >  [] ? ret_from_fork+0x25/0x30
> > NMI backtrace for cpu 2
> > CPU: 2 PID: 35 Comm: khungtaskd Not tainted 4.9.0-ucs105-amd64 #1 Debian 
> > 4.9.30-2A~4.2.0.201709271649
> >   81331935  0002
> >  81335e60 0002 8104cb70 8801f0c90e80
> >  81335f6a 8801f0c90e80 003fffbc 81128048
> > Call Trace:
> >  [] ? dump_stack+0x5c/0x77
> >  [] ? nmi_cpu_backtrace+0x90/0xa0
> >  [] ? irq_force_complete_move+0x140/0x140
> >  [] ? nmi_trigger_cpumask_backtrace+0xfa/0x130
> >  [] ? watchdog+0x2b8/0x330
> >  [] ? reset_hung_task_detector+0x10/0x10
> >  [] ? kthread+0xf0/0x110
> >  [] ? __switch_to+0x2c9/0x720
> >  [] ? kthread_park+0x60/0x60
> >  [] ? ret_from_fork+0x25/0x30
> > Sending NMI from CPU 2 to CPUs 0-1,3:
> > NMI backtrace for cpu 1
> > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0-ucs105-amd64 #1 Debian 
> > 4.9.30-2A~4.2.0.201709271649
> > task: 8801f4a02ec0 task.stack: c90040ca4000
> > RIP: e030:[]  [] 
> > xen_hypercall_sched_op+0xa/0x20
> > RSP: e02b:c90040ca7ed0  EFLAGS: 0246
> > RAX:  RBX: 8801f4a02ec0 RCX: 810013aa
> > RDX: 81c4ba70 RSI:  RDI: 0001
> > RBP: 0001 R08:  R09: 
> > R10: 7ff0 R11: 0246 R12: 
> > R13:  R14: 8801f4a02ec0 R15: 8801f4a02ec0
> > FS:  7f23ac595700() GS:8801f5a8() knlGS:
> > CS:  e033 DS: 002b ES: 002b CR0: 80050033
> > CR2: 7f52537d6d46 CR3: 0001bba23000 CR4: 2660
> > Stack:
> >  8801bb832201 0001 8101b55c 81611ec8
> >  8801f4a02ec0 0001 810bc280 8801f4a02ec0
> >  8801f4a02ec0 c0a995961d41240f addce6dcadd009c9 
> > Call Trace:
> >  [] ? xen_safe_halt+0xc/0x20
> >  [] ? default_idle+0x18/0xd0
> >  [] ? cpu_startup_entry+0x1f0/0x260
> > Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc 
> > cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 
> > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 
> > NMI backtrace for cpu 3
> > CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.9.0-ucs105-amd64 #1 Debian 
> > 4.9.30-2A~4.2.0.201709271649
> > task: 8801f4a24f00 task.stack: c90040cb4000
> > RIP: e030:[]  [] 
> > xen_hypercall_sched_op+0xa/0x20
> > RSP: e02b:c90040cb7ed0  EFLAGS: 0246
> > RAX:  RBX: 8801f4a24f00 RCX: 810013aa
> > RDX: 81c4ba70 RSI:  RDI: 0001
> > RBP: 0003 R08:  R09: 
> > R10: 7ff0 R11: 0246 R12: 
> > R13:  R14: 8801f4a24f00 R15: 8801f4a24f00
> > FS:  7f1a2af19700() GS:8801f5b8() knlGS:
> > CS:  e033 DS: 002b ES: 002b CR0: 80050033
> > CR2: 7f4a5416b000 CR3: 0001d83ec000 CR4: 2660
> > Stack:
> >  0001 0001 8101b55c 81611ec8
> >  8801f4a24f00 0003 810bc280 8801f4a24f00
> >  8801f4a24f00 77816deb133b9979 addce6dcadd009c9 
> > Call Trace:
> >  [] ? xen_safe_halt+0xc/0x20
> >  [] ? default_idle+0x18/0xd0
> >  [] ? cpu_startup_entry+0x1f0/0x260
> > Code: cc 51 41 53 b8 1c 00 00 00 0f 05 41 5b 59 c3 cc cc cc cc cc cc cc cc 
> > cc cc cc cc cc cc cc cc cc cc 51 41 53 b8 1d 00 00 00 0f 05 <41> 5b 59 c3 
> > cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 
> > NMI backtrace for cpu 0
> > CPU: 0 PID: 0 Comm: swapper/0 Not ta

Re: [Xen-devel] [PATCH v3 5/9] x86/vvmx: make updating shadow EPTP value more efficient

[Andrew Cooper]

On 05/10/17 14:04, Sergey Dyasli wrote:
> On Thu, 2017-10-05 at 03:27 -0600, Jan Beulich wrote:
> On 05.10.17 at 10:18,  wrote:
>>> --- a/xen/arch/x86/hvm/vmx/entry.S
>>> +++ b/xen/arch/x86/hvm/vmx/entry.S
>>> @@ -80,7 +80,7 @@ UNLIKELY_END(realmode)
>>>  mov  %rsp,%rdi
>>>  call vmx_vmenter_helper
>>>  cmp  $0,%eax
>>> -jne .Lvmx_vmentry_restart
>>> +je .Lvmx_vmentry_restart
>> If you make the function return bool, the cmp above also needs
>> changing (and then preferably to "test %al, %al", in which case
>> it would then also better be "jz" instead of "je").
> Here's the updated delta:
>
> diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
> index 9fb8f89220..47cd674260 100644
> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -79,8 +79,8 @@ UNLIKELY_END(realmode)
>  
>  mov  %rsp,%rdi
>  call vmx_vmenter_helper
> -cmp  $0,%eax
> -jne .Lvmx_vmentry_restart
> +test %al, %al
> +jz .Lvmx_vmentry_restart
>  mov  VCPU_hvm_guest_cr2(%rbx),%rax
>  
>  pop  %r15
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index c9a4111267..a5c2bd71cd 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -4197,7 +4197,8 @@ static void lbr_fixup(void)
>  bdw_erratum_bdf14_fixup();
>  }
>  
> -int vmx_vmenter_helper(const struct cpu_user_regs *regs)
> +/* Returns false if the vmentry has to be restarted */
> +bool vmx_vmenter_helper(const struct cpu_user_regs *regs)
>  {
>  struct vcpu *curr = current;
>  u32 new_asid, old_asid;
> @@ -4206,7 +4207,7 @@ int vmx_vmenter_helper(const struct cpu_user_regs *regs)
>  
>  /* Shadow EPTP can't be updated here because irqs are disabled */
>   if ( nestedhvm_vcpu_in_guestmode(curr) && 
> vcpu_nestedhvm(curr).stale_np2m )
> - return 1;
> + return false;
>  
>  if ( curr->domain->arch.hvm_domain.pi_ops.do_resume )
>  curr->domain->arch.hvm_domain.pi_ops.do_resume(curr);
> @@ -4269,7 +4270,7 @@ int vmx_vmenter_helper(const struct cpu_user_regs *regs)
>  __vmwrite(GUEST_RSP,regs->rsp);
>  __vmwrite(GUEST_RFLAGS, regs->rflags | X86_EFLAGS_MBS);
>  
> -return 0;
> +return true;
>  }

With this, the whole series is Acked-by: Andrew Cooper


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

Re: [Xen-devel] [PATCH v6 08/11] vpci/bars: add handlers to map the BARs

[Jan Beulich]

>>> On 05.10.17 at 14:02,  wrote:
> On Thu, Oct 05, 2017 at 11:55:39AM +, Jan Beulich wrote:
>> >>> On 05.10.17 at 13:09,  wrote:
>> > On Thu, Oct 05, 2017 at 10:01:46AM +, Jan Beulich wrote:
>> >> >>> On 05.10.17 at 11:20,  wrote:
>> >> > On Wed, Oct 04, 2017 at 08:33:33AM +, Jan Beulich wrote:
>> >> >> >>> On 19.09.17 at 17:29,  wrote:
>> >> >> > +bool rom_enabled;
>> >> >> 
>> >> >> Especially with the error handling issue in mind that I've mentioned
>> >> >> earlier, I wonder whether this field shouldn't be dropped, along the
>> >> >> lines of you also no longer caching the memory decode enable bit in the
>> >> >> command register.
>> >> > 
>> >> > Removing rom_enabled would imply doing a register read in
>> >> > vpci_modify_bars in order to know whether the ROM BAR is enabled or
>> >> > not, which is not trivial because depending on the header type the
>> >> > position of the ROM BAR is different.
>> >> 
>> >> As said - I wouldn't mind the field if it was always in sync with the
>> >> hardware one. And it was for a reason that I mentioned the
>> >> memory decode bit, which you no longer cache. I think both
>> >> should be treated the same.
>> > 
>> > I think I'm missing something, rom_enabled matches exactly the state
>> > of the ROM enable bit. There's no way rom_enabled will get updated
>> > without the BAR ROM also being updated in vpci_rom_write.
>> 
>> Oh, I'm sorry for not being precise here: I think the hardware
>> bit should only be set once the mapping is complete. That's
>> not how the code currently behaves, so yes, right now the
>> cached bit apparently properly reflects the actual one. With
>> the possibly deferred mapping, that wouldn't be the case.
> 
> I could add some tail code to vpci_process_pending that sets the
> memory decoding or ROM BAR enable bit together with the rom_enable and
> enabled fields in the header struct. Would you agree to this?

If that's cleanly doable, sure. I had assumed you didn't do it
because you couldn't reasonably update state at that later point.

Jan


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

Re: [Xen-devel] [RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support

[Steven Rostedt]

On Wed,  4 Oct 2017 14:19:56 -0700
Thomas Garnier  wrote:

> When using -fPIE/PIC with function tracing, the compiler generates a
> call through the GOT (call *__fentry__@GOTPCREL). This instruction
> takes 6 bytes instead of 5 on the usual relative call.
> 
> With this change, function tracing supports 6 bytes on traceable
> function and can still replace relative calls on the ftrace assembly
> functions.
> 
> Position Independent Executable (PIE) support will allow to extended the
> KASLR randomization range below the -2G memory limit.

Question: This 6 bytes is only the initial call that gcc creates. When
function tracing is enabled, the calls are back to the normal call to
the ftrace trampoline?

-- Steve


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

Re: [Xen-devel] [PATCH v3 5/9] x86/vvmx: make updating shadow EPTP value more efficient

[Sergey Dyasli]

On Thu, 2017-10-05 at 03:27 -0600, Jan Beulich wrote:
> > > > On 05.10.17 at 10:18,  wrote:
> > 
> > --- a/xen/arch/x86/hvm/vmx/entry.S
> > +++ b/xen/arch/x86/hvm/vmx/entry.S
> > @@ -80,7 +80,7 @@ UNLIKELY_END(realmode)
> >  mov  %rsp,%rdi
> >  call vmx_vmenter_helper
> >  cmp  $0,%eax
> > -jne .Lvmx_vmentry_restart
> > +je .Lvmx_vmentry_restart
> 
> If you make the function return bool, the cmp above also needs
> changing (and then preferably to "test %al, %al", in which case
> it would then also better be "jz" instead of "je").

Here's the updated delta:

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 9fb8f89220..47cd674260 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -79,8 +79,8 @@ UNLIKELY_END(realmode)
 
 mov  %rsp,%rdi
 call vmx_vmenter_helper
-cmp  $0,%eax
-jne .Lvmx_vmentry_restart
+test %al, %al
+jz .Lvmx_vmentry_restart
 mov  VCPU_hvm_guest_cr2(%rbx),%rax
 
 pop  %r15
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c9a4111267..a5c2bd71cd 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -4197,7 +4197,8 @@ static void lbr_fixup(void)
 bdw_erratum_bdf14_fixup();
 }
 
-int vmx_vmenter_helper(const struct cpu_user_regs *regs)
+/* Returns false if the vmentry has to be restarted */
+bool vmx_vmenter_helper(const struct cpu_user_regs *regs)
 {
 struct vcpu *curr = current;
 u32 new_asid, old_asid;
@@ -4206,7 +4207,7 @@ int vmx_vmenter_helper(const struct cpu_user_regs *regs)
 
 /* Shadow EPTP can't be updated here because irqs are disabled */
  if ( nestedhvm_vcpu_in_guestmode(curr) && vcpu_nestedhvm(curr).stale_np2m 
)
- return 1;
+ return false;
 
 if ( curr->domain->arch.hvm_domain.pi_ops.do_resume )
 curr->domain->arch.hvm_domain.pi_ops.do_resume(curr);
@@ -4269,7 +4270,7 @@ int vmx_vmenter_helper(const struct cpu_user_regs *regs)
 __vmwrite(GUEST_RSP,regs->rsp);
 __vmwrite(GUEST_RFLAGS, regs->rflags | X86_EFLAGS_MBS);
 
-return 0;
+return true;
 }
 
 /*

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

Re: [Xen-devel] [PATCH v7 04/11] public: xen.h: add definitions for UUID handling

[Konrad Rzeszutek Wilk]

On Thu, Oct 05, 2017 at 12:00:20AM +0300, Volodymyr Babchuk wrote:
> Added type xen_uuid_t. This type represents UUID as an array of 16
> bytes in big endian format.
> 
> Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:
> 
>  XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
>   0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
> 
> will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
>  {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
>   0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}
> 
> NB: This is compatible with Linux kernel and with libuuid, but it is not
> compatible with Microsoft, as they use mixed-endian encoding (some
> components are little-endian, some are big-endian).

Oh boy. What a mess.

Do we care about Microsoft for this or is this more for information
purpose?
> 
> Signed-off-by: Volodymyr Babchuk 
> ---
> 
> * Fixed example for XEN_DEFINE_UUID() usage. Was
>   XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899, 0xaabbccddeeff)
> 
> * Added comment to xen.h
> 
> * Used
>   #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>   instead of
>   #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> 
> * Used generic macro XEN_DEFINE_UUID_
> 
> ---
> xen/include/public/xen.h | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index 2ac6b1e..1a6255f 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -930,6 +930,39 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
>  __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
>  __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
>  
> +typedef struct
> +{
> +uint8_t a[16];
> +} xen_uuid_t;
> +
> +/*
> + * XEN_DEFINE_UUID(0x00112233, 0x4455, 0x6677, 0x8899,
> + * 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff)
> + * will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
> + * {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
> + * 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff};
> + *
> + * NB: This is compatible with Linux kernel and with libuuid, but it is not
> + * compatible with Microsoft, as they use mixed-endian encoding (some
> + * components are little-endian, some are big-endian).
> + */
> +#define XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)\
> +{{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF,   \
> +  ((a) >>  8) & 0xFF, ((a) >>  0) & 0xFF,   \
> +  ((b) >>  8) & 0xFF, ((b) >>  0) & 0xFF,   \
> +  ((c) >>  8) & 0xFF, ((c) >>  0) & 0xFF,   \
> +  ((d) >>  8) & 0xFF, ((d) >>  0) & 0xFF,   \
> +e1, e2, e3, e4, e5, e6}}
> +
> +/* Compound literals are supported in C99 and later. */
> +#if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
> +(xen_uuid_t)XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
> +#else
> +#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
> +XEN_DEFINE_UUID_(a, b, c, d, e1, e2, e3, e4, e5, e6)
> +#endif /* defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L */
> +
>  #endif /* !__ASSEMBLY__ */
>  
>  /* Default definitions for macros used by domctl/sysctl. */
> -- 
> 2.7.4
> 
> 
> ___
> 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] [PATCH 1/3] arm/xen: don't inclide rwlock.h directly.

[Sebastian Andrzej Siewior]

rwlock.h should not be included directly. Instead linux/splinlock.h
should be included. One thing it does is to break the RT build.

Cc: Stefano Stabellini 
Cc: xen-de...@lists.xenproject.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Sebastian Andrzej Siewior 
---
 arch/arm/xen/p2m.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/xen/p2m.c b/arch/arm/xen/p2m.c
index e71eefa2e427..0641ba54ab62 100644
--- a/arch/arm/xen/p2m.c
+++ b/arch/arm/xen/p2m.c
@@ -1,7 +1,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.14.2


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

Re: [Xen-devel] [PATCH 4/4] xen/ubsan: Introduce and use CONFIG_UBSAN

[Konrad Rzeszutek Wilk]

> +config UBSAN
> + bool "Undefined behaviour sanitizer"
> + depends on X86
> + ---help---
> +   Enable undefined behaviour sanitizer.
> +
> +   If unsure, say N here.

Could you perhaps expand it a bit? How does it sanitize it? With soap :-)?
And what 'undefinded behaviour's are we talking about? opcodes? 

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

Re: [Xen-devel] [PATCH 1/4] xen/tmem: Drop unnecessary noinline attribute

[Konrad Rzeszutek Wilk]

On Tue, Oct 03, 2017 at 07:07:50PM +0100, Andrew Cooper wrote:
> tmem_mempool_page_get() is only referenced by address, so isn't eligable for
> inlining in the first place.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Konrad Rzeszutek Wilk 

Reviewed-by: Konrad Rzeszutek Wilk 

> 
> Not related to the rest of the series, but I stumbled across it while
> resolving another noinline issue.
> ---
>  xen/common/tmem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/common/tmem.c b/xen/common/tmem.c
> index c955cf7..324f42a 100644
> --- a/xen/common/tmem.c
> +++ b/xen/common/tmem.c
> @@ -200,7 +200,7 @@ static void tmem_free_page(struct tmem_pool *pool, struct 
> page_info *pfp)
>  atomic_dec_and_assert(global_page_count);
>  }
>  
> -static noinline void *tmem_mempool_page_get(unsigned long size)
> +static void *tmem_mempool_page_get(unsigned long size)
>  {
>  struct page_info *pi;
>  
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH] xen/pt: Mark TYPE_XEN_PT_DEVICE as hybrid

[Eduardo Habkost]

xen-pt doesn't set the is_express field, but is supposed to be
able to handle PCI Express devices too.  Mark it as hybrid.

Suggested-by: Jan Beulich 
Signed-off-by: Eduardo Habkost 
---
 hw/xen/xen_pt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c
index 01df3414d3..9bba717708 100644
--- a/hw/xen/xen_pt.c
+++ b/hw/xen/xen_pt.c
@@ -966,6 +966,7 @@ static const TypeInfo xen_pci_passthrough_info = {
 .class_init = xen_pci_passthrough_class_init,
 .interfaces = (InterfaceInfo[]) {
 { INTERFACE_CONVENTIONAL_PCI_DEVICE },
+{ INTERFACE_PCIE_DEVICE },
 { },
 },
 };
-- 
2.13.6


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

Re: [Xen-devel] 4.9.52: INFO: task XXX blocked for more than 300 seconds.

[Philipp Hahn]

Hello Jan,

thank you for you answer.

Am 05.10.2017 um 12:12 schrieb Jan Beulich:
 On 04.10.17 at 20:26,  wrote:
>> with linux-4.9.52 running on Debian-Wheezy with Xen-4.1 I observed
>> several stuck processes: Here is one (truncated) dump of the Linux
>> kernel messages:
>>
>>>  [] ? __schedule+0x23d/0x6d0
>>>  [] ? bit_wait_timeout+0x90/0x90
>>>  [] ? schedule+0x32/0x80
>>>  [] ? schedule_timeout+0x1ec/0x360
>>>  [] ? __blk_mq_run_hw_queue+0x327/0x3e0* see below
>>>  [] ? xen_clocksource_get_cycles+0x11/0x20
>>>  [] ? bit_wait_timeout+0x90/0x90
>>>  [] ? io_schedule_timeout+0xb4/0x130
>>>  [] ? prepare_to_wait+0x57/0x80
>>>  [] ? bit_wait_io+0x17/0x60
>>>  [] ? __wait_on_bit+0x5c/0x90
>>>  [] ? bit_wait_timeout+0x90/0x90
>>>  [] ? out_of_line_wait_on_bit+0x7e/0xa0
>>>  [] ? autoremove_wake_function+0x40/0x40
>>>  [] ? jbd2_journal_commit_transaction+0xd48/0x17e0 [jbd2]
>>>  [] ? __switch_to+0x2c9/0x720
>>>  [] ? try_to_del_timer_sync+0x4d/0x80
>>>  [] ? kjournald2+0xdd/0x280 [jbd2]
>>>  [] ? wake_up_atomic_t+0x30/0x30
>>>  [] ? commit_timeout+0x10/0x10 [jbd2]
>>>  [] ? kthread+0xf0/0x110
>>>  [] ? __switch_to+0x2c9/0x720
>>>  [] ? kthread_park+0x60/0x60
>>>  [] ? ret_from_fork+0x25/0x30
>>> NMI backtrace for cpu 2
>>> CPU: 2 PID: 35 Comm: khungtaskd Not tainted 4.9.0-ucs105-amd64 #1 Debian 
>>> 4.9.30-2A~4.2.0.201709271649
>>>   81331935  0002
>>>  81335e60 0002 8104cb70 8801f0c90e80
>>>  81335f6a 8801f0c90e80 003fffbc 81128048
>>> Call Trace:
>>>  [] ? dump_stack+0x5c/0x77
>>>  [] ? nmi_cpu_backtrace+0x90/0xa0
>>>  [] ? irq_force_complete_move+0x140/0x140
>>>  [] ? nmi_trigger_cpumask_backtrace+0xfa/0x130
>>>  [] ? watchdog+0x2b8/0x330
>>>  [] ? reset_hung_task_detector+0x10/0x10
>>>  [] ? kthread+0xf0/0x110
>>>  [] ? __switch_to+0x2c9/0x720
>>>  [] ? kthread_park+0x60/0x60
>>>  [] ? ret_from_fork+0x25/0x30
...
>> Looking at the dis-assembly of xen_clocksource_get_cycles() in
>> arch/x86/xen/time.c I see no path how that should call
>> __blk_mq_run_hw_queue():
> 
> Hence the question marks ahead of the stack entries: What you see
> there are likely leftovers from prior call trees. It just so happens
> that the old return address slots haven't got overwritten yet. You
> need to first sanitize the stack trace e.g. by having the kernel
> dump more of the stack in raw hex form, and then looking at the
> disassembly to figure out how large each stack frame is, starting
> at the top-most address (i.e. the one in RIP).

That explains the strange call trace for me, thank you for the
enlightenment.

> On Wed, Oct 04, 2017 at 06:26:27PM +, Philipp Hahn wrote:
>>> INFO: task btrfs-transacti:522 blocked for more than 300 seconds.
> [...] 
>> And another one:
>>> INFO: task smbd:20101 blocked for more than 300 seconds.
> [...] 
>> This does not look normal to me or did I miss something?
> 
> So I see that both of the stuck processes listed above (smbd and
> btrfs-*) are disk related processes. Might I ask how many disk/nics
> (PV) do you have attached to this DomU, and how many queues does each
> have?

Nothing special configured, how would I best fetch that info?


Which leads me back to my original problem: How can I diagnose *why* the
task is blocked for that time? From my understanding this can happen if
IO is too slow and task just have to wait for too long. ¹
Even if IO is slow the system should stabilize itself when no new IO is
generated and the old one has been processed, right? So looking at
`vmstat` or `blktrace` should tell me, that Xen/Linux/whatever is busy
with IO and it is simply not fast enough to keep up with the load.

Thanks again, but any hint how to diagnose this does help.

Philipp

¹


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

Re: [Xen-devel] [PATCH v6 08/11] vpci/bars: add handlers to map the BARs

[Roger Pau Monné]

On Thu, Oct 05, 2017 at 11:55:39AM +, Jan Beulich wrote:
> >>> On 05.10.17 at 13:09,  wrote:
> > On Thu, Oct 05, 2017 at 10:01:46AM +, Jan Beulich wrote:
> >> >>> On 05.10.17 at 11:20,  wrote:
> >> > On Wed, Oct 04, 2017 at 08:33:33AM +, Jan Beulich wrote:
> >> >> >>> On 19.09.17 at 17:29,  wrote:
> >> >> > --- a/xen/include/xen/vpci.h
> >> >> > +++ b/xen/include/xen/vpci.h
> >> >> > @@ -35,11 +35,52 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int 
> >> >> > reg, unsigned int size);
> >> >> >  void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
> >> >> >  uint32_t data);
> >> >> >  
> >> >> > +/*
> >> >> > + * Check for pending vPCI operations on this vcpu. Returns true if 
> >> >> > the vcpu
> >> >> > + * should not run.
> >> >> > + */
> >> >> > +bool vpci_check_pending(struct vcpu *v);
> >> >> > +
> >> >> >  struct vpci {
> >> >> >  /* List of vPCI handlers for a device. */
> >> >> >  struct list_head handlers;
> >> >> >  spinlock_t lock;
> >> >> > +
> >> >> > +#ifdef __XEN__
> >> >> > +/* Hide the rest of the vpci struct from the user-space test 
> >> >> > harness. */
> >> >> > +struct vpci_header {
> >> >> > +/* Information about the PCI BARs of this device. */
> >> >> > +struct vpci_bar {
> >> >> > +paddr_t addr;
> >> >> > +uint64_t size;
> >> >> > +enum {
> >> >> > +VPCI_BAR_EMPTY,
> >> >> > +VPCI_BAR_IO,
> >> >> > +VPCI_BAR_MEM32,
> >> >> > +VPCI_BAR_MEM64_LO,
> >> >> > +VPCI_BAR_MEM64_HI,
> >> >> > +VPCI_BAR_ROM,
> >> >> > +} type;
> >> >> > +bool prefetchable;
> >> >> > +/* Store whether the BAR is mapped into guest p2m. */
> >> >> > +bool enabled;
> >> >> > +/*
> >> >> > + * Store whether the ROM enable bit is set (doesn't 
> >> >> > imply ROM BAR
> >> >> > + * is mapped into guest p2m). Only used for type 
> >> >> > VPCI_BAR_ROM.
> >> >> > + */
> >> >> > +bool rom_enabled;
> >> >> 
> >> >> Especially with the error handling issue in mind that I've mentioned
> >> >> earlier, I wonder whether this field shouldn't be dropped, along the
> >> >> lines of you also no longer caching the memory decode enable bit in the
> >> >> command register.
> >> > 
> >> > Removing rom_enabled would imply doing a register read in
> >> > vpci_modify_bars in order to know whether the ROM BAR is enabled or
> >> > not, which is not trivial because depending on the header type the
> >> > position of the ROM BAR is different.
> >> 
> >> As said - I wouldn't mind the field if it was always in sync with the
> >> hardware one. And it was for a reason that I mentioned the
> >> memory decode bit, which you no longer cache. I think both
> >> should be treated the same.
> > 
> > I think I'm missing something, rom_enabled matches exactly the state
> > of the ROM enable bit. There's no way rom_enabled will get updated
> > without the BAR ROM also being updated in vpci_rom_write.
> 
> Oh, I'm sorry for not being precise here: I think the hardware
> bit should only be set once the mapping is complete. That's
> not how the code currently behaves, so yes, right now the
> cached bit apparently properly reflects the actual one. With
> the possibly deferred mapping, that wouldn't be the case.

I could add some tail code to vpci_process_pending that sets the
memory decoding or ROM BAR enable bit together with the rom_enable and
enabled fields in the header struct. Would you agree to this?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v6 08/11] vpci/bars: add handlers to map the BARs

[Jan Beulich]

>>> On 05.10.17 at 13:09,  wrote:
> On Thu, Oct 05, 2017 at 10:01:46AM +, Jan Beulich wrote:
>> >>> On 05.10.17 at 11:20,  wrote:
>> > On Wed, Oct 04, 2017 at 08:33:33AM +, Jan Beulich wrote:
>> >> >>> On 19.09.17 at 17:29,  wrote:
>> >> > --- a/xen/include/xen/vpci.h
>> >> > +++ b/xen/include/xen/vpci.h
>> >> > @@ -35,11 +35,52 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int 
>> >> > reg, unsigned int size);
>> >> >  void vpci_write(pci_sbdf_t sbdf, unsigned int reg, unsigned int size,
>> >> >  uint32_t data);
>> >> >  
>> >> > +/*
>> >> > + * Check for pending vPCI operations on this vcpu. Returns true if the 
>> >> > vcpu
>> >> > + * should not run.
>> >> > + */
>> >> > +bool vpci_check_pending(struct vcpu *v);
>> >> > +
>> >> >  struct vpci {
>> >> >  /* List of vPCI handlers for a device. */
>> >> >  struct list_head handlers;
>> >> >  spinlock_t lock;
>> >> > +
>> >> > +#ifdef __XEN__
>> >> > +/* Hide the rest of the vpci struct from the user-space test 
>> >> > harness. */
>> >> > +struct vpci_header {
>> >> > +/* Information about the PCI BARs of this device. */
>> >> > +struct vpci_bar {
>> >> > +paddr_t addr;
>> >> > +uint64_t size;
>> >> > +enum {
>> >> > +VPCI_BAR_EMPTY,
>> >> > +VPCI_BAR_IO,
>> >> > +VPCI_BAR_MEM32,
>> >> > +VPCI_BAR_MEM64_LO,
>> >> > +VPCI_BAR_MEM64_HI,
>> >> > +VPCI_BAR_ROM,
>> >> > +} type;
>> >> > +bool prefetchable;
>> >> > +/* Store whether the BAR is mapped into guest p2m. */
>> >> > +bool enabled;
>> >> > +/*
>> >> > + * Store whether the ROM enable bit is set (doesn't imply 
>> >> > ROM BAR
>> >> > + * is mapped into guest p2m). Only used for type 
>> >> > VPCI_BAR_ROM.
>> >> > + */
>> >> > +bool rom_enabled;
>> >> 
>> >> Especially with the error handling issue in mind that I've mentioned
>> >> earlier, I wonder whether this field shouldn't be dropped, along the
>> >> lines of you also no longer caching the memory decode enable bit in the
>> >> command register.
>> > 
>> > Removing rom_enabled would imply doing a register read in
>> > vpci_modify_bars in order to know whether the ROM BAR is enabled or
>> > not, which is not trivial because depending on the header type the
>> > position of the ROM BAR is different.
>> 
>> As said - I wouldn't mind the field if it was always in sync with the
>> hardware one. And it was for a reason that I mentioned the
>> memory decode bit, which you no longer cache. I think both
>> should be treated the same.
> 
> I think I'm missing something, rom_enabled matches exactly the state
> of the ROM enable bit. There's no way rom_enabled will get updated
> without the BAR ROM also being updated in vpci_rom_write.

Oh, I'm sorry for not being precise here: I think the hardware
bit should only be set once the mapping is complete. That's
not how the code currently behaves, so yes, right now the
cached bit apparently properly reflects the actual one. With
the possibly deferred mapping, that wouldn't be the case.

Jan


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

Re: [Xen-devel] [PATCH 23/24] libxl: dm_restrict: Support uid range user

[Wei Liu]

On Wed, Oct 04, 2017 at 04:57:29PM +0100, Ian Jackson wrote:
> Signed-off-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 24/24] tools: xentoolcore_restrict_all: use domid_t

[Wei Liu]

On Wed, Oct 04, 2017 at 04:57:30PM +0100, Ian Jackson wrote:
> This necessitates adding $(CFLAGS_xeninclude) to all the depending
> libraries (which can be done via Rules.mk), so that the definition of
> domid_t (in xen.h) can be found.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Wei Liu 

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