Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Jan Beulich]

>>> On 02.09.16 at 15:03,  wrote:
> On 09/02/2016 03:56 PM, Jan Beulich wrote:
> On 02.09.16 at 14:41,  wrote:
>>> On 09/02/2016 03:33 PM, Jan Beulich wrote:
>>> On 02.09.16 at 14:21,  wrote:
> On 09/02/2016 01:02 PM, Jan Beulich wrote:
>>> +/*
 + * Corresponding list of access settings for pfn_list
 + * Used only with XENMEM_access_op_set_access_multi
 + */
 +XEN_GUEST_HANDLE(uint8) access_list;
>> And for both of them - I don't think the arrays are meant to be
>> used for output? In which case they should be handles of const
>> types.
>
> Actually I can't seem to be able to find a magic combination that works.
>
> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>
> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
> name a type
>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>
> which is fair. I've tried:
>
> XEN_GUEST_HANDLE(const_uint8) access_list;
>
> which does go further with the compilation process, but still kills it 
> with:
>
> xen/include/compat/memory.h:154:5: error: unknown type name
> '__compat_handle_const_uint8'
>  COMPAT_HANDLE(const_uint8) access_list;
>
> What would be the appropriate const type to use here?

 This one. Did you check that handle actually gets created? Per
 my brief checking it doesn't look so. And neither the native one.
>>>
>>> Running ./configure again, followed by 'make clean' and a new 'make
>>> dist' didn't help, so if it's supposed to be generated automatically it
>>> doesn't seem to be (or I'm doing something wrong). I'll investigate more.
>> 
>> The compat one is supposed to get auto-generated once the native
>> one is there.
> 
> Changing both handles to XEN_GUEST_HANLDE(const_void) compiles cleanly.
> As soon as I change to either XEN_GUEST_HANLDE(const_uint8) or
> XEN_GUEST_HANLDE(const_uint64) I start getting errors.
> 
> Previously the auto-generation seems to have worked fine, so this is
> likely something more subtle.

Oh, I see where the issue is: Both DEFINE_XEN_GUEST_HANDLE()
and __DEFINE_XEN_GUEST_HANDLE() auto-magically produce const
counterparts, but while DEFINE_COMPAT_HANDLE() does too,
__DEFINE_COMPAT_HANDLE() doesn't. That'll need fixing, I think.

Jan


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

Re: [Xen-devel] [PATCH v5] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

[Jan Beulich]

>>> On 02.09.16 at 10:20,  wrote:
> +/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
> +#define SMEP_HVM_ONLY (-1)
> +static s8 __initdata opt_smep = 1;
> +static void __init parse_smep_param(char *s)
> +{
> +if ( !parse_bool(s) )
> +{
> +opt_smep = 0;
> +}
> +else if ( !strcmp(s, "hvm") )
> +{
> +opt_smep = SMEP_HVM_ONLY;
> +}
> +
> +if ( opt_smep == 1 )
> +__set_bit(X86_FEATURE_XEN_SMEP, boot_cpu_data.x86_capability);
> +}
> +custom_param("smep", parse_smep_param);

The pointless braces are still there, and it still doesn't look like e.g.
"smep=0 smep=1" would work. Did you take the time to look at
other callers of parse_bool()?

And then - I'm sorry for not having noticed before - setting the
feature flag here means it won't get set if no "smep=" was given.
I.e. you rather want to move that ...

> @@ -1403,12 +1433,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  if ( !opt_smep )
>  setup_clear_cpu_cap(X86_FEATURE_SMEP);

... around here.

Jan


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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Tamas K Lengyel]

On Sep 2, 2016 09:17, "Razvan Cojocaru"  wrote:
>
> On 09/02/2016 06:13 PM, Tamas K Lengyel wrote:
> > On Sep 2, 2016 09:03, "Jan Beulich"  > > wrote:
> >>
> >> >>> On 02.09.16 at 16:50,  > > wrote:
> >> > On Sep 2, 2016 05:45, "Jan Beulich"  > > wrote:
> >> >>
> >> >> >>> On 02.09.16 at 13:18,  > > wrote:
> >> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
> >> >> > On 02.09.16 at 10:51,  > > wrote:
> >> >> >>> Changes since V1 / RFC:
> >> >> >>>  - Renamed xc_set_mem_access_sparse() to
xc_set_mem_access_multi(),
> >> >> >>>and XENMEM_access_op_set_access_sparse to
> >> >> >>>XENMEM_access_op_set_access_multi.
> >> >> >>>  - Renamed the 'nr' parameter to 'size'.
> >> >> >>
> >> >> >> Why?
> >> >> >
> >> >> > Tamas suggested it, size sounded more intuitive to him. I have no
> >> >> > problem with either nr or size.
> >> >>
> >> >> Size to me means something in bytes, which clearly isn't the case
> >> >> here. There's not even support for other then 4k pages so far.
> >> >
> >> > Lets make it array_size then to clarify?
> >>
> >> What's wrong with "nr", matching the other (existing) function?
> >>
> >
> > IMHO it's too generic. So either a more descriptive name or a comment is
> > warranted to explain the inputs.
>
> If this satisfies everybody, I'll keep 'nr' and add a comment describing
> the function and parameters (which is a good thing anyway).
>
>

SGTM.

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

[Xen-devel] [libvirt test] 100715: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  8540301b782a36a0721ece0fe756e7e328d61418
baseline version:
 libvirt  36f57ad7d792f9a1342d48c9977ca9f5af647d1d

Last test of basis   100671  2016-08-31 04:21:56 Z2 days
Testing same since   100686  2016-09-01 04:21:33 Z1 days2 attempts


People who touched revisions under test:
  Michal Privoznik 

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 fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 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=8540301b782a36a0721ece0fe756e7e328d61418
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt 
8540301b782a36a0721ece0fe756e7e328d61418
+ branch=libvirt
+ 

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

[Wei Liu]

On Fri, Sep 02, 2016 at 01:30:40PM +0100, Andrew Cooper wrote:
> On 02/09/16 13:26, Jan Beulich wrote:
>  On 02.09.16 at 14:13,  wrote:
> >> On 02/09/16 13:06, Jan Beulich wrote:
> >> On 02.09.16 at 14:01,  wrote:
>  On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
>  On 02.09.16 at 13:47,  wrote:
> > Since this is a config option - why bother issuing a warning and
> > tainting the hypervisor?
> >
>  Because there isn't a clear indicator if gcov is enabled.
> 
>  I think it would be valuable to just tell from the backtrace or console
>  log that gcov is enabled, then we can legitimately refuse to provide
>  (security) support for such builds.
> >>> Then perhaps making it match the "debug=" would be the better
> >>> approach for a feature not controlled on the command line?
> >> I would prefer not to make it depend on debug=
> >>
> >> Coverage on a release hypervisor is equally important, and will be
> >> different from a debug hypervisor.
> > I didn't say "depend on", but "match" (which I mean just logging wise).
> >
> >> I am on the fence as to whether a taint is right to use, but I do think
> >> that a "with GCOV" is needed somewhere obvious on the banner line.
> > Right, hence the matching goal with "debug=".
> 
> Ah - I see what you mean.  Yes - that would be fine by me.
> 

Fine by me, too.

I will replace this patch with a new one.

Wei.

> ~Andrew

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

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

[Wei Liu]

On Fri, Sep 02, 2016 at 02:21:28PM +0100, Julien Grall wrote:
> Hi Wei,
> 
> On 02/09/16 13:01, Wei Liu wrote:
> >On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
> >On 02.09.16 at 13:47,  wrote:
> >>
> >>Since this is a config option - why bother issuing a warning and
> >>tainting the hypervisor?
> >>
> >
> >Because there isn't a clear indicator if gcov is enabled.
> 
> I think this is an issue to all .config option. If I am not mistaken,
> currently you are not able to know whether option FOO has been enabled for
> your kernel.
> 
> Maybe we should integrate the .config in the binary?
> 

I think that would be a good idea.  It is orthogonal to what I'm trying
to do here though.

Wei.

> Regards,
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

[Jan Beulich]

>>> On 19.08.16 at 19:22,  wrote:
> Ravi Sahita's dynamically allocated altp2m structs

I think I've asked before: With this and ...

> Signed-off-by: Paul Lai 
> Reviewed-by: Ravi Sahita 

... this - who's the actual author?

> @@ -5279,11 +5279,11 @@ static int do_altp2m_op(
>  break;
>  }
>  
> -ostate = d->arch.altp2m_active;
> -d->arch.altp2m_active = !!a.u.domain_state.state;
> +ostate = altp2m_active(d);
> +set_altp2m_active(d, !!a.u.domain_state.state);

The !! shouldn't be needed anymore.

> --- a/xen/arch/x86/mm/altp2m.c
> +++ b/xen/arch/x86/mm/altp2m.c
> @@ -73,23 +73,23 @@ hvm_altp2m_init( struct domain *d)
>  unsigned int i = 0;
>  
>  /* Init alternate p2m data. */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +if ( (d->arch.altp2m->altp2m_eptp = alloc_xenheap_page()) == NULL )
>  {
>  rc = -ENOMEM;
>  goto out;
>  }
>  
>  for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +d->arch.altp2m->altp2m_eptp[i] = mfn_x(INVALID_MFN);
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +rc = p2m_alloc_table(d->arch.altp2m->altp2m_p2m[i]);
>  if ( rc != 0 )
> goto out;
>  }
>  
> -d->arch.altp2m_active = 0;
> +set_altp2m_active(d, 0);

"false" please (also elsewhere).

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -193,12 +193,15 @@ static void p2m_teardown_altp2m(struct domain *d)
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -if ( !d->arch.altp2m_p2m[i] )
> +if ( !d->arch.altp2m->altp2m_p2m[i] )
>  continue;
> -p2m = d->arch.altp2m_p2m[i];
> +p2m = d->arch.altp2m->altp2m_p2m[i];
>  p2m_free_one(p2m);
> -d->arch.altp2m_p2m[i] = NULL;
> +d->arch.altp2m->altp2m_p2m[i] = NULL;
>  }
> +
> +if ( d->arch.altp2m )
> +xfree(d->arch.altp2m);

Two problems here: First, xfree() happily deals with NULL being
passed. But then, such a NULL check clearly should not come
_after_ the pointer did already get dereferenced. I.e. first of all
you need to clarify for yourself whether the function can be called
with the pointer being NULL.

> @@ -206,10 +209,14 @@ static int p2m_init_altp2m(struct domain *d)

And then, considering this is the last patch in the series - how come
these two functions are still in this source file?

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -338,6 +338,13 @@ struct p2m_domain {
>  };
>  };
>  
> +struct altp2m_domain {
> +bool_t altp2m_active;
> +struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
> +mm_lock_t altp2m_list_lock;
> +uint64_t *altp2m_eptp;
> +};

None of the altp2m_ prefixes here are really useful for anything afaics.

Jan


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

Re: [Xen-devel] Can't build ipxe with 6.1.1

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] Can't build ipxe with 6.1.1"):
> Ian: Can we see about getting xenbits:ipxe.git which works, and is
> tested by osstest, in the same way as seabios currently is?

As I said on IRC, I have no objection to this plan.  When there is an
appropriate ipxe git branch we can put it on xenbits nest to seabios.
There would have to be a corresponding xen.git patch to clone and use
the new ipxe git repo.

If those pieces are present, I would be happy to do the associated
osstest work (which is very straightforward).

> iPXE has a rolling release with no specific version number, but does
> have a xen-netfront implementation (when we start using a version which
> isn't 6 years old), so some system testing of PXE booting HVM guests
> would be a good move.

There is currently no testing of pxebooting guests, in osstest.  I
would welcome patches to do that.  I guess they'd end up using ipxe
with qemu-trad and native pxe support with qemu upstream (assuming all
the toolstack plumbing is in place - which I'm not sure about TBH).
The starting point would probably be the Debian d-i test cases.
(Search for test-debian-di in osstest.git:make-flight.)

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Tamas K Lengyel]

On Sep 2, 2016 05:45, "Jan Beulich"  wrote:
>
> >>> On 02.09.16 at 13:18,  wrote:
> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
> > On 02.09.16 at 10:51,  wrote:
> >>> Changes since V1 / RFC:
> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
> >>>and XENMEM_access_op_set_access_sparse to
> >>>XENMEM_access_op_set_access_multi.
> >>>  - Renamed the 'nr' parameter to 'size'.
> >>
> >> Why?
> >
> > Tamas suggested it, size sounded more intuitive to him. I have no
> > problem with either nr or size.
>
> Size to me means something in bytes, which clearly isn't the case
> here. There's not even support for other then 4k pages so far.
>

Lets make it array_size then to clarify?

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

Re: [Xen-devel] xen arm64 dom0 question

[Julien Grall]

On 02/09/16 12:27, Peng Fan wrote:

Hi Julien, Stefano


Hi Peng,



On My ARM64 platform, there is 6GB memory.
0x8000 - 0xfff: 2GB
0x88000 - 0x9: 4GB

xen will alloc 1:1 mapping for Dom0 memory, so if I assign dom0_mem with a 
bigger
value, saying 2048MB or bigger. xen will alloc continus memory from higher 
address
space in the higer 4GB.

But the SD controller in my ARM64 platform has a limitation that it can only
access 32bit address space. So if Dom0 memory is at higher 4GB, SD controller
can not work as expected, because it only works when the dma address is 32bit
address.

So, Can we assign a hole in lower 32bit address space for Dom0 guest physical
memory, just as DomU? Dynamically find out a hole and size 128MB or bigger?
Or do you have any ideas?


Looking at the allocation code (allocate_memory in 
arch/arm/domain_build.c), Xen is trying to allocate as much memory as 
possible below 4GB for 32-bit domain to accommodate non-LPAE kernel.


We haven't though about devices that can only handle 32-bit address at 
that time. I think replacing "lowmen = is_32bit_domain(d)" by "lowmem = 
true" should do the job.


Note that, a proper upstream patch would require to modify the 
description of the function and potentially kill lowmen (or gate it with 
a command line parameter?).


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

[Julien Grall]

Hi Wei,

On 02/09/16 13:01, Wei Liu wrote:

On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:

On 02.09.16 at 13:47,  wrote:


Since this is a config option - why bother issuing a warning and
tainting the hypervisor?



Because there isn't a clear indicator if gcov is enabled.


I think this is an issue to all .config option. If I am not mistaken, 
currently you are not able to know whether option FOO has been enabled 
for your kernel.


Maybe we should integrate the .config in the binary?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Jan Beulich]

>>> On 02.09.16 at 15:15,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 2, 2016 6:46 PM
>> To: Wu, Feng 
>> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> de...@lists.xen.org 
>> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
>> PI hooks
>> 
>> >>> On 02.09.16 at 12:30,  wrote:
>> 
>> >
>> >> -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Friday, September 2, 2016 5:26 PM
>> >> To: Wu, Feng 
>> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> de...@lists.xen.org 
>> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> assigning
>> >> PI hooks
>> >>
>> >> >>> On 02.09.16 at 10:40,  wrote:
>> >>
>> >> >
>> >> >> -Original Message-
>> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> Sent: Friday, September 2, 2016 4:16 PM
>> >> >> To: Wu, Feng 
>> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> >> de...@lists.xen.org 
>> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> >> assigning
>> >> >> PI hooks
>> >> >>
>> >> >> >>> On 02.09.16 at 09:31,  wrote:
>> >> >>
>> >> >> >
>> >> >> >> -Original Message-
>> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> Sent: Friday, September 2, 2016 3:04 PM
>> >> >> >> To: Wu, Feng 
>> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
>> xen-
>> >> >> >> de...@lists.xen.org 
>> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> >> >> assigning
>> >> >> >> PI hooks
>> >> >> >>
>> >> >> >> >>> On 02.09.16 at 03:46,  wrote:
>> >> >> >>
>> >> >> >> >
>> >> >> >> >> -Original Message-
>> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> >> >> >> Sent: Thursday, September 1, 2016 4:30 PM
>> >> >> >> >> To: Wu, Feng 
>> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
>> >> xen-
>> >> >> >> >> de...@lists.xen.org 
>> >> >> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain
>> before/after
>> >> >> >> assigning
>> >> >> >> >> PI hooks
>> >> >> >> >>
>> >> >> >> >> >>> On 31.08.16 at 05:56,  wrote:
>> >> >> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> >> >> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >> >> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain
>> *d)
>> >> >> >> >> >
>> >> >> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>> >> >> >> >> >
>> >> >> >> >> > +/*
>> >> >> >> >> > + * Pausing the domain can make sure the vCPU is not
>> >> >> >> >> > + * running and hence calling the hooks simultaneously
>> >> >> >> >> > + * when deassigning the PI hooks. This makes sure that
>> >> >> >> >> > + * all the appropriate state of PI descriptor is actually
>> >> >> >> >> > + * set up for all vCPus before leaving this function.
>> >> >> >> >> > + */
>> >> >> >> >> > +domain_pause(d);
>> >> >> >> >> > +
>> >> >> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
>> >> >> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
>> >> >> >> >> > +
>> >> >> >> >> > +domain_unpause(d);
>> >> >> >> >> >  }
>> >> >> >> >>
>> >> >> >> >> First of all I'm missing a word on whether the race mentioned in
>> >> >> >> >> the description and comment can actually happen. Device
>> >> >> >> >> (de)assignment should already be pretty much serialized (via
>> >> >> >> >> the domctl lock, and maybe also via the pcidevs one).
>> >> >> >> >
>> >> >> >> > The purpose of this patch is to address the race condition that
>> >> >> >> > the _vCPU_ is running while we are installing these hooks. Do you
>> >> >> >> > think this cannot happen?  This patch is trying to fix the issue
>> >> >> >> > described at:
>> >> >> >> > http://www.gossamer-threads.com/lists/xen/devel/433229 
>> >> >> >> > Consider that the other two hooks were installed when the VM
>> >> >> >> > is created, seems no such race condition. However, according
>> >> >> >> > to the discussion about patch 1 and patch 2 of series, we need
>> >> >> >> > to install the other two hooks here as well,
>> >> >> >>
>> >> >> >> I don't think we've agreed that the creation time installation of
>> >> >> >> those hooks is actually necessary. In fact your most recent
>> >> >> >> response to patch 1 makes me think you now 

[Xen-devel] [xen-unstable test] 100712: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100667
 build-amd64-rumpuserxen   6 xen-buildfail  like 100674
 build-i386-rumpuserxen6 xen-buildfail  like 100674
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100674
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100674
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100674
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100674

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

version targeted for testing:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca
baseline version:
 xen  4b314c89be24c26abfad47900f806cebeafc805e

Last test of basis   100674  2016-08-31 08:49:52 Z2 days
Failing since100681  2016-08-31 18:14:20 Z1 days5 attempts
Testing same since   100706  2016-09-01 19:14:21 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Feng Wu 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Wei Liu 

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 

Re: [Xen-devel] [PATCH v5 03/16] libxl/arm: Generate static ACPI DSDT table

[Wei Liu]

On Fri, Sep 02, 2016 at 10:55:26AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> It uses static DSDT table like the way x86 uses. Currently the DSDT
> table only contains processor device objects and it generates the
> maximal objects which so far is 128.
> 
> While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
> needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.
> 
> Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
> supported.
> 
> Signed-off-by: Shannon Zhao 
> ---
> Note: this patch needs to be rebased on Boris's v3 patchset for only 
> generating dsdt_anycpu_arm.c for ARM64.
> ---
>  tools/configure.ac|  2 +-

Note to Ian and myself: need to rerun autogen.sh while committing.

>  tools/libacpi/Makefile| 13 -
>  tools/libacpi/mk_dsdt.c   | 27 ++-

This could use review from Jan, Boris and Andrew.

>  tools/libxl/Makefile  |  5 -
>  tools/libxl/libxl_arm_acpi.c  |  5 +

Again, subject from an ack from ARM maintainers:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 02/16] libxl/arm: prepare for constructing ACPI tables

[Wei Liu]

On Fri, Sep 02, 2016 at 10:55:25AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> It only constructs the ACPI tables for 64-bit ARM DomU when user enables
> acpi because 32-bit DomU doesn't support ACPI. And the generation codes
> are only built for 64-bit toolstack.
> 
> Signed-off-by: Shannon Zhao 

The code looks reasonable to me.

Subject to an ack from ARM maintainers:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v5 01/16] tools/libxl: Add an unified configuration option for ACPI

[Wei Liu]

On Fri, Sep 02, 2016 at 10:55:24AM +0800, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Since the existing configuration option "u.hvm.acpi" is x86 specific and
> we want to reuse it on ARM as well, add a unified option "acpi" for
> x86 and ARM, and for ARM it's disabled by default.
> 
> Signed-off-by: Shannon Zhao 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [RFC] Classify and remove (some) abort()s in libxl

[Wei Liu]

Andrew and Doug, do you have more comments?

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep  fail REGR. vs. 100732

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

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0

Last test of basis   100732  2016-09-02 12:01:43 Z0 days
Testing same since   100733  2016-09-02 14:01:51 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Wei Liu 

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



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

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

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

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


Not pushing.


commit 158dd1bdca161a6456ee6be293969f87ecde3922
Author: Wei Liu 
Date:   Mon Aug 15 16:27:27 2016 +0100

tools: delete gtraceview and gtracestat

There has not been any substantial update to them since 2011. My quick
check shows that they don't work.

Just delete them. It would be easy to resurrect them from git log should
people still need them.

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 

commit 341e8c0b7a13fa5e23337e77b6df202c79e088da
Author: Jan Beulich 
Date:   Fri Sep 2 14:22:28 2016 +0200

x86/mm: drop pointless use of __FUNCTION__

Non-debugging message text should be (and is here) distinguishable
without also logging function names.

Signed-off-by: Jan Beulich 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Andrew Cooper 
Acked-by: George Dunlap 

commit 6dc9ac9f52b8651b5700e24567fadd5b2b61786d
Author: Jan Beulich 
Date:   Fri Sep 2 14:20:23 2016 +0200

x86emul: check alignment of SSE and AVX memory operands

It only now occurred to me that there's no new hook needed to do so.
Eliminate the two work item comments.

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

commit 8d6af808a7e9d9ae1d129e1e5a0def7f8b2333ee
Author: Jan Beulich 
Date:   Fri Sep 2 14:19:51 2016 +0200

memory: fix compat handling of XENMEM_access_op

Within compat_memory_op() this needs to be placed in the first switch()
statement, or it ends up being dead code (as that first switch() has a
default case chaining to compat_arch_memory_op()).

Signed-off-by: Jan Beulich 
Tested-by: Razvan Cojocaru 
Reviewed-by: Andrew Cooper 

commit bea64b3ed25864b90a41e1ca6eeb5a58895bb751
Author: Jan Beulich 
Date:   Fri Sep 2 14:19:29 2016 +0200

x86/PV: make PMU MSR handling consistent

So far accesses to Intel MSRs on an AMD system fall through to the
default case, while accesses to AMD MSRs on an Intel system bail (in
the RDMSR case without updating EAX and EDX). Make the "AMD MSRs on
Intel" case match the "Intel MSR on AMD" one.

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

commit f8f185dc4359a1cd8e7896dfbcacb54b473436c8
Author: Jan Beulich 
Date:   Fri Sep 2 14:18:52 2016 

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Julien Grall]

On 02/09/16 14:22, Razvan Cojocaru wrote:
> On 09/02/2016 04:17 PM, Julien Grall wrote:
>> Hello Razvan,
> 
> Hello Julien, thanks for the email!
> 
>> On 02/09/16 09:51, Razvan Cojocaru wrote:
>>> Currently it is only possible to set mem_access restrictions only for
>>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>>> This patch introduces a new libxc function taking an array of GFNs.
>>> The alternative would be to set each page in turn, using a userspace-HV
>>> roundtrip for each call, and triggering a TLB flush per page set.
>>>
>>> Signed-off-by: Razvan Cojocaru 
>>>
>>> ---
>>> Changes since V1 / RFC:
>>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>>>and XENMEM_access_op_set_access_sparse to
>>>XENMEM_access_op_set_access_multi.
>>>  - Renamed the 'nr' parameter to 'size'.
>>>  - Wrapped long line in the implementation of xc_set_mem_access_multi().
>>>  - Factored out common code in _p2m_set_mem_access() (and modified
>>>p2m_set_altp2m_mem_access() in the process, to take an unsigned
>>>long argument instead of a gfn_t).
>>>  - Factored out xenmem_access_t to p2m_access_t conversion code in
>>>p2m_xenmem_access_to_p2m_access().
>>>  - Added hypercall continuation support.
>>>  - Added compat translation support.
>>>  - No longer allocating buffers (now using copy_from_guest_offset()).
>>>  - Added support for setting an array of access restrictions, as
>>>suggested by Tamas Lengyel.
>>>  - This patch incorporates Jan Beulich's "memory: fix compat handling
>>>of XENMEM_access_op".
>>> ---
>>>  tools/libxc/include/xenctrl.h |   4 ++
>>>  tools/libxc/xc_mem_access.c   |  38 ++
>>>  xen/arch/x86/mm/p2m.c | 161
>>> --
>>>  xen/common/compat/memory.c|  24 +--
>>>  xen/common/mem_access.c   |  11 +++
>>>  xen/include/public/memory.h   |  14 +++-
>>>  xen/include/xen/p2m-common.h  |   6 ++
>>
>> p2m-common.h contains prototype common between ARM and x86. I would have
>> expected to see a change in the ARM port because of that.
> 
> The only change to p2m-common.h is the addition of a single function,
> p2m_set_mem_access_multi(). As long as the ARM bits don't make use of
> it, there's nothing to modify there.

p2m_set_mem_access_multi is called from common code. If you had tried
to build Xen on ARM you would have noticed a compilation error:

prelink.o: In function `mem_access_memop':
/local/home/julieng/works/xen/xen/common/mem_access.c:80: undefined reference 
to `p2m_set_mem_access_multi'
aarch64-linux-gnu-ld: /local/home/julieng/works/xen/xen/.xen-syms.0: hidden 
symbol `p2m_set_mem_access_multi' isn't defined

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/02/2016 04:26 PM, Julien Grall wrote:
> 
> 
> On 02/09/16 14:22, Razvan Cojocaru wrote:
>> On 09/02/2016 04:17 PM, Julien Grall wrote:
>>> Hello Razvan,
>>
>> Hello Julien, thanks for the email!
>>
>>> On 02/09/16 09:51, Razvan Cojocaru wrote:
 Currently it is only possible to set mem_access restrictions only for
 a contiguous range of GFNs (or, as a particular case, for a single GFN).
 This patch introduces a new libxc function taking an array of GFNs.
 The alternative would be to set each page in turn, using a userspace-HV
 roundtrip for each call, and triggering a TLB flush per page set.

 Signed-off-by: Razvan Cojocaru 

 ---
 Changes since V1 / RFC:
  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
and XENMEM_access_op_set_access_sparse to
XENMEM_access_op_set_access_multi.
  - Renamed the 'nr' parameter to 'size'.
  - Wrapped long line in the implementation of xc_set_mem_access_multi().
  - Factored out common code in _p2m_set_mem_access() (and modified
p2m_set_altp2m_mem_access() in the process, to take an unsigned
long argument instead of a gfn_t).
  - Factored out xenmem_access_t to p2m_access_t conversion code in
p2m_xenmem_access_to_p2m_access().
  - Added hypercall continuation support.
  - Added compat translation support.
  - No longer allocating buffers (now using copy_from_guest_offset()).
  - Added support for setting an array of access restrictions, as
suggested by Tamas Lengyel.
  - This patch incorporates Jan Beulich's "memory: fix compat handling
of XENMEM_access_op".
 ---
  tools/libxc/include/xenctrl.h |   4 ++
  tools/libxc/xc_mem_access.c   |  38 ++
  xen/arch/x86/mm/p2m.c | 161
 --
  xen/common/compat/memory.c|  24 +--
  xen/common/mem_access.c   |  11 +++
  xen/include/public/memory.h   |  14 +++-
  xen/include/xen/p2m-common.h  |   6 ++
>>>
>>> p2m-common.h contains prototype common between ARM and x86. I would have
>>> expected to see a change in the ARM port because of that.
>>
>> The only change to p2m-common.h is the addition of a single function,
>> p2m_set_mem_access_multi(). As long as the ARM bits don't make use of
>> it, there's nothing to modify there.
> 
> p2m_set_mem_access_multi is called from common code. If you had tried
> to build Xen on ARM you would have noticed a compilation error:
> 
> prelink.o: In function `mem_access_memop':
> /local/home/julieng/works/xen/xen/common/mem_access.c:80: undefined reference 
> to `p2m_set_mem_access_multi'
> aarch64-linux-gnu-ld: /local/home/julieng/works/xen/xen/.xen-syms.0: hidden 
> symbol `p2m_set_mem_access_multi' isn't defined

I see. Sorry about that. I'll fix that in V3.


Thanks,
Razvan


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

Re: [Xen-devel] [PATCH] tools: delete gtraceview and gtracestat

[Wei Liu]

On Fri, Sep 02, 2016 at 12:36:21PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [PATCH] tools: delete gtraceview and gtracestat"):
> > On Fri, Sep 02, 2016 at 12:13:04PM +0100, George Dunlap wrote:
> > > If so, it's probably just the case that the trace record format has
> > > changed somewhat and these weren't updated.  It would probably be fairly
> > > straightforward to fix; but if nobody's using it, I'd just as soon
> > > delete it.  The "gtracestat" functionality would probably better be
> > > added to xenalyze in any case.
> > 
> > Yes. I agree.
> 
> OK, thanks for the discussion.  I'm sold.
> 
> Acked-by: Ian Jackson 

Pushed with your ack. Thanks.

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/02/2016 04:17 PM, Julien Grall wrote:
> Hello Razvan,

Hello Julien, thanks for the email!

> On 02/09/16 09:51, Razvan Cojocaru wrote:
>> Currently it is only possible to set mem_access restrictions only for
>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>> This patch introduces a new libxc function taking an array of GFNs.
>> The alternative would be to set each page in turn, using a userspace-HV
>> roundtrip for each call, and triggering a TLB flush per page set.
>>
>> Signed-off-by: Razvan Cojocaru 
>>
>> ---
>> Changes since V1 / RFC:
>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>>and XENMEM_access_op_set_access_sparse to
>>XENMEM_access_op_set_access_multi.
>>  - Renamed the 'nr' parameter to 'size'.
>>  - Wrapped long line in the implementation of xc_set_mem_access_multi().
>>  - Factored out common code in _p2m_set_mem_access() (and modified
>>p2m_set_altp2m_mem_access() in the process, to take an unsigned
>>long argument instead of a gfn_t).
>>  - Factored out xenmem_access_t to p2m_access_t conversion code in
>>p2m_xenmem_access_to_p2m_access().
>>  - Added hypercall continuation support.
>>  - Added compat translation support.
>>  - No longer allocating buffers (now using copy_from_guest_offset()).
>>  - Added support for setting an array of access restrictions, as
>>suggested by Tamas Lengyel.
>>  - This patch incorporates Jan Beulich's "memory: fix compat handling
>>of XENMEM_access_op".
>> ---
>>  tools/libxc/include/xenctrl.h |   4 ++
>>  tools/libxc/xc_mem_access.c   |  38 ++
>>  xen/arch/x86/mm/p2m.c | 161
>> --
>>  xen/common/compat/memory.c|  24 +--
>>  xen/common/mem_access.c   |  11 +++
>>  xen/include/public/memory.h   |  14 +++-
>>  xen/include/xen/p2m-common.h  |   6 ++
> 
> p2m-common.h contains prototype common between ARM and x86. I would have
> expected to see a change in the ARM port because of that.

The only change to p2m-common.h is the addition of a single function,
p2m_set_mem_access_multi(). As long as the ARM bits don't make use of
it, there's nothing to modify there.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Tamas K Lengyel]

On Sep 2, 2016 09:03, "Jan Beulich"  wrote:
>
> >>> On 02.09.16 at 16:50,  wrote:
> > On Sep 2, 2016 05:45, "Jan Beulich"  wrote:
> >>
> >> >>> On 02.09.16 at 13:18,  wrote:
> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
> >> > On 02.09.16 at 10:51,  wrote:
> >> >>> Changes since V1 / RFC:
> >> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
> >> >>>and XENMEM_access_op_set_access_sparse to
> >> >>>XENMEM_access_op_set_access_multi.
> >> >>>  - Renamed the 'nr' parameter to 'size'.
> >> >>
> >> >> Why?
> >> >
> >> > Tamas suggested it, size sounded more intuitive to him. I have no
> >> > problem with either nr or size.
> >>
> >> Size to me means something in bytes, which clearly isn't the case
> >> here. There's not even support for other then 4k pages so far.
> >
> > Lets make it array_size then to clarify?
>
> What's wrong with "nr", matching the other (existing) function?
>

IMHO it's too generic. So either a more descriptive name or a comment is
warranted to explain the inputs.

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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 2, 2016 6:46 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> >>> On 02.09.16 at 12:30,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, September 2, 2016 5:26 PM
> >> To: Wu, Feng 
> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> >> de...@lists.xen.org
> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> assigning
> >> PI hooks
> >>
> >> >>> On 02.09.16 at 10:40,  wrote:
> >>
> >> >
> >> >> -Original Message-
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: Friday, September 2, 2016 4:16 PM
> >> >> To: Wu, Feng 
> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> >> >> de...@lists.xen.org
> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> >> assigning
> >> >> PI hooks
> >> >>
> >> >> >>> On 02.09.16 at 09:31,  wrote:
> >> >>
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> >> Sent: Friday, September 2, 2016 3:04 PM
> >> >> >> To: Wu, Feng 
> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
> xen-
> >> >> >> de...@lists.xen.org
> >> >> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> >> >> assigning
> >> >> >> PI hooks
> >> >> >>
> >> >> >> >>> On 02.09.16 at 03:46,  wrote:
> >> >> >>
> >> >> >> >
> >> >> >> >> -Original Message-
> >> >> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> >> >> Sent: Thursday, September 1, 2016 4:30 PM
> >> >> >> >> To: Wu, Feng 
> >> >> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> >> >> george.dun...@eu.citrix.com; Tian, Kevin ;
> >> xen-
> >> >> >> >> de...@lists.xen.org
> >> >> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain
> before/after
> >> >> >> assigning
> >> >> >> >> PI hooks
> >> >> >> >>
> >> >> >> >> >>> On 31.08.16 at 05:56,  wrote:
> >> >> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> >> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> >> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain
> *d)
> >> >> >> >> >
> >> >> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> >> >> >> >> >
> >> >> >> >> > +/*
> >> >> >> >> > + * Pausing the domain can make sure the vCPU is not
> >> >> >> >> > + * running and hence calling the hooks simultaneously
> >> >> >> >> > + * when deassigning the PI hooks. This makes sure that
> >> >> >> >> > + * all the appropriate state of PI descriptor is actually
> >> >> >> >> > + * set up for all vCPus before leaving this function.
> >> >> >> >> > + */
> >> >> >> >> > +domain_pause(d);
> >> >> >> >> > +
> >> >> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> >> >> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> >> >> >> >> > +
> >> >> >> >> > +domain_unpause(d);
> >> >> >> >> >  }
> >> >> >> >>
> >> >> >> >> First of all I'm missing a word on whether the race mentioned in
> >> >> >> >> the description and comment can actually happen. Device
> >> >> >> >> (de)assignment should already be pretty much serialized (via
> >> >> >> >> the domctl lock, and maybe also via the pcidevs one).
> >> >> >> >
> >> >> >> > The purpose of this patch is to address the race condition that
> >> >> >> > the _vCPU_ is running while we are installing these hooks. Do you
> >> >> >> > think this cannot happen?  This patch is trying to fix the issue
> >> >> >> > described at:
> >> >> >> > http://www.gossamer-threads.com/lists/xen/devel/433229
> >> >> >> > Consider that the other two hooks were installed when the VM
> >> >> >> > is created, seems no such race condition. However, according
> >> >> >> > to the discussion about patch 1 and patch 2 of series, we need
> >> >> >> > to install the other two hooks here as well,
> >> >> >>
> >> >> >> I don't think we've agreed that the creation time installation of
> >> >> >> those hooks is actually necessary. In fact your most recent
> >> >> >> response to patch 1 makes me think you now agree we don't
> >> >> >> need to do so. And hence with that precondition not holding
> >> >> >> anymore, I don't think the conclusion does.
> >> >> >
> >> >> > I think 

Re: [Xen-devel] [PATCH] x86: correct CPUID output for out of bounds input

[Andrew Cooper]

On 01/09/16 16:27, Jan Beulich wrote:
>
>>> +{
>>> +if ( d->arch.x86_vendor == X86_VENDOR_AMD )
>>> +{
>>> +*eax = 0;
>>> +*ebx = 0;
>>> +*ecx = 0;
>>> +*edx = 0;
>>> +return;
>>> +}
>>> +if ( input >> 16 )
>>> +hvm_cpuid(0, , NULL, NULL, NULL);
>> Is this really the right way round?  The AMD method of "reserved always
>> as zero" is the more sane default to take.
> If anything I'd then say let's _always_ follow the AMD model.

It would certainly be better to default to AMD, and special case others
on an as-needed basis.

Strictly speaking, following the AMD model is compatible with the
"Reserved" nature specified for Intel.

Lets just go with this.

~Andrew

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/02/2016 06:13 PM, Tamas K Lengyel wrote:
> On Sep 2, 2016 09:03, "Jan Beulich"  > wrote:
>>
>> >>> On 02.09.16 at 16:50,  > wrote:
>> > On Sep 2, 2016 05:45, "Jan Beulich"  > wrote:
>> >>
>> >> >>> On 02.09.16 at 13:18,  > wrote:
>> >> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> >> > On 02.09.16 at 10:51,  > wrote:
>> >> >>> Changes since V1 / RFC:
>> >> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>> >> >>>and XENMEM_access_op_set_access_sparse to
>> >> >>>XENMEM_access_op_set_access_multi.
>> >> >>>  - Renamed the 'nr' parameter to 'size'.
>> >> >>
>> >> >> Why?
>> >> >
>> >> > Tamas suggested it, size sounded more intuitive to him. I have no
>> >> > problem with either nr or size.
>> >>
>> >> Size to me means something in bytes, which clearly isn't the case
>> >> here. There's not even support for other then 4k pages so far.
>> >
>> > Lets make it array_size then to clarify?
>>
>> What's wrong with "nr", matching the other (existing) function?
>>
> 
> IMHO it's too generic. So either a more descriptive name or a comment is
> warranted to explain the inputs.

If this satisfies everybody, I'll keep 'nr' and add a comment describing
the function and parameters (which is a good thing anyway).


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

[Jan Beulich]

>>> On 19.08.16 at 19:22,  wrote:
> @@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +int
> +hvm_altp2m_init( struct domain *d)

Stray blank (more elsewhere). Also I don't think hvm_ is a proper
prefix for a function placed in this file, i.e. if altp2m_init() is used
elsewhere already, then altp2m_hvm_init() or perhaps better
altp2m_domain_init() please.

> +{
> +int rc = 0;
> +unsigned int i = 0;

Pointless initializers.

> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}

When the epilogue (after the target label) is just a return statement,
please avoid using goto.

> +void
> +hvm_altp2m_teardown( struct domain *d)
> +{
> +unsigned int i = 0;
> +d->arch.altp2m_active = 0;
> +
> +if ( d->arch.altp2m_eptp )
> +{
> +free_xenheap_page(d->arch.altp2m_eptp);
> +d->arch.altp2m_eptp = NULL;
> +}

Please avoid the if() - free_xenheap_page() happily deals with a
NULL pointer passed to it.

> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +p2m_teardown(d->arch.altp2m_p2m[i]);

I realize it's been that way in the original code, but wouldn't swapping
the two things be both more natural and more robust?

> @@ -501,24 +502,9 @@ int hap_enable(struct domain *d, u32 mode)
>  
>  if ( hvm_altp2m_supported() )
>  {
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> -}
> -
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> -
> -d->arch.altp2m_active = 0;
> +rv = hvm_altp2m_init(d);
> +if ( rv != 0 )
> +   goto out;
>  }
>  
>  /* Now let other users see the new mode */
> @@ -534,18 +520,7 @@ void hap_final_teardown(struct domain *d)
>  unsigned int i;
>  
>  if ( hvm_altp2m_supported() )
> -{
> -d->arch.altp2m_active = 0;
> -
> -if ( d->arch.altp2m_eptp )
> -{
> -free_xenheap_page(d->arch.altp2m_eptp);
> -d->arch.altp2m_eptp = NULL;
> -}
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -p2m_teardown(d->arch.altp2m_p2m[i]);
> -}
> +hvm_altp2m_teardown(d);

I wonder whether in both cases the hvm_altp2m_supported()
would better also be moved into the functions.

It looks like the parts above and below this point, except for header
file adjustments, are completely independent. Please consider
splitting into two patches.

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
>  register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
>  }
>  
> +void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)

Please drop the _helper suffix now that there is _ept.

Jan


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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Wei Liu]

On Tue, Aug 30, 2016 at 12:02:26PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
> > Well, in a way. And then not: Initially I had thought no issue would
> > arise, until I came to realize the kernel memory corruption potential.
> > Question is whether now we're overlooking some other not
> > immediately obvious issue. The problem with auditing is that
> > generally you can only look for things you're aware of (or magically
> > become aware of while looking at the code). But I guess we should
> > just go ahead with the patterns we know of.
> 
> I think so, yes.  I will take a look at the interfaces, at least, to
> see if I can spot anything missing.  This will probably generate some
> more stupid questions...
> 
> So, then, is everyone now happy with the overall approach ?  That is,
> as I wrote up in:
>   Message-ID: <22464.10246.708893.563...@mariner.uk.xensource.com>
>   Subject: Re: Device model operation hypercall (DMOP, re qemu depriv)
>   Date: Fri, 26 Aug 2016 12:29:10 +0100
> 

It looks like a reasonable plan to me.

Wei.

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Jan Beulich]

>>> On 02.09.16 at 16:50,  wrote:
> On Sep 2, 2016 05:45, "Jan Beulich"  wrote:
>>
>> >>> On 02.09.16 at 13:18,  wrote:
>> > On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> > On 02.09.16 at 10:51,  wrote:
>> >>> Changes since V1 / RFC:
>> >>>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>> >>>and XENMEM_access_op_set_access_sparse to
>> >>>XENMEM_access_op_set_access_multi.
>> >>>  - Renamed the 'nr' parameter to 'size'.
>> >>
>> >> Why?
>> >
>> > Tamas suggested it, size sounded more intuitive to him. I have no
>> > problem with either nr or size.
>>
>> Size to me means something in bytes, which clearly isn't the case
>> here. There's not even support for other then 4k pages so far.
> 
> Lets make it array_size then to clarify?

What's wrong with "nr", matching the other (existing) function?

Jan


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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/02/2016 04:10 PM, Jan Beulich wrote:
 On 02.09.16 at 15:03,  wrote:
>> On 09/02/2016 03:56 PM, Jan Beulich wrote:
>> On 02.09.16 at 14:41,  wrote:
 On 09/02/2016 03:33 PM, Jan Beulich wrote:
 On 02.09.16 at 14:21,  wrote:
>> On 09/02/2016 01:02 PM, Jan Beulich wrote:
 +/*
> + * Corresponding list of access settings for pfn_list
> + * Used only with XENMEM_access_op_set_access_multi
> + */
> +XEN_GUEST_HANDLE(uint8) access_list;
>>> And for both of them - I don't think the arrays are meant to be
>>> used for output? In which case they should be handles of const
>>> types.
>>
>> Actually I can't seem to be able to find a magic combination that works.
>>
>> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>>
>> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
>> name a type
>>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>>
>> which is fair. I've tried:
>>
>> XEN_GUEST_HANDLE(const_uint8) access_list;
>>
>> which does go further with the compilation process, but still kills it 
>> with:
>>
>> xen/include/compat/memory.h:154:5: error: unknown type name
>> '__compat_handle_const_uint8'
>>  COMPAT_HANDLE(const_uint8) access_list;
>>
>> What would be the appropriate const type to use here?
>
> This one. Did you check that handle actually gets created? Per
> my brief checking it doesn't look so. And neither the native one.

 Running ./configure again, followed by 'make clean' and a new 'make
 dist' didn't help, so if it's supposed to be generated automatically it
 doesn't seem to be (or I'm doing something wrong). I'll investigate more.
>>>
>>> The compat one is supposed to get auto-generated once the native
>>> one is there.
>>
>> Changing both handles to XEN_GUEST_HANLDE(const_void) compiles cleanly.
>> As soon as I change to either XEN_GUEST_HANLDE(const_uint8) or
>> XEN_GUEST_HANLDE(const_uint64) I start getting errors.
>>
>> Previously the auto-generation seems to have worked fine, so this is
>> likely something more subtle.
> 
> Oh, I see where the issue is: Both DEFINE_XEN_GUEST_HANDLE()
> and __DEFINE_XEN_GUEST_HANDLE() auto-magically produce const
> counterparts, but while DEFINE_COMPAT_HANDLE() does too,
> __DEFINE_COMPAT_HANDLE() doesn't. That'll need fixing, I think.

I see it, thanks! I'll submit a small patch shortly.


Thanks,
Razvan


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

[Xen-devel] [PATCH] xen: Have __DEFINE_COMPAT_HANDLE() generate const versions

[Razvan Cojocaru]

Both DEFINE_XEN_GUEST_HANDLE() and __DEFINE_XEN_GUEST_HANDLE()
each produce both const and non-const handles,
only DEFINE_COMPAT_HANDLE() does (__DEFINE_COMPAT_HANDLE()
does not). This patch has __DEFINE_COMPAT_HANDLE() also
produce a const handle.

Suggested-by: Jan Beulich 
Signed-off-by: Razvan Cojocaru 
---
 xen/include/xen/compat.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/include/xen/compat.h b/xen/include/xen/compat.h
index 3f4cef6..ce913ac 100644
--- a/xen/include/xen/compat.h
+++ b/xen/include/xen/compat.h
@@ -15,11 +15,14 @@
 typedef struct { \
 compat_ptr_t c; \
 type *_[0] __packed; \
-} __compat_handle_ ## name
+} __compat_handle_ ## name; \
+typedef struct { \
+compat_ptr_t c; \
+const type *_[0] __packed; \
+} __compat_handle_const_ ## name
 
 #define DEFINE_COMPAT_HANDLE(name) \
-__DEFINE_COMPAT_HANDLE(name, name); \
-__DEFINE_COMPAT_HANDLE(const_ ## name, const name)
+__DEFINE_COMPAT_HANDLE(name, name)
 #define COMPAT_HANDLE(name)  __compat_handle_ ## name
 
 /* NB: it is assumed that if an arch uses the compat layer it does not
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] docs: document old SUSE/Novell unplug for HVM

[Wei Liu]

On Fri, Sep 02, 2016 at 11:32:55AM +0200, Olaf Hering wrote:
> Signed-off-by: Olaf Hering 

More document is always a good thing. :-)

I will leave the review to Konrad and Stefano because I don't know
enough about this.

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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Wei Liu]

Thanks for posting.

I go over all the patches and I think this series is in good shape. I
will defer most of the table construction code to ARM maintainers.

Wei.

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Julien Grall]

Hello Razvan,

On 02/09/16 09:51, Razvan Cojocaru wrote:

Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for each call, and triggering a TLB flush per page set.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1 / RFC:
 - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
   and XENMEM_access_op_set_access_sparse to
   XENMEM_access_op_set_access_multi.
 - Renamed the 'nr' parameter to 'size'.
 - Wrapped long line in the implementation of xc_set_mem_access_multi().
 - Factored out common code in _p2m_set_mem_access() (and modified
   p2m_set_altp2m_mem_access() in the process, to take an unsigned
   long argument instead of a gfn_t).
 - Factored out xenmem_access_t to p2m_access_t conversion code in
   p2m_xenmem_access_to_p2m_access().
 - Added hypercall continuation support.
 - Added compat translation support.
 - No longer allocating buffers (now using copy_from_guest_offset()).
 - Added support for setting an array of access restrictions, as
   suggested by Tamas Lengyel.
 - This patch incorporates Jan Beulich's "memory: fix compat handling
   of XENMEM_access_op".
---
 tools/libxc/include/xenctrl.h |   4 ++
 tools/libxc/xc_mem_access.c   |  38 ++
 xen/arch/x86/mm/p2m.c | 161 --
 xen/common/compat/memory.c|  24 +--
 xen/common/mem_access.c   |  11 +++
 xen/include/public/memory.h   |  14 +++-
 xen/include/xen/p2m-common.h  |   6 ++


p2m-common.h contains prototype common between ARM and x86. I would have 
expected to see a change in the ARM port because of that.


Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0
baseline version:
 xen  c8777e62d9af845b5fd158684eaed10918fc5cf8

Last test of basis   100720  2016-09-02 09:01:31 Z0 days
Testing same since   100732  2016-09-02 12:01:43 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Tim Deegan 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f59174d7e5fb8bb530246003d373345b5b433ea0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
f59174d7e5fb8bb530246003d373345b5b433ea0
+ branch=xen-unstable-smoke
+ revision=f59174d7e5fb8bb530246003d373345b5b433ea0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xf59174d7e5fb8bb530246003d373345b5b433ea0 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local 

Re: [Xen-devel] [PATCH linux v3 3/9] xen: introduce xen_vcpu_id mapping

[Julien Grall]

Hi Vitaly,

On 26/07/16 13:30, Vitaly Kuznetsov wrote:

It may happen that Xen's and Linux's ideas of vCPU id diverge. In
particular, when we crash on a secondary vCPU we may want to do kdump
and unlike plain kexec where we do migrate_to_reboot_cpu() we try booting
on the vCPU which crashed. This doesn't work very well for PVHVM guests as
we have a number of hypercalls where we pass vCPU id as a parameter. These
hypercalls either fail or do something unexpected. To solve the issue
introduce percpu xen_vcpu_id mapping. ARM and PV guests get direct mapping
for now. Boot CPU for PVHVM guest gets its id from CPUID. With secondary
CPUs it is a bit more trickier. Currently, we initialize IPI vectors
before these CPUs boot so we can't use CPUID. Use ACPI ids from MADT
instead.

Signed-off-by: Vitaly Kuznetsov 
---
Changes since v2:
- Use uint32_t for xen_vcpu_id mapping [Julien Grall]

Changes since v1:
- Introduce xen_vcpu_nr() helper [David Vrabel]
- Use ACPI ids instead of vLAPIC ids /2 [Andrew Cooper, Jan Beulich]
---
 arch/arm/xen/enlighten.c | 10 ++
 arch/x86/xen/enlighten.c | 23 ++-
 include/xen/xen-ops.h|  6 ++
 3 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 75cd734..fe32267 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -46,6 +46,10 @@ struct shared_info *HYPERVISOR_shared_info = (void 
*)_dummy_shared_info;
 DEFINE_PER_CPU(struct vcpu_info *, xen_vcpu);
 static struct vcpu_info __percpu *xen_vcpu_info;

+/* Linux <-> Xen vCPU id mapping */
+DEFINE_PER_CPU(uint32_t, xen_vcpu_id) = U32_MAX;
+EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
+
 /* These are unused until we support booting "pre-ballooned" */
 unsigned long xen_released_pages;
 struct xen_memory_region xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
@@ -179,6 +183,9 @@ static void xen_percpu_init(void)
pr_info("Xen: initializing cpu%d\n", cpu);
vcpup = per_cpu_ptr(xen_vcpu_info, cpu);

+   /* Direct vCPU id mapping for ARM guests. */
+   per_cpu(xen_vcpu_id, cpu) = cpu;
+


We did some internal testing on ARM64 with the latest Linux kernel 
(4.8-rc4) and noticed that this patch is breaking SMP support. Sorry for 
noticing the issue that late.


This function is called on the running CPU whilst some code (e.g 
init_control_block in drivers/xen/events/events_fifo.c) is executed 
whilst preparing the CPU on the boot CPU.


So xen_vcpu_nr(cpu) will always return 0 in this case and 
init_control_block will fail to execute.


I am not sure how to fix. I guess we could setup per_cpu(xen_vcpu_id, *) 
in xen_guest_init. Any opinions?


[...]


diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0f87db2..c833912 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1795,6 +1806,12 @@ static void __init init_hvm_pv_info(void)

xen_setup_features();

+   cpuid(base + 4, , , , );
+   if (eax & XEN_HVM_CPUID_VCPU_ID_PRESENT)
+   this_cpu_write(xen_vcpu_id, ebx);
+   else
+   this_cpu_write(xen_vcpu_id, smp_processor_id());
+
pv_info.name = "Xen HVM";

xen_domain_type = XEN_HVM_DOMAIN;
@@ -1806,6 +1823,10 @@ static int xen_hvm_cpu_notify(struct notifier_block 
*self, unsigned long action,
int cpu = (long)hcpu;
switch (action) {
case CPU_UP_PREPARE:
+   if (cpu_acpi_id(cpu) != U32_MAX)
+   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
+   else
+   per_cpu(xen_vcpu_id, cpu) = cpu;


I have not tried myself. But looking at the code, the notifiers 
xen_hvm_cpu_notifier and evtchn_fifo_cpu_notifier have the same 
priority. So what does prevent the code above to be executed after the 
event channel callback?



xen_vcpu_setup(cpu);
if (xen_have_vector_callback) {
if (xen_feature(XENFEAT_hvm_safe_pvclock))
diff --git a/include/xen/xen-ops.h b/include/xen/xen-ops.h
index 86abe07..648ce814 100644
--- a/include/xen/xen-ops.h
+++ b/include/xen/xen-ops.h
@@ -9,6 +9,12 @@

 DECLARE_PER_CPU(struct vcpu_info *, xen_vcpu);

+DECLARE_PER_CPU(uint32_t, xen_vcpu_id);
+static inline int xen_vcpu_nr(int cpu)
+{
+   return per_cpu(xen_vcpu_id, cpu);
+}
+
 void xen_arch_pre_suspend(void);
 void xen_arch_post_suspend(int suspend_cancelled);


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 4/5] gcov: add option to determine gcov format

[Wei Liu]

On Fri, Sep 02, 2016 at 01:08:27PM +0100, Wei Liu wrote:
> On Fri, Sep 02, 2016 at 06:01:22AM -0600, Jan Beulich wrote:
> > >>> On 02.09.16 at 13:47,  wrote:
> > > Currently only gcc 3.4 format is supported.
> > 
> > Doesn't this patch contradict your coverage letter? Here you provide
> > means to add support for further formats, but there you said there's
> > no obvious route to that goal.
> > 
> 
> There is a way, we can ditch the old interface and just hand back the
> blob.
> 

Let me try to make myself clearer because now I reread my reply it
doesn't seem to convey my thought.

There are two issues:

1. The sysctl interface is tied to gcc 3.4 format.
2. The implementation inside Xen is tied to gcc 3.4 format.

My cover letter was referring to #1 because there is no way to fit newer
gcc format into the existing Xen sysctl coverage interface. To solve #1
I'm afraid we need to design new interfaces.

#2 is independent of #1. Regardless of what the sysctl interface looks
like, Xen needs to know which format to use (size of the structure,
offset of fields etc) in order to extract information.

This patch (sorta) deals with #2 and is one step towards dealing with
#1.

Wei.

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

[Xen-devel] [PATCH] libxc: zero-initialize structures in macros

[Tamas K Lengyel]

While debugging applications built on top of libxc with Valgrind we get a lot
of complaining about relying on uninitialized values allocated in libxc.
While these warnings are safe to ignore, zero-initializing the structures
reduces Valgrind clutter a lot and aids in spotting real bugs.

Signed-off-by: Tamas K Lengyel 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/xc_private.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index 75b761c..4e9073b 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -59,11 +59,11 @@ struct iovec {
 #include 
 #endif
 
-#define DECLARE_DOMCTL struct xen_domctl domctl
-#define DECLARE_SYSCTL struct xen_sysctl sysctl
-#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
-#define DECLARE_FLASK_OP struct xen_flask_op op
-#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
+#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
+#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
+#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
+#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
+#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}
 
 #undef PAGE_SHIFT
 #undef PAGE_SIZE
-- 
2.9.3


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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Tamas K Lengyel]

On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall  wrote:
> On 02/09/2016 18:45, Andrew Cooper wrote:
>>
>> On 02/09/16 18:37, Tamas K Lengyel wrote:
>>>
>>> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>>>  wrote:

 On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>
> Add support for getting/setting registers through vm_event on ARM. Only
> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is
> set
> as part of a response. The set of registers can be expanded in the
> future to
> include other registers as well if necessary.
>
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Andrew Cooper 

 Acked-by: Razvan Cojocaru 
>>>
>>> Patch ping.
>>
>>
>> Requires an ARM ack.
>
>
> I don't think it requires an ack from Stefano and I, it touches only the
> vm_event subsystem.
>
> If you still want an ARM ack, then I will defer to Stefano.

Indeed it only touches the vm_event system so just wanted to double
check it's OK from your side as we had lengthy discussion about it. If
there are no objections a formal ack should not be necessary and it's
good to go.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH v3] mem_access: sanitize code around sending vm_event request

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 12:41 PM, Tamas K Lengyel
 wrote:
> The two functions monitor_traps and mem_access_send_req duplicate some of the
> same functionality. The mem_access_send_req however leaves a lot of the
> standard vm_event fields to be filled by other functions.
>
> Remove mem_access_send_req() completely, making use of monitor_traps() to put
> requests into the monitor ring.  This in turn causes some cleanup around the
> old callsites of mem_access_send_req(). We also update monitor_traps to now
> include setting the common vcpu_id field so that all other call-sites can 
> ommit
> this step.
>
> Finally, this change identifies that errors from mem_access_send_req() were
> never checked.  As errors constitute a problem with the monitor ring,
> crashing the domain is the most appropriate action to take.
>
> Signed-off-by: Tamas K Lengyel 
> Reviewed-by: Andrew Cooper 
> Acked-by: Razvan Cojocaru 
> ---
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: Jan Beulich 
> Cc: George Dunlap 
>
> v3: reduce the code movement and sanitization performed to a minimum

Patch ping. Needs an ARM ack (George has acked v2 for x86 that I
forgot to update in the patch message).

Tamas

> ---
>  xen/arch/arm/p2m.c   | 15 ---
>  xen/arch/x86/hvm/hvm.c   | 18 --
>  xen/arch/x86/hvm/monitor.c   |  5 -
>  xen/arch/x86/mm/p2m.c| 26 +-
>  xen/common/mem_access.c  | 11 ---
>  xen/common/monitor.c |  2 ++
>  xen/include/asm-x86/p2m.h| 13 -
>  xen/include/xen/mem_access.h |  7 ---
>  8 files changed, 31 insertions(+), 66 deletions(-)
>
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 40a0b80..a3f05b4 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -5,7 +5,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1740,10 +1740,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  {
>  req->reason = VM_EVENT_REASON_MEM_ACCESS;
>
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
> -
>  /* Send request to mem access subscriber */
>  req->u.mem_access.gfn = gpa >> PAGE_SHIFT;
>  req->u.mem_access.offset =  gpa & ((1 << PAGE_SHIFT) - 1);
> @@ -1760,16 +1756,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
> -req->vcpu_id = v->vcpu_id;
>
> -mem_access_send_req(v->domain, req);
> +if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
> +domain_crash(v->domain);
> +
>  xfree(req);
>  }
>
> -/* Pause the current VCPU */
> -if ( xma != XENMEM_access_n2rwx )
> -vm_event_vcpu_pause(v);
> -
>  return false;
>  }
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index daaee1d..42f163e 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  int rc, fall_through = 0, paged = 0;
>  int sharing_enomem = 0;
>  vm_event_request_t *req_ptr = NULL;
> -bool_t ap2m_active;
> +bool_t ap2m_active, sync = 0;
>
>  /* On Nested Virtualization, walk the guest page table.
>   * If this succeeds, all is fine.
> @@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
> long gla,
>  }
>  }
>
> -if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) )
> -{
> +sync = p2m_mem_access_check(gpa, gla, npfec, _ptr);
> +
> +if ( !sync )
>  fall_through = 1;
> -} else {
> -/* Rights not promoted, vcpu paused, work here is done */
> +else
> +{
> +/*
> + * Rights not promoted (aka. sync event), work here is done
> + */
>  rc = 1;
>  goto out_put_gfn;
>  }
> @@ -1956,7 +1960,9 @@ out:
>  }
>  if ( req_ptr )
>  {
> -mem_access_send_req(currd, req_ptr);
> +if ( monitor_traps(curr, sync, req_ptr) < 0 )
> +rc = 0;
> +
>  xfree(req_ptr);
>  }
>  return rc;
> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
> index 7277c12..0f6ef96 100644
> --- a/xen/arch/x86/hvm/monitor.c
> +++ 

Re: [Xen-devel] [PATCH] libxc: zero-initialize structures in macros

[Tamas K Lengyel]

On Fri, Sep 2, 2016 at 11:18 AM, Andrew Cooper
 wrote:
> On 02/09/16 17:39, Tamas K Lengyel wrote:
>> While debugging applications built on top of libxc with Valgrind we get a lot
>> of complaining about relying on uninitialized values allocated in libxc.
>> While these warnings are safe to ignore, zero-initializing the structures
>> reduces Valgrind clutter a lot and aids in spotting real bugs.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Ian Jackson 
>> Cc: Wei Liu 
>> ---
>>  tools/libxc/xc_private.h | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
>> index 75b761c..4e9073b 100644
>> --- a/tools/libxc/xc_private.h
>> +++ b/tools/libxc/xc_private.h
>> @@ -59,11 +59,11 @@ struct iovec {
>>  #include 
>>  #endif
>>
>> -#define DECLARE_DOMCTL struct xen_domctl domctl
>> -#define DECLARE_SYSCTL struct xen_sysctl sysctl
>> -#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
>> -#define DECLARE_FLASK_OP struct xen_flask_op op
>> -#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
>> +#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
>> +#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
>> +#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
>> +#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
>> +#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}
>
> I specifically took those out in the past, because it hides real
> problems from Valgrind.
>
> Instead, I would recommend removing these wrappers entirely.  They serve
> no useful purpose.
>
> Taking a random example of xc_get_pfn_type_batch(), it would be rather
> more efficient to write
>
> ...
> DECLARE_HYPERCALL_BOUNCE(arr, sizeof(*arr) * num,
> XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
> struct xen_domctl domctl = {
> .cmd = XEN_DOMCTL_getpageframeinfo3,
> .domain = dom,
> .u.getpageframeinfo3.num = num,
> };
> ...
>
> as it permits the compiler more freedom in how xen_domctl gets
> constructed, as well as being able to plainly see exactly what is done
> to the memory.
>

Yea I don't really see much point using these macros as they are
either and the one you propose certainly would make more sense.

Tamas

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

Re: [Xen-devel] [PATCH] libxc: zero-initialize structures in macros

[Andrew Cooper]

On 02/09/16 17:39, Tamas K Lengyel wrote:
> While debugging applications built on top of libxc with Valgrind we get a lot
> of complaining about relying on uninitialized values allocated in libxc.
> While these warnings are safe to ignore, zero-initializing the structures
> reduces Valgrind clutter a lot and aids in spotting real bugs.
>
> Signed-off-by: Tamas K Lengyel 
> ---
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
>  tools/libxc/xc_private.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
> index 75b761c..4e9073b 100644
> --- a/tools/libxc/xc_private.h
> +++ b/tools/libxc/xc_private.h
> @@ -59,11 +59,11 @@ struct iovec {
>  #include 
>  #endif
>  
> -#define DECLARE_DOMCTL struct xen_domctl domctl
> -#define DECLARE_SYSCTL struct xen_sysctl sysctl
> -#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op
> -#define DECLARE_FLASK_OP struct xen_flask_op op
> -#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op
> +#define DECLARE_DOMCTL struct xen_domctl domctl = {0}
> +#define DECLARE_SYSCTL struct xen_sysctl sysctl = {0}
> +#define DECLARE_PHYSDEV_OP struct physdev_op physdev_op = {0}
> +#define DECLARE_FLASK_OP struct xen_flask_op op = {0}
> +#define DECLARE_PLATFORM_OP struct xen_platform_op platform_op = {0}

I specifically took those out in the past, because it hides real
problems from Valgrind.

Instead, I would recommend removing these wrappers entirely.  They serve
no useful purpose.

Taking a random example of xc_get_pfn_type_batch(), it would be rather
more efficient to write

...
DECLARE_HYPERCALL_BOUNCE(arr, sizeof(*arr) * num,
XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
struct xen_domctl domctl = {
.cmd = XEN_DOMCTL_getpageframeinfo3,
.domain = dom,
.u.getpageframeinfo3.num = num,
};
...

as it permits the compiler more freedom in how xen_domctl gets
constructed, as well as being able to plainly see exactly what is done
to the memory.

~Andrew

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0

Last test of basis   100732  2016-09-02 12:01:43 Z0 days
Testing same since   100733  2016-09-02 14:01:51 Z0 days2 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=158dd1bdca161a6456ee6be293969f87ecde3922
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
158dd1bdca161a6456ee6be293969f87ecde3922
+ branch=xen-unstable-smoke
+ revision=158dd1bdca161a6456ee6be293969f87ecde3922
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x158dd1bdca161a6456ee6be293969f87ecde3922 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
  

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Julien Grall]

On 02/09/2016 18:45, Andrew Cooper wrote:

On 02/09/16 18:37, Tamas K Lengyel wrote:

On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
 wrote:

On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:

Add support for getting/setting registers through vm_event on ARM. Only
TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
as part of a response. The set of registers can be expanded in the future to
include other registers as well if necessary.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Andrew Cooper 

Acked-by: Razvan Cojocaru 

Patch ping.


Requires an ARM ack.


I don't think it requires an ack from Stefano and I, it touches only the 
vm_event subsystem.


If you still want an ARM ack, then I will defer to Stefano.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Tamas K Lengyel]

On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
 wrote:
> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>> Add support for getting/setting registers through vm_event on ARM. Only
>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
>> as part of a response. The set of registers can be expanded in the future to
>> include other registers as well if necessary.
>>
>> Signed-off-by: Tamas K Lengyel 
>> Reviewed-by: Andrew Cooper 
>
> Acked-by: Razvan Cojocaru 

Patch ping.

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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to altp2m files.

[Lai, Paul C]

[PAUL] in-line

Ravi -- please comment on swap comment below.

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Friday, September 2, 2016 6:31 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH v2 Altp2m cleanup v3 2/3] Move altp2m specific functions to 
altp2m files.

>>> On 19.08.16 at 19:22,  wrote:
> @@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  vcpu_unpause(v);
>  }
>  
> +int
> +hvm_altp2m_init( struct domain *d)

Stray blank (more elsewhere). Also I don't think hvm_ is a proper prefix for a 
function placed in this file, i.e. if altp2m_init() is used elsewhere already, 
then altp2m_hvm_init() or perhaps better
altp2m_domain_init() please.

> +{
> +int rc = 0;
> +unsigned int i = 0;

Pointless initializers.

> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +{
> +rc = -ENOMEM;
> +goto out;
> +}

When the epilogue (after the target label) is just a return statement, please 
avoid using goto.

[PAUL] I don't see this code in an epilogue (after the target label).  

> +void
> +hvm_altp2m_teardown( struct domain *d) {
> +unsigned int i = 0;
> +d->arch.altp2m_active = 0;
> +
> +if ( d->arch.altp2m_eptp )
> +{
> +free_xenheap_page(d->arch.altp2m_eptp);
> +d->arch.altp2m_eptp = NULL;
> +}

Please avoid the if() - free_xenheap_page() happily deals with a NULL pointer 
passed to it.

> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +p2m_teardown(d->arch.altp2m_p2m[i]);

I realize it's been that way in the original code, but wouldn't swapping the 
two things be both more natural and more robust?

[PAUL] Ravi ?

> @@ -501,24 +502,9 @@ int hap_enable(struct domain *d, u32 mode)
>  
>  if ( hvm_altp2m_supported() )
>  {
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> -}
> -
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> -
> -d->arch.altp2m_active = 0;
> +rv = hvm_altp2m_init(d);
> +if ( rv != 0 )
> +   goto out;
>  }
>  
>  /* Now let other users see the new mode */ @@ -534,18 +520,7 @@ 
> void hap_final_teardown(struct domain *d)
>  unsigned int i;
>  
>  if ( hvm_altp2m_supported() )
> -{
> -d->arch.altp2m_active = 0;
> -
> -if ( d->arch.altp2m_eptp )
> -{
> -free_xenheap_page(d->arch.altp2m_eptp);
> -d->arch.altp2m_eptp = NULL;
> -}
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -p2m_teardown(d->arch.altp2m_p2m[i]);
> -}
> +hvm_altp2m_teardown(d);

I wonder whether in both cases the hvm_altp2m_supported() would better also be 
moved into the functions.

It looks like the parts above and below this point, except for header file 
adjustments, are completely independent. Please consider splitting into two 
patches.

> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
>  register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT 
> tables", 0);  }
>  
> +void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)

Please drop the _helper suffix now that there is _ept.

Jan


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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically allocated.

[Lai, Paul C]

[PAUL] in line

-Original Message-
From: Jan Beulich [mailto:jbeul...@suse.com] 
Sent: Friday, September 2, 2016 6:47 AM
To: Lai, Paul C 
Cc: george.dun...@citrix.com; Sahita, Ravi ; xen-devel 

Subject: Re: [PATCH v2 Altp2m cleanup v3 3/3] Making altp2m struct dynamically 
allocated.

>>> On 19.08.16 at 19:22,  wrote:
> Ravi Sahita's dynamically allocated altp2m structs

I think I've asked before: With this and ...

> Signed-off-by: Paul Lai 
> Reviewed-by: Ravi Sahita 

... this - who's the actual author?

[PAUL] Ravi is the actual author.  I thought the commit message would have been 
clear :(

> @@ -5279,11 +5279,11 @@ static int do_altp2m_op(
>  break;
>  }
>  
> -ostate = d->arch.altp2m_active;
> -d->arch.altp2m_active = !!a.u.domain_state.state;
> +ostate = altp2m_active(d);
> +set_altp2m_active(d, !!a.u.domain_state.state);

The !! shouldn't be needed anymore.

> --- a/xen/arch/x86/mm/altp2m.c
> +++ b/xen/arch/x86/mm/altp2m.c
> @@ -73,23 +73,23 @@ hvm_altp2m_init( struct domain *d)
>  unsigned int i = 0;
>  
>  /* Init alternate p2m data. */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +if ( (d->arch.altp2m->altp2m_eptp = alloc_xenheap_page()) == NULL 
> + )
>  {
>  rc = -ENOMEM;
>  goto out;
>  }
>  
>  for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +d->arch.altp2m->altp2m_eptp[i] = mfn_x(INVALID_MFN);
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +rc = p2m_alloc_table(d->arch.altp2m->altp2m_p2m[i]);
>  if ( rc != 0 )
> goto out;
>  }
>  
> -d->arch.altp2m_active = 0;
> +set_altp2m_active(d, 0);

"false" please (also elsewhere).

> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -193,12 +193,15 @@ static void p2m_teardown_altp2m(struct domain 
> *d)
>  
>  for ( i = 0; i < MAX_ALTP2M; i++ )
>  {
> -if ( !d->arch.altp2m_p2m[i] )
> +if ( !d->arch.altp2m->altp2m_p2m[i] )
>  continue;
> -p2m = d->arch.altp2m_p2m[i];
> +p2m = d->arch.altp2m->altp2m_p2m[i];
>  p2m_free_one(p2m);
> -d->arch.altp2m_p2m[i] = NULL;
> +d->arch.altp2m->altp2m_p2m[i] = NULL;
>  }
> +
> +if ( d->arch.altp2m )
> +xfree(d->arch.altp2m);

Two problems here: First, xfree() happily deals with NULL being passed. But 
then, such a NULL check clearly should not come _after_ the pointer did already 
get dereferenced. I.e. first of all you need to clarify for yourself whether 
the function can be called with the pointer being NULL.

[PAUL] great catch

> @@ -206,10 +209,14 @@ static int p2m_init_altp2m(struct domain *d)

And then, considering this is the last patch in the series - how come these two 
functions are still in this source file?

> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -338,6 +338,13 @@ struct p2m_domain {
>  };
>  };
>  
> +struct altp2m_domain {
> +bool_t altp2m_active;
> +struct p2m_domain *altp2m_p2m[MAX_ALTP2M];
> +mm_lock_t altp2m_list_lock;
> +uint64_t *altp2m_eptp;
> +};

None of the altp2m_ prefixes here are really useful for anything afaics.

Jan


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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Andrew Cooper]

On 02/09/16 18:37, Tamas K Lengyel wrote:
> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>  wrote:
>> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>>> Add support for getting/setting registers through vm_event on ARM. Only
>>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is set
>>> as part of a response. The set of registers can be expanded in the future to
>>> include other registers as well if necessary.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Andrew Cooper 
>> Acked-by: Razvan Cojocaru 
> Patch ping.

Requires an ARM ack.

~Andrew

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

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Julien Grall]

On 02/09/2016 19:47, Tamas K Lengyel wrote:

On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall  wrote:

On 02/09/2016 18:45, Andrew Cooper wrote:


On 02/09/16 18:37, Tamas K Lengyel wrote:


On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
 wrote:


On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:


Add support for getting/setting registers through vm_event on ARM. Only
TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC is
set
as part of a response. The set of registers can be expanded in the
future to
include other registers as well if necessary.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Andrew Cooper 


Acked-by: Razvan Cojocaru 


Patch ping.



Requires an ARM ack.



I don't think it requires an ack from Stefano and I, it touches only the
vm_event subsystem.

If you still want an ARM ack, then I will defer to Stefano.


Indeed it only touches the vm_event system so just wanted to double
check it's OK from your side as we had lengthy discussion about it. If
there are no objections a formal ack should not be necessary and it's
good to go.


My objections are still there. Hence why I said I will defer to Stefano.

Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable baseline-only test] 67628: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67628 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67628/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 67617
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 67617
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 67617
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 67617
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 67617
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 67617
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 67617
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 67617
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 67617
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 67617
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 67617
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
67617
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 67617
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 67617
 test-amd64-i386-migrupgrade  10 xen-boot/dst_host fail REGR. vs. 67617
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 67617
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 67617

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 67617
 build-i386-rumpuserxen6 xen-buildfail   like 67617
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67617
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67617
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67617
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67617
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67617
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67617

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 

[Xen-devel] [xen-unstable test] 100734: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100712
 build-i386-rumpuserxen6 xen-buildfail  like 100712
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100712
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100712
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100712
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100712
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100712
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100712

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

version targeted for testing:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0
baseline version:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca

Last test of basis   100712  2016-09-02 02:49:03 Z0 days
Testing same since   100734  2016-09-02 14:15:24 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Tim Deegan 
  Wei Liu 

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 

Re: [Xen-devel] [PATCH v2] arm/vm_event: get/set registers

[Tamas K Lengyel]

On Fri, Sep 2, 2016 at 1:10 PM, Julien Grall  wrote:
>
>
> On 02/09/2016 19:47, Tamas K Lengyel wrote:
>>
>> On Fri, Sep 2, 2016 at 12:40 PM, Julien Grall 
>> wrote:
>>>
>>> On 02/09/2016 18:45, Andrew Cooper wrote:


 On 02/09/16 18:37, Tamas K Lengyel wrote:
>
>
> On Tue, Aug 2, 2016 at 2:10 AM, Razvan Cojocaru
>  wrote:
>>
>>
>> On 08/01/2016 08:59 PM, Tamas K Lengyel wrote:
>>>
>>>
>>> Add support for getting/setting registers through vm_event on ARM.
>>> Only
>>> TTB/CR/R0/R1, PC and CPSR are sent as part of a request and only PC
>>> is
>>> set
>>> as part of a response. The set of registers can be expanded in the
>>> future to
>>> include other registers as well if necessary.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Andrew Cooper 
>>
>>
>> Acked-by: Razvan Cojocaru 
>
>
> Patch ping.



 Requires an ARM ack.
>>>
>>>
>>>
>>> I don't think it requires an ack from Stefano and I, it touches only the
>>> vm_event subsystem.
>>>
>>> If you still want an ARM ack, then I will defer to Stefano.
>>
>>
>> Indeed it only touches the vm_event system so just wanted to double
>> check it's OK from your side as we had lengthy discussion about it. If
>> there are no objections a formal ack should not be necessary and it's
>> good to go.
>
>
> My objections are still there. Hence why I said I will defer to Stefano.

Fair enough.

Thanks,
Tamas

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
baseline version:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89

Last test of basis   100721  2016-09-02 10:46:07 Z0 days
Testing same since   100737  2016-09-02 19:44:57 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
+ branch=ovmf
+ revision=0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  9 debian-install   fail REGR. vs. 100669

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100669
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100669
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100669

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

version targeted for testing:
 qemuu1dc33ed90bf1fe1c2014dffa0d9e863c520d953a
baseline version:
 qemuu12d2c4184c5ab60be3428b2bdea5ae66e8d5d960

Last test of basis   100669  2016-08-31 00:23:42 Z2 days
Testing same since   100735  2016-09-02 15:14:36 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

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-debianhvm-amd64-xsmpass
 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
baseline version:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89

Last test of basis67627  2016-09-02 13:16:23 Z0 days
Testing same since67630  2016-09-02 21:47:42 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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


Push not applicable.


commit 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3
Author: Ard Biesheuvel 
Date:   Wed Aug 31 10:07:33 2016 +0100

ArmPkg/BaseMemoryLibStm: implement new IsZeroBuffer() API function

BaseMemoryLib has recently been extended with an API function
IsZeroBuffer(), so copy the default implementation into BaseMemoryLibStm
as well.

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

commit a548a5421f98f0890e3ab9703a5209d3ef8a9183
Author: Ard Biesheuvel 
Date:   Wed Aug 31 10:07:32 2016 +0100

ArmPkg/BaseMemoryLibStm: implement new IsZeroGuid() API function

BaseMemoryLib has recently been extended with an API function
IsZeroGuid(), so copy the default implementation into BaseMemoryLibStm
as well.

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

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89
baseline version:
 ovmf 4a2aaff2fca69d9f41c5b8906699ba242278cbaa

Last test of basis67626  2016-09-02 10:46:31 Z0 days
Testing same since67627  2016-09-02 13:16:23 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 

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



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

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

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


Push not applicable.


commit 8953d69a5ca7f18f80f46e67da95c2527ca6ee89
Author: Liming Gao 
Date:   Thu Sep 1 13:41:20 2016 +0800

MdeModulePkg UefiBootManagerLib: Ignore BootManagerMenu from LoadFile

BootManagerMenu boot option is handled by EfiBootManagerGetBootManagerMenu.
Don't need to handle it again when parse LoadFile protocol.

In V2, use "BootManagerMenu" instead of "BootMenuApp".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Sunny Wang 

commit 7c69fbf20d409516c80355de9a40656ec55f5e21
Author: Liming Gao 
Date:   Thu Sep 1 13:30:13 2016 +0800

MdeModulePkg UefiBootManagerLib: Rename BootMenuApp to BootManagerMenu

Rename local function name BootMenuApp to BootManagerMenu to align to
other public function name.

In V2, use "BootManagerMenu" instead of "BootMenuApp".

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Sunny Wang 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   9 debian-install   fail REGR. vs. 100734

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail  like 100734
 build-i386-rumpuserxen6 xen-buildfail  like 100734
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100734
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100734
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 100734
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100734
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 100734
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100734

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

version targeted for testing:
 xen  158dd1bdca161a6456ee6be293969f87ecde3922
baseline version:
 xen  f59174d7e5fb8bb530246003d373345b5b433ea0

Last test of basis   100734  2016-09-02 14:15:24 Z0 days
Testing same since   100738  2016-09-02 21:44:47 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Razvan Cojocaru 
  Wei Liu 

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   

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 72092534a9283291edd6b497c9aa934049c4b928
baseline version:
 ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce

Last test of basis   100739  2016-09-02 22:14:43 Z0 days
Testing same since   100743  2016-09-03 03:47:36 Z0 days1 attempts


People who touched revisions under test:
  Giri P Mudusuru 
  Mudusuru, Giri P 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=72092534a9283291edd6b497c9aa934049c4b928
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
72092534a9283291edd6b497c9aa934049c4b928
+ branch=ovmf
+ revision=72092534a9283291edd6b497c9aa934049c4b928
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x72092534a9283291edd6b497c9aa934049c4b928 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce
baseline version:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3

Last test of basis67630  2016-09-02 21:47:42 Z0 days
Testing same since67631  2016-09-03 03:48:54 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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


Push not applicable.


commit 646a9e5b799b009426fe37af7ac8528a98cc96ce
Author: Ard Biesheuvel 
Date:   Wed Aug 31 16:35:57 2016 +0100

ArmVirtPkg: remove now unused PciHostBridgeDxe

This code is now no longer used, so remove it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit 9d64ac2369673607a8d5d1339e05d45723efc496
Author: Ard Biesheuvel 
Date:   Sun Aug 21 18:51:04 2016 +0200

ArmVirtPkg/FdtPciHostBridgeLib: add MMIO64 support

If the pci-host-ecam-generic DT node describes a 64-bit MMIO region,
account for it in the PCI_ROOT_BRIDGE description that we return to
the generic PciHostBridgeDxe implementation, which will be able to
allocate BARs from it without any further changes.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit 53ee81bb686c18789fb1f58b062f40c69f19dec1
Author: Ard Biesheuvel 
Date:   Sun Aug 21 18:53:34 2016 +0200

ArmVirtPkg/ArmVirtQemu: switch to generic PciHostBridgeDxe

Wire up the FdtPciHostBridgeLib introduced in the previous patch
to the generic PciHostBridgeDxe implementation, and drop the special
ArmVirtPkg version. The former's dependency on gEfiCpuIo2ProtocolGuid
is satisfied by adding ArmPciCpuIo2Dxe.inf as well, and adding the PCD
gArmTokenSpaceGuid.PcdPciIoTranslation as a dynamic PCD.

In terms of functionality, no changes are intended.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit d4cb9a30494ddf003497fae3aaf37dae137f6b45
Author: Ard Biesheuvel 
Date:   Sun Aug 21 17:34:19 2016 +0200

ArmVirtPkg: implement FdtPciHostBridgeLib

Implement PciHostBridgeLib for DT platforms that expose a PCI root bridge
via a pci-host-ecam-generic DT node. The DT parsing logic is copied from
the PciHostBridgeDxe implementation in ArmVirtPkg, with the one notable
difference that we don't set some of the legacy PCI attributes for IDE
and VGA I/O ranges.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=65

commit c8f1a75aa997b3614b0ab751399690a4a0bfc18e
Author: Ard Biesheuvel 
Date:   Wed Aug 24 19:03:00 2016 +0200

ArmVirtPkg/FdtPciPcdProducerLib: add handling of PcdPciIoTranslation

Add handling of the PcdPciIoTranslation PCD, so that modules that include
this library via NULL resolution are guaranteed that it 

Re: [Xen-devel] [PATCH 2/3] mini-os: add testbuild target to Makefile

[Samuel Thibault]

Juergen Gross, on Fri 02 Sep 2016 10:56:46 +0200, wrote:
> Add a "testbuild" target to the Makefile to test building a set of
> pre-defined configurations.
> 
> Configurations tested are stored under arch//testbuild in form
> of configuration files. All configurations found there are built in
> a local directory.

Please also document just above the CONFIG_* lines in Config.mk that new
CONFIG options should be set in all-* testbuilds.

> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

Samuel

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

Re: [Xen-devel] [PATCH 1/3] mini-os: fix builds with uncommon config settings

[Samuel Thibault]

Juergen Gross, on Fri 02 Sep 2016 10:56:45 +0200, wrote:
> Some config settings won't build standalone. Fix the following cases:
> 
> - all CONFIG_* set to "n"
> - standard config with latest Xen interface version
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Samuel Thibault 

> ---
>  include/x86/os.h | 5 +
>  include/xenbus.h | 6 --
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/include/x86/os.h b/include/x86/os.h
> index 90ab6e6..0f5dd6c 100644
> --- a/include/x86/os.h
> +++ b/include/x86/os.h
> @@ -514,6 +514,11 @@ static __inline__ unsigned long __ffs(unsigned long word)
>  #endif /* ifdef __INSIDE_MINIOS */
>  
>  /* common i386 and x86_64  /
> +#define xen_mb()  mb()
> +#define xen_rmb() rmb()
> +#define xen_wmb() wmb()
> +#define xen_barrier() asm volatile ( "" : : : "memory")
> +
>  #define wrmsr(msr,val1,val2) \
>__asm__ __volatile__("wrmsr" \
> : /* no outputs */ \
> diff --git a/include/xenbus.h b/include/xenbus.h
> index c254652..12391b9 100644
> --- a/include/xenbus.h
> +++ b/include/xenbus.h
> @@ -7,10 +7,14 @@ typedef unsigned long xenbus_transaction_t;
>  #define XBT_NIL ((xenbus_transaction_t)0)
>  
>  #ifdef CONFIG_XENBUS
> +extern uint32_t xenbus_evtchn;
> +
>  /* Initialize the XenBus system. */
>  void init_xenbus(void);
>  void get_xenbus(void *p);
>  #else
> +#define xenbus_evtchn ~0
> +
>  static inline void init_xenbus(void)
>  {
>  }
> @@ -33,8 +37,6 @@ struct xenbus_event {
>  };
>  typedef struct xenbus_event *xenbus_event_queue;
>  
> -extern uint32_t xenbus_evtchn;
> -
>  char *xenbus_watch_path_token(xenbus_transaction_t xbt, const char *path, 
> const char *token, xenbus_event_queue *events);
>  char *xenbus_unwatch_path_token(xenbus_transaction_t xbt, const char *path, 
> const char *token);
>  extern struct wait_queue_head xenbus_watch_queue;
> -- 
> 2.6.6
> 

-- 
Samuel
(03:13:14)  bon
(03:13:19)  il est tard :p
(03:13:25)  c'est l'heure de manger
(03:13:38)  hm j'ai mangé à 1h moi, j'ai des horaires raisonnables

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 646a9e5b799b009426fe37af7ac8528a98cc96ce
baseline version:
 ovmf 0b09c212a8aecf18bab2377b0c4cf43aef0f8ed3

Last test of basis   100737  2016-09-02 19:44:57 Z0 days
Testing same since   100739  2016-09-02 22:14:43 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=646a9e5b799b009426fe37af7ac8528a98cc96ce
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
646a9e5b799b009426fe37af7ac8528a98cc96ce
+ branch=ovmf
+ revision=646a9e5b799b009426fe37af7ac8528a98cc96ce
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x646a9e5b799b009426fe37af7ac8528a98cc96ce = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

[Jan Beulich]

>>> On 02.09.16 at 14:13,  wrote:
> On 02/09/16 13:06, Jan Beulich wrote:
> On 02.09.16 at 14:01,  wrote:
>>> On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
>>> On 02.09.16 at 13:47,  wrote:
 Since this is a config option - why bother issuing a warning and
 tainting the hypervisor?

>>> Because there isn't a clear indicator if gcov is enabled.
>>>
>>> I think it would be valuable to just tell from the backtrace or console
>>> log that gcov is enabled, then we can legitimately refuse to provide
>>> (security) support for such builds.
>> Then perhaps making it match the "debug=" would be the better
>> approach for a feature not controlled on the command line?
> 
> I would prefer not to make it depend on debug=
> 
> Coverage on a release hypervisor is equally important, and will be
> different from a debug hypervisor.

I didn't say "depend on", but "match" (which I mean just logging wise).

> I am on the fence as to whether a taint is right to use, but I do think
> that a "with GCOV" is needed somewhere obvious on the banner line.

Right, hence the matching goal with "debug=".

Jan


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

[Xen-devel] [PATCH v2] xen/pciback: support driver_override

[Juergen Gross]

Support the driver_override scheme introduced with commit 782a985d7af2
("PCI: Introduce new device binding path using pci_dev.driver_override")

As pcistub_probe() is called for all devices (it has to check for a
match based on the slot address rather than device type) it has to
check for driver_override set to "pciback" itself.

Signed-off-by: Juergen Gross 
---
V2: removed now unused label
---
 drivers/xen/xen-pciback/pci_stub.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/xen/xen-pciback/pci_stub.c 
b/drivers/xen/xen-pciback/pci_stub.c
index 258b7c3..85c28f7 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -25,6 +25,8 @@
 #include "conf_space.h"
 #include "conf_space_quirks.h"
 
+#define PCISTUB_DRIVER_NAME "pciback"
+
 static char *pci_devs_to_hide;
 wait_queue_head_t xen_pcibk_aer_wait_queue;
 /*Add sem for sync AER handling and xen_pcibk remove/reconfigue ops,
@@ -529,16 +531,18 @@ static int pcistub_probe(struct pci_dev *dev, const 
struct pci_device_id *id)
"don't have a normal (0) or bridge (1) "
"header type!\n");
err = -ENODEV;
-   goto out;
}
 
+   } else if (!dev->driver_override ||
+  strcmp(dev->driver_override, PCISTUB_DRIVER_NAME))
+   /* Didn't find the device */
+   err = -ENODEV;
+
+   if (!err) {
dev_info(>dev, "seizing device\n");
err = pcistub_seize(dev);
-   } else
-   /* Didn't find the device */
-   err = -ENODEV;
+   }
 
-out:
return err;
 }
 
@@ -945,7 +949,7 @@ static const struct pci_error_handlers 
xen_pcibk_error_handler = {
 static struct pci_driver xen_pcibk_pci_driver = {
/* The name should be xen_pciback, but until the tools are updated
 * we will keep it as pciback. */
-   .name = "pciback",
+   .name = PCISTUB_DRIVER_NAME,
.id_table = pcistub_ids,
.probe = pcistub_probe,
.remove = pcistub_remove,
-- 
2.6.6


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

Re: [Xen-devel] [PATCH 1/5] xen: add tainted state and show warning is gcov is enabled

[Andrew Cooper]

On 02/09/16 13:26, Jan Beulich wrote:
 On 02.09.16 at 14:13,  wrote:
>> On 02/09/16 13:06, Jan Beulich wrote:
>> On 02.09.16 at 14:01,  wrote:
 On Fri, Sep 02, 2016 at 05:56:49AM -0600, Jan Beulich wrote:
 On 02.09.16 at 13:47,  wrote:
> Since this is a config option - why bother issuing a warning and
> tainting the hypervisor?
>
 Because there isn't a clear indicator if gcov is enabled.

 I think it would be valuable to just tell from the backtrace or console
 log that gcov is enabled, then we can legitimately refuse to provide
 (security) support for such builds.
>>> Then perhaps making it match the "debug=" would be the better
>>> approach for a feature not controlled on the command line?
>> I would prefer not to make it depend on debug=
>>
>> Coverage on a release hypervisor is equally important, and will be
>> different from a debug hypervisor.
> I didn't say "depend on", but "match" (which I mean just logging wise).
>
>> I am on the fence as to whether a taint is right to use, but I do think
>> that a "with GCOV" is needed somewhere obvious on the banner line.
> Right, hence the matching goal with "debug=".

Ah - I see what you mean.  Yes - that would be fine by me.

~Andrew

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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Jan Beulich]

>>> On 02.09.16 at 14:21,  wrote:
> On 09/02/2016 01:02 PM, Jan Beulich wrote:
>>> +/*
>>> > + * Corresponding list of access settings for pfn_list
>>> > + * Used only with XENMEM_access_op_set_access_multi
>>> > + */
>>> > +XEN_GUEST_HANDLE(uint8) access_list;
>> And for both of them - I don't think the arrays are meant to be
>> used for output? In which case they should be handles of const
>> types.
> 
> Actually I can't seem to be able to find a magic combination that works.
> 
> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
> 
> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
> name a type
>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
> 
> which is fair. I've tried:
> 
> XEN_GUEST_HANDLE(const_uint8) access_list;
> 
> which does go further with the compilation process, but still kills it with:
> 
> xen/include/compat/memory.h:154:5: error: unknown type name
> '__compat_handle_const_uint8'
>  COMPAT_HANDLE(const_uint8) access_list;
> 
> What would be the appropriate const type to use here?

This one. Did you check that handle actually gets created? Per
my brief checking it doesn't look so. And neither the native one.

Jan


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

Re: [Xen-devel] fail to register IRQ for virtualization exception

[Big Strong]

Or should I modify the linux kernel to add support for handling #VE
exception?

2016-09-02 16:35 GMT+08:00 Big Strong :

> Sorry for that. Could you give any suggestions on how to register the IRQ
> handler for #VE?
>
> 2016-09-02 15:52 GMT+08:00 Jan Beulich :
>
>> >>> On 02.09.16 at 04:59,  wrote:
>> > I'm recently trying to utilize the virtualization exception (#VE)
>> feature.
>> > As the document says, #VE is handled by guest interrupt handler. The IRQ
>> > number of #VE is 20. However, when I tried to register an IRQ handler
>> for
>> > #VE, it returns errno -22, which means invalid arguments.
>> >
>> > request_irq(20, ve_handler, IRQF_NO_SUSPEND, "ve", NULL)
>> >
>> > Is there anything wrong?
>>
>> You're mixing up exception vectors and IRQ numbers.
>>
>> Jan
>>
>>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/02/2016 03:33 PM, Jan Beulich wrote:
 On 02.09.16 at 14:21,  wrote:
>> On 09/02/2016 01:02 PM, Jan Beulich wrote:
 +/*
> + * Corresponding list of access settings for pfn_list
> + * Used only with XENMEM_access_op_set_access_multi
> + */
> +XEN_GUEST_HANDLE(uint8) access_list;
>>> And for both of them - I don't think the arrays are meant to be
>>> used for output? In which case they should be handles of const
>>> types.
>>
>> Actually I can't seem to be able to find a magic combination that works.
>>
>> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>>
>> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
>> name a type
>>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>>
>> which is fair. I've tried:
>>
>> XEN_GUEST_HANDLE(const_uint8) access_list;
>>
>> which does go further with the compilation process, but still kills it with:
>>
>> xen/include/compat/memory.h:154:5: error: unknown type name
>> '__compat_handle_const_uint8'
>>  COMPAT_HANDLE(const_uint8) access_list;
>>
>> What would be the appropriate const type to use here?
> 
> This one. Did you check that handle actually gets created? Per
> my brief checking it doesn't look so. And neither the native one.

Running ./configure again, followed by 'make clean' and a new 'make
dist' didn't help, so if it's supposed to be generated automatically it
doesn't seem to be (or I'm doing something wrong). I'll investigate more.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

[anshul makkar]

On 17/08/16 18:20, Dario Faggioli wrote:

By not looking at the same cpu (to check whether
we want to preempt who's running there) twice, if
the vcpu being woken up has both soft and hard
affinity.

In fact, all the cpus that are part of both soft
affinity and hard-affinity (of the waking vcpu)
are checked during the soft-affinity balancing
step. If none turns out to be suitable, e.g.,
because they're running vcpus with higher credits,
there's no point in re-checking them, only to
re-assess the same, during the hard-affinity
step.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
  xen/common/sched_credit2.c |   43 +++
  1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 6963872..f03ecce 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -997,7 +997,7 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  s_time_t lowest = (1<<30);
  unsigned int bs, cpu = new->vcpu->processor;
  struct csched2_runqueue_data *rqd = RQD(ops, cpu);
-cpumask_t mask;
+cpumask_t mask, skip_mask;
  struct csched2_vcpu * cur;

  ASSERT(new->rqd == rqd);
@@ -1017,6 +1017,13 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  (unsigned char *));
  }

+/*
+ * Cpus that end up in this mask, have been already checked during the
+ * soft-affinity step, and need not to be checked again when doing hard
+ * affinity.
+ */
+cpumask_clear(_mask);
+
  for_each_affinity_balance_step( bs )
  {
  /*
@@ -1073,7 +1080,8 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  cpumask_andnot(, >active, >idle);
  cpumask_andnot(, , >tickled);
  cpumask_and(, , cpumask_scratch);
-if ( cpumask_test_cpu(cpu, ) )
+if ( cpumask_test_cpu(cpu, ) &&
+ !cpumask_test_cpu(cpu, _mask) )
  {
  cur = CSCHED2_VCPU(curr_on_cpu(cpu));

@@ -1102,13 +1110,26 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  ipid = cpu;
  goto tickle;
  }
+
+/*
+ * If we're here, cpu is just not a valid candidate for being
+ * tickled. Set its bit in skip_mask, to avoid calling
+ * burn_credits() and check its current vcpu for preemption
+ * twice.
+ */
+__cpumask_set_cpu(cpu, _mask);
  }
  }

  for_each_cpu(i, )
  {
-/* Already looked at this one above */
-if ( i == cpu )
+/*
+ * Already looked at these ones above, either because it's the
+ * cpu where new was running before, or because we are at the
+ * hard-affinity step, and we checked this during the
+ * soft-affinity one
+ */
Sorry for my naiveness here, but can we be sure that situation has not 
changed since we checked during soft-affinity step. ?

+if ( i == cpu || cpumask_test_cpu(i, _mask) )
  continue;

  cur = CSCHED2_VCPU(curr_on_cpu(i));
@@ -1139,6 +1160,20 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
  ipid = i;
  lowest = cur->credit;
  }
+
+/*
+ * No matter if i is the new lowest or not. We've run
+ * burn_credits() on it, and we've checked it for preemption.
+ *
+ * If we are at soft-affinity balancing step, and i is indeed
+ * the lowest, it will be tickled (and we exit the function).
+ * If it is not the lowest among the cpus in the soft-affinity
+ * mask, it can't be the lowest among the cpus in the hard
+ * affinity mask (assuming we'll actually do the second
+ * balancing step), as hard-affinity is a superset of soft
+ * affinity, and therefore we can flag it to be skipped.
+ */
+__cpumask_set_cpu(i, _mask);
  }
  }





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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4a2aaff2fca69d9f41c5b8906699ba242278cbaa
baseline version:
 ovmf b8922094f6f8b5293f01a09035b74463fff12320

Last test of basis67624  2016-09-02 05:18:08 Z0 days
Testing same since67626  2016-09-02 10:46:31 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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


Push not applicable.


commit 4a2aaff2fca69d9f41c5b8906699ba242278cbaa
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:36:42 2016 +0200

MdeModulePkg/EbcDxe AARCH64: simplify interpreter entry point thunks

The prototypes of EbcInterpret() and ExecuteEbcImageEntryPoint() are
private to the AARCH64 implementation of EbcDxe, so we can shuffle
the arguments around a bit and make the assembler thunking glue a lot
simpler.

For ExecuteEbcImageEntryPoint(), this involves passing the EntryPoint
argument as the third parameter, rather than the first, which allows
us to do a tail call. For EbcInterpret(), instead of copying each
argument beyond #8 from one native stack frame to the next (before
another copy is made into the VM stack), pass a pointer to the
argument stack.

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

commit 3226e315d20c6f572de818d6d1229a88b5b6e7b3
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:29:09 2016 +0200

MdeModulePkg/EbcDxe AARCH64: use tail call for EBC to native thunk

Instead of pessimistically copying at least 64 bytes from the VM stack
to the native stack, and popping off the register arguments again
before doing the native call, try to avoid touching the stack completely
if the VM stack frame is <= 64 bytes. Also, if the stack frame does exceed
64 bytes, there is no need to copy the first 64 bytes, since we are passing
those in registers anyway.

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

commit 4d1f5a214bb3c7904c26f2634294dee2a18be5d3
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:24:52 2016 +0200

MdeModulePkg/EbcDxe AARCH64: use a fixed size thunk structure

The thunk generation is needlessly complex, given that it attempts to
deal with variable length instructions, which don't exist on AArch64.

So replace it with a simple template coded in assembler, with a matching
struct definition in C. That way, we can create and manipulate the thunks
easily without looping over the instructions looking for 'magic' numbers.

Also, use x16 rather than x9, since it is the architectural register to
use for thunks/veneers.

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

commit 72b0eaa02679de8a0f0984a4d41ed1386262f3f3
Author: Ard Biesheuvel 
Date:   Wed Aug 17 16:08:21 2016 +0200

MdeModulePkg/EbcDxe AARCH64: clean up comment style in ASM file

Change to consistent // style comments. Also, remove bogus global
definitions for external 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 8953d69a5ca7f18f80f46e67da95c2527ca6ee89
baseline version:
 ovmf 4a2aaff2fca69d9f41c5b8906699ba242278cbaa

Last test of basis   100719  2016-09-02 07:17:48 Z0 days
Testing same since   100721  2016-09-02 10:46:07 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=8953d69a5ca7f18f80f46e67da95c2527ca6ee89
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
8953d69a5ca7f18f80f46e67da95c2527ca6ee89
+ branch=ovmf
+ revision=8953d69a5ca7f18f80f46e67da95c2527ca6ee89
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x8953d69a5ca7f18f80f46e67da95c2527ca6ee89 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Jan Beulich]

>>> On 02.09.16 at 14:41,  wrote:
> On 09/02/2016 03:33 PM, Jan Beulich wrote:
> On 02.09.16 at 14:21,  wrote:
>>> On 09/02/2016 01:02 PM, Jan Beulich wrote:
> +/*
>> + * Corresponding list of access settings for pfn_list
>> + * Used only with XENMEM_access_op_set_access_multi
>> + */
>> +XEN_GUEST_HANDLE(uint8) access_list;
 And for both of them - I don't think the arrays are meant to be
 used for output? In which case they should be handles of const
 types.
>>>
>>> Actually I can't seem to be able to find a magic combination that works.
>>>
>>> XEN_GUEST_HANDLE(const uint8) access_list; tells me:
>>>
>>> ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
>>> name a type
>>>  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>>>
>>> which is fair. I've tried:
>>>
>>> XEN_GUEST_HANDLE(const_uint8) access_list;
>>>
>>> which does go further with the compilation process, but still kills it with:
>>>
>>> xen/include/compat/memory.h:154:5: error: unknown type name
>>> '__compat_handle_const_uint8'
>>>  COMPAT_HANDLE(const_uint8) access_list;
>>>
>>> What would be the appropriate const type to use here?
>> 
>> This one. Did you check that handle actually gets created? Per
>> my brief checking it doesn't look so. And neither the native one.
> 
> Running ./configure again, followed by 'make clean' and a new 'make
> dist' didn't help, so if it's supposed to be generated automatically it
> doesn't seem to be (or I'm doing something wrong). I'll investigate more.

The compat one is supposed to get auto-generated once the native
one is there.

Jan


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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/02/2016 03:56 PM, Jan Beulich wrote:
 On 02.09.16 at 14:41,  wrote:
>> On 09/02/2016 03:33 PM, Jan Beulich wrote:
>> On 02.09.16 at 14:21,  wrote:
 On 09/02/2016 01:02 PM, Jan Beulich wrote:
>> +/*
>>> + * Corresponding list of access settings for pfn_list
>>> + * Used only with XENMEM_access_op_set_access_multi
>>> + */
>>> +XEN_GUEST_HANDLE(uint8) access_list;
> And for both of them - I don't think the arrays are meant to be
> used for output? In which case they should be handles of const
> types.

 Actually I can't seem to be able to find a magic combination that works.

 XEN_GUEST_HANDLE(const uint8) access_list; tells me:

 ./public/arch-x86/xen.h:53:41: error: '__guest_handle_const' does not
 name a type
  #define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name

 which is fair. I've tried:

 XEN_GUEST_HANDLE(const_uint8) access_list;

 which does go further with the compilation process, but still kills it 
 with:

 xen/include/compat/memory.h:154:5: error: unknown type name
 '__compat_handle_const_uint8'
  COMPAT_HANDLE(const_uint8) access_list;

 What would be the appropriate const type to use here?
>>>
>>> This one. Did you check that handle actually gets created? Per
>>> my brief checking it doesn't look so. And neither the native one.
>>
>> Running ./configure again, followed by 'make clean' and a new 'make
>> dist' didn't help, so if it's supposed to be generated automatically it
>> doesn't seem to be (or I'm doing something wrong). I'll investigate more.
> 
> The compat one is supposed to get auto-generated once the native
> one is there.

Changing both handles to XEN_GUEST_HANLDE(const_void) compiles cleanly.
As soon as I change to either XEN_GUEST_HANLDE(const_uint8) or
XEN_GUEST_HANLDE(const_uint64) I start getting errors.

Previously the auto-generation seems to have worked fine, so this is
likely something more subtle.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 Altp2m cleanup v3 1/3] altp2m cleanup work

[Jan Beulich]

>>> On 19.08.16 at 19:22,  wrote:
> @@ -5213,12 +5213,25 @@ static int do_altp2m_op(
>  return -EFAULT;
>  
>  if ( a.pad1 || a.pad2 ||
> - (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
> - (a.cmd < HVMOP_altp2m_get_domain_state) ||
> - (a.cmd > HVMOP_altp2m_change_gfn) )
> +(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
>  return -EINVAL;
>  
> -d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
> +switch( a.cmd )

Missing blank.

> +{
> +case HVMOP_altp2m_get_domain_state:
> +case HVMOP_altp2m_set_domain_state:
> +case HVMOP_altp2m_vcpu_enable_notify:
> +case HVMOP_altp2m_create_p2m:
> +case HVMOP_altp2m_destroy_p2m:
> +case HVMOP_altp2m_switch_p2m:
> +case HVMOP_altp2m_set_mem_access:
> +case HVMOP_altp2m_change_gfn:
> +break;
> +default:
> +return -ENOSYS;
> +}
> +
> +d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
>  rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
>  
>  if ( d == NULL )
> @@ -5335,6 +5348,8 @@ static int do_altp2m_op(
>  rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
>  _gfn(a.u.change_gfn.old_gfn),
>  _gfn(a.u.change_gfn.new_gfn));
> +default:
> +return -EINVAL;
>  }

Together with the earlier switch() this is dead code. So if anything,
ASSERT_UNREACHABLE() please.

>  /* emulates #VE */
> -bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
> +static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
> +{
> +if ( hvm_funcs.altp2m_vcpu_emulate_ve )
> +return hvm_funcs.altp2m_vcpu_emulate_ve(v);
> +return 0;
> +}

Since you already touch this, plain "bool" and "false" please.

Jan


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

Re: [Xen-devel] [PATCH 2/2] xen/trace: Turn the stub debugtrace_{dump, printk}() macros into functions

[Jan Beulich]

>>> On 01.09.16 at 21:21,  wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -68,8 +68,10 @@ extern void debugtrace_dump(void);
>  extern void debugtrace_printk(const char *fmt, ...)
>  __attribute__ ((format (printf, 1, 2)));
>  #else
> -#define debugtrace_dump()  ((void)0)
> -#define debugtrace_printk(_f, ...) ((void)0)
> +static inline void debugtrace_dump(void) {};
> +static inline void
> + __attribute__ ((format (printf, 1, 2)))
> +debugtrace_printk(const char *fmt, ...) {};
>  #endif

With the stray semicolons dropped, and provided this (at least a
little surprisingly) doesn't cause any other fallout with
DEBUG_TRACE_DUMP defined,
Acked-by: Jan Beulich 

Jan




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

[Xen-devel] [qemu-upstream-4.7-testing test] 100711: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale 15 guest-start/debian.repeat fail in 100708 pass 
in 100711
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 100708 pass in 
100711
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 100708

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

version targeted for testing:
 qemuue927b5f5a809f07b73b063831527c8a87f053933
baseline version:
 qemuu44a072f0de0d57c95c2212bbce0232b7b74f

Last test of basis   100704  2016-09-01 16:43:31 Z0 days
Testing same since   100708  2016-09-01 21:16:11 Z0 days2 attempts


People who touched revisions under test:
  P J P 
  Stefan Hajnoczi 
  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   

[Xen-devel] [PATCH v5] xen/sm{e, a}p: allow disabling sm{e, a}p for Xen itself

[He Chen]

SMEP/SMAP is a security feature to prevent kernel executing/accessing
user address involuntarily, any such behavior will lead to a page fault.

SMEP/SMAP is open (in CR4) for both Xen and HVM guest in earlier code.
SMEP/SMAP bit set in Xen CR4 would enforce security checking for 32-bit
PV guest which will suffer unknown SMEP/SMAP page fault when guest
kernel attempt to access user address although SMEP/SMAP is close for
PV guests.

This patch introduces a new boot option value "hvm" for "sm{e,a}p", it
is going to diable SMEP/SMAP for Xen hypervisor while enable them for
HVM. In this way, 32-bit PV guest will not suffer SMEP/SMAP security
issue. Users can choose whether open SMEP/SMAP for Xen itself,
especially when they are going to run 32-bit PV guests.

Signed-off-by: He Chen 

---
Changes in v5:
* refine sm{e,a}p parameters parser flow.
* replace cpu_has_sm{e,a}p with boot_cpu_has(X86_FEATURE_XEN_SM{E,A}P).
* refine docs.

Changes in v4:
* introduce 2 new synthetic features X86_FEATURE_XEN_SMEP and
  X86_FEATURE_XEN_SMAP for Xen itself.
* adjust SM{E,A}P related instruction patching code.
* commit message refinement.

Changes in v3:
* fix boot options.
* fix CR4 & mmu_cr4_features operations.
* disable SMEP/SMAP for Dom0.
* commit message refinement.

Changes in v2:
* allow "hvm" as a value to "smep" and "smap" command line options.
* clear SMEP/SMAP CPUID bits for pv guests if they are set to hvm only.
* refine docs.
* rewrite commit message.
---
 docs/misc/xen-command-line.markdown |  2 ++
 xen/arch/x86/setup.c| 54 -
 xen/include/asm-x86/asm_defns.h | 10 +++
 xen/include/asm-x86/cpufeature.h|  4 +--
 4 files changed, 51 insertions(+), 19 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 3a250cb..0225974 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1433,6 +1433,7 @@ Set the serial transmit buffer size.
 > Default: `true`
 
 Flag to enable Supervisor Mode Execution Protection
+Use `smep=hvm` to allow SMEP use by HVM guests only.
 
 ### smap
 > `= `
@@ -1440,6 +1441,7 @@ Flag to enable Supervisor Mode Execution Protection
 > Default: `true`
 
 Flag to enable Supervisor Mode Access Prevention
+Use `smap=hvm` to allow SMAP use by HVM guests only.
 
 ### snb\_igd\_quirk
 > `=  | cap | `
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 217c775..5256e99 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -61,14 +61,6 @@ boolean_param("nosmp", opt_nosmp);
 static unsigned int __initdata max_cpus;
 integer_param("maxcpus", max_cpus);
 
-/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
-static bool_t __initdata opt_smep = 1;
-boolean_param("smep", opt_smep);
-
-/* smap: Enable/disable Supervisor Mode Access Prevention (default on). */
-static bool_t __initdata opt_smap = 1;
-boolean_param("smap", opt_smap);
-
 unsigned long __read_mostly cr4_pv32_mask;
 
 /* Boot dom0 in pvh mode */
@@ -111,6 +103,44 @@ struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 
0, 0, -1 };
 
 unsigned long __read_mostly mmu_cr4_features = XEN_MINIMAL_CR4;
 
+/* smep: Enable/disable Supervisor Mode Execution Protection (default on). */
+#define SMEP_HVM_ONLY (-1)
+static s8 __initdata opt_smep = 1;
+static void __init parse_smep_param(char *s)
+{
+if ( !parse_bool(s) )
+{
+opt_smep = 0;
+}
+else if ( !strcmp(s, "hvm") )
+{
+opt_smep = SMEP_HVM_ONLY;
+}
+
+if ( opt_smep == 1 )
+__set_bit(X86_FEATURE_XEN_SMEP, boot_cpu_data.x86_capability);
+}
+custom_param("smep", parse_smep_param);
+
+/* smap: Enable/disable Supervisor Mode Access Prevention (default on). */
+#define SMAP_HVM_ONLY (-1)
+static s8 __initdata opt_smap = 1;
+static void __init parse_smap_param(char *s)
+{
+if ( !parse_bool(s) )
+{
+opt_smap = 0;
+}
+else if ( !strcmp(s, "hvm") )
+{
+opt_smap = SMAP_HVM_ONLY;
+}
+
+if ( opt_smap == 1 )
+__set_bit(X86_FEATURE_XEN_SMAP, boot_cpu_data.x86_capability);
+}
+custom_param("smap", parse_smap_param);
+
 bool_t __read_mostly acpi_disabled;
 bool_t __initdata acpi_force;
 static char __initdata acpi_param[10] = "";
@@ -1403,12 +1433,12 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 if ( !opt_smep )
 setup_clear_cpu_cap(X86_FEATURE_SMEP);
-if ( cpu_has_smep )
+if ( boot_cpu_has(X86_FEATURE_XEN_SMEP) )
 set_in_cr4(X86_CR4_SMEP);
 
 if ( !opt_smap )
 setup_clear_cpu_cap(X86_FEATURE_SMAP);
-if ( cpu_has_smap )
+if ( boot_cpu_has(X86_FEATURE_XEN_SMAP) )
 set_in_cr4(X86_CR4_SMAP);
 
 cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
@@ -1550,7 +1580,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * This saves a large number of corner cases interactions with
  * copy_from_user().
  */

Re: [Xen-devel] [Minios-devel] [PATCH 0/3] repair stubdoms

[Wei Liu]

On Tue, Aug 30, 2016 at 01:51:20PM +0200, Juergen Gross wrote:
> Adding support for HVMlite Mini-OS broke some stubdom functionality
> as various parts of the stubdom code was built without specifying
> any Mini-OS configuration defines. This led to inconsistencies when
> those parts included Mini-OS headers now depending on the config of
> Mini9-OS. Some of those cases did work just by pure luck.
> 
> Juergen Gross (3):
>   mini-os: support newer xen interface
>   mini-os: provide irq on/off/save/restore functions for Mini-OS apps
>   mini-os: support "make config" for out-of-tree users
> 

Pushed.

I will update Xen's Config.mk soon-ish.

Wei.

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

Re: [Xen-devel] [PATCH] tools/migrate: Prevent PTE truncation from being fatal duing the live phase

[Wei Liu]

On Thu, Sep 01, 2016 at 10:45:03AM +0100, Andrew Cooper wrote:
> It is possible, when normalising a PV pagetable that the table has been freed
> and reused for something else by the guest.
> 
> In such a case, data read might no longer be a pagetable, and fail the
> truncation check.  However, this should only be fatal if we encounter such a
> page in the paused phase.
> 
> This check is now consistent with all other checks in the same area.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] doc: fix some typos

[Wei Liu]

On Thu, Sep 01, 2016 at 01:02:45PM +0200, Juergen Gross wrote:
> Fix some typos in docs/man/xl.cfg.pod.5.in
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 06/38] arm/p2m: Add HVMOP_altp2m_get_domain_state

[Sergej Proskurin]

Hi Julien,

On 09/01/2016 07:06 PM, Julien Grall wrote:
> Hello Sergej,
> 
> On 16/08/16 23:16, Sergej Proskurin wrote:
>> This commit adopts the x86 HVMOP_altp2m_get_domain_state implementation.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v3: Removed the "altp2m_enabled" check in HVMOP_altp2m_get_domain_state
>> case as it has been moved in front of the switch statement in
>> "do_altp2m_op".
>>
>> Removed the macro "altp2m_enabled". Instead, check directly for the
>> HVM_PARAM_ALTP2M param in d->arch.hvm_domain.
>> ---
>>  xen/arch/arm/hvm.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index ce6a436..180154e 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -66,7 +66,7 @@ static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void)
>> arg)
>>  goto out;
>>  }
>>
>> -if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
>> +if ( !d->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
> 
> Spurious change. This should be merged in patch #4.
> 

I will change that, thanks.

>>  {
>>  rc = -EINVAL;
>>  goto out;
>> @@ -78,7 +78,8 @@ static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void)
>> arg)
>>  switch ( a.cmd )
>>  {
>>  case HVMOP_altp2m_get_domain_state:
>> -rc = -EOPNOTSUPP;
>> +a.u.domain_state.state = altp2m_active(d);
>> +rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
>>  break;
>>
>>  case HVMOP_altp2m_set_domain_state:
>>
> 
> Regards,
> 

Best regards,
~Sergej

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

[Xen-devel] [PATCH 0/3] mini-os: test and document config variations

[Juergen Gross]

Add a "testbuild" target to Makefile which builds various configurations.
Repair some minor issues uncovered by those test builds.
Document the config framework.

Juergen Gross (3):
  mini-os: fix builds with uncommon config settings
  mini-os: add testbuild target to Makefile
  mini-os: update README to reflect recent changes

 Makefile  | 10 ++
 README| 31 +++
 arch/x86/arch.mk  |  2 ++
 arch/x86/testbuild/all-no | 18 ++
 arch/x86/testbuild/all-yes| 19 +++
 arch/x86/testbuild/balloon|  2 ++
 arch/x86/testbuild/newxen |  1 +
 arch/x86/testbuild/newxen-yes | 20 
 arch/x86/testbuild/std|  0
 include/x86/os.h  |  5 +
 include/xenbus.h  |  6 --
 11 files changed, 112 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/testbuild/all-no
 create mode 100644 arch/x86/testbuild/all-yes
 create mode 100644 arch/x86/testbuild/balloon
 create mode 100644 arch/x86/testbuild/newxen
 create mode 100644 arch/x86/testbuild/newxen-yes
 create mode 100644 arch/x86/testbuild/std

-- 
2.6.6


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

[Xen-devel] [PATCH 3/3] mini-os: update README to reflect recent changes

[Juergen Gross]

Add some notes to README regarding configuration of Mini-OS via config
files.

Signed-off-by: Juergen Gross 
---
 README | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/README b/README
index 7e9c07a..abd8440 100644
--- a/README
+++ b/README
@@ -19,6 +19,37 @@ This includes:
 
 - to build it just type make.
 
+- Mini-OS can be configured in various ways by specifying a config file:
+
+  MINIOS_CONFIG=config-file make
+
+  config-file can contain various CONFIG_* items set to either "y" or "n".
+  Their defaults can be found in Config.mk.
+  It is possible to specify the interface version of Xen via setting
+
+  XEN_INTERFACE_VERSION=
+
+  in the config file. This defaults to 0x00030205, which is the minimal
+  version supported. The latest available version is specified by setting
+
+  XEN_INTERFACE_VERSION=__XEN_LATEST_INTERFACE_VERSION__
+
+- By typing
+
+  make testbuild
+
+  it is possible to test builds of various configurations. This should be
+  done always after modifying Mini-OS.
+
+  The configurations which are build tested can be found in the directory
+  arch/*/testbuild with one file per configuration. Those configurations are
+  being built for each sub-architecture (e.g. x86_32 and x86_64 for the
+  x86 architecture).
+
+  Please update the current configuration files when adding a new CONFIG_
+  item and maybe even add a new configuration file if the new item interacts
+  with other CONFIG_ items.
+
 - to build it with TCP/IP support, download LWIP 1.3.2 source code and type
 
   make LWIPDIR=/path/to/lwip/source
-- 
2.6.6


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

Re: [Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Wei Liu]

On Fri, Sep 02, 2016 at 11:51:06AM +0300, Razvan Cojocaru wrote:
> Currently it is only possible to set mem_access restrictions only for
> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> This patch introduces a new libxc function taking an array of GFNs.
> The alternative would be to set each page in turn, using a userspace-HV
> roundtrip for each call, and triggering a TLB flush per page set.
> 
> Signed-off-by: Razvan Cojocaru 
> 
> ---
> Changes since V1 / RFC:
>  - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
>and XENMEM_access_op_set_access_sparse to
>XENMEM_access_op_set_access_multi.
>  - Renamed the 'nr' parameter to 'size'.
>  - Wrapped long line in the implementation of xc_set_mem_access_multi().
>  - Factored out common code in _p2m_set_mem_access() (and modified
>p2m_set_altp2m_mem_access() in the process, to take an unsigned
>long argument instead of a gfn_t).
>  - Factored out xenmem_access_t to p2m_access_t conversion code in
>p2m_xenmem_access_to_p2m_access().
>  - Added hypercall continuation support.
>  - Added compat translation support.
>  - No longer allocating buffers (now using copy_from_guest_offset()).
>  - Added support for setting an array of access restrictions, as
>suggested by Tamas Lengyel.
>  - This patch incorporates Jan Beulich's "memory: fix compat handling
>of XENMEM_access_op".
> ---
>  tools/libxc/include/xenctrl.h |   4 ++
>  tools/libxc/xc_mem_access.c   |  38 ++

Acked-by: Wei Liu 

FAOD I am happy with hv maintainers handle this patch.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  1461504ce3c414fc5dc717ce16f039d0742b455a
baseline version:
 xen  a4f39a6450abe5207cb33f877b4b6cd5db8a6cca

Last test of basis   100698  2016-09-01 14:01:50 Z0 days
Testing same since   100718  2016-09-02 07:02:22 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=1461504ce3c414fc5dc717ce16f039d0742b455a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
1461504ce3c414fc5dc717ce16f039d0742b455a
+ branch=xen-unstable-smoke
+ revision=1461504ce3c414fc5dc717ce16f039d0742b455a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x1461504ce3c414fc5dc717ce16f039d0742b455a = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [PATCH v3 04/38] arm/p2m: Add first altp2m HVMOP stubs

[Sergej Proskurin]

Hi Julien,

On 09/01/2016 06:09 PM, Julien Grall wrote:
> Hello Sergej,
> 
> On 16/08/16 23:16, Sergej Proskurin wrote:
>> This commit moves the altp2m-related code from x86 to ARM. Functions
> 
> s/moves/copies/
> 
> However, this is not really true because the code is current patch is
> not a verbatim copy.
> 

Ok, I will adapt the commit msg to "copies and extends" in the next patch.

> Lastly, what is the status to have x86 and ARM implementation of
> do_altp2m_op merged?
> 
> It would allow us to get code clean-up more easily. I have in mind the
> recent patch [1] from Paul Lai.
> 
> I am also worry to see the code diverging, for instance the locking is
> likely needed on x86 too.
> 

We believe that (while merging of both code bases definitely does makes
sense) it is out of scope in this patch. The changes you are suggesting
would further blow up this patch series. The current patch series is
already large enough and we really think we should keep focusing on the
implementation the ARM architecture in the first place. We agree that a
merge of both architectures is necessary but also strongly believe that
the merging should be done in a separate patch.

>> that are no yet supported notify the caller or print a BUG message
>> stating their absence.
>>
>> Also, the struct arch_domain is extended with the altp2m_active
>> attribute, representing the current altp2m activity configuration of the
>> domain.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
>> Removed not used altp2m helper stubs in altp2m.h.
>>
>> v3: Cosmetic fixes.
>>
>> Added domain lock in "do_altp2m_op" to avoid concurrent execution of
>> altp2m-related HVMOPs.
>>
>> Added check making sure that HVM_PARAM_ALTP2M is set before
>> execution of altp2m-related HVMOPs.
>> ---
>>  xen/arch/arm/hvm.c   | 89
>> 
>>  xen/include/asm-arm/altp2m.h |  4 +-
>>  xen/include/asm-arm/domain.h |  3 ++
>>  3 files changed, 94 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
>> index d999bde..45d51c6 100644
>> --- a/xen/arch/arm/hvm.c
>> +++ b/xen/arch/arm/hvm.c
>> @@ -32,6 +32,91 @@
>>
>>  #include 
>>
>> +#include 
>> +
>> +static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
>> +{
>> +struct xen_hvm_altp2m_op a;
>> +struct domain *d = NULL;
>> +int rc = 0;
>> +
>> +if ( copy_from_guest(, arg, 1) )
>> +return -EFAULT;
>> +
>> +if ( a.pad1 || a.pad2 ||
>> + (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
>> + (a.cmd < HVMOP_altp2m_get_domain_state) ||
>> + (a.cmd > HVMOP_altp2m_change_gfn) )
>> +return -EINVAL;
>> +
>> +d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
>> +rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
>> +
>> +if ( d == NULL )
>> +return -ESRCH;
>> +
>> +/* Prevent concurrent execution of the following HVMOPs. */
>> +domain_lock(d);
> 
> So you are not allowing concurrent call of set_mem_access on different
> altp2m. Is it something that you plan to fix in the future?
> 

Concurrent access of the altp2m interface, including the set_mem_access
on different altp2m views, is not performance relevant. However, we will
definitely think about which HVMOPs can be executed concurrently without
causing troubles.

>> +
>> +if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
>> + (a.cmd != HVMOP_altp2m_set_domain_state) &&
>> + !altp2m_active(d) )
>> +{
>> +rc = -EOPNOTSUPP;
>> +goto out;
>> +}
>> +
>> +if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
>> +{
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
>> +goto out;
>> +
>> +switch ( a.cmd )
>> +{
>> +case HVMOP_altp2m_get_domain_state:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_set_domain_state:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_vcpu_enable_notify:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_create_p2m:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_destroy_p2m:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_switch_p2m:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_set_mem_access:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_change_gfn:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +}
>> +
>> +out:
>> +domain_unlock(d);
>> +rcu_unlock_domain(d);
>> +
>> +return rc;
>> +}
>> +
>>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>>  {
>>  

Re: [Xen-devel] Issue in MPX support in Xen

[Rockosov, Dmitry]

Hello Jan,

I have tested your patch, it works fine in situation when cpu_has_mpx = 1 and 
cpu_has_vmx_mpx = 0.

Thank you!

Best regards,
Dmitry Rockosov

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, August 26, 2016 11:09 AM
> To: Rockosov, Dmitry 
> Cc: Andrew Cooper ; Sorokin, Georgy
> ; Rechistov, Grigory
> ; Nakajima, Jun ;
> Tian, Kevin ; Kornev, Roman M
> ; Samoylidi, Sergey N
> ; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Issue in MPX support in Xen
> 
> >>> On 25.08.16 at 18:53,  wrote:
> > We are working on enabling XEN with WindRiver Simics, which is Intel
> > reference functional simulator for servers.
> >
> > We found the issue in XEN with MPX using.
> > If MPX is supported by CPUID, but MPX is not supported by VMX, XEN is
> > failing on store CPU MSR GUEST_BNDCFGS (file
> > xen-4.7.0/xen/arch/x86/hvm/vmx/vmx.c:798).
> >
> > SDM says in 24.4.1 Guest Register State:
> > IA32_BNDCFGS (64 bits). This field is supported only on processors
> > that support either the 1-setting of the "load IA32_BNDCFGS" VM-entry
> > control or that of the "clear IA32_BNDCFGS"
> > VM-exit control.
> >
> > Looks like XEN doesn't consult VM-entry control or VM-exit control
> > listed in SDM.
> 
> Could you give the attached patch a try? It's against -unstable and will
> require trivial adjustment to two of the vmx.c hunks in order to apply
> to 4.7.
> 
> Andrew, Kevin, Jun - please take a look as well, in particular regarding
> the non-commit-message remark.
> 
> Jan



Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Jan Beulich]

>>> On 02.09.16 at 09:31,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, September 2, 2016 3:04 PM
>> To: Wu, Feng 
>> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> de...@lists.xen.org 
>> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
>> PI hooks
>> 
>> >>> On 02.09.16 at 03:46,  wrote:
>> 
>> >
>> >> -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Thursday, September 1, 2016 4:30 PM
>> >> To: Wu, Feng 
>> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
>> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
>> >> de...@lists.xen.org 
>> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain before/after
>> assigning
>> >> PI hooks
>> >>
>> >> >>> On 31.08.16 at 05:56,  wrote:
>> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain *d)
>> >> >
>> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>> >> >
>> >> > +/*
>> >> > + * Pausing the domain can make sure the vCPU is not
>> >> > + * running and hence calling the hooks simultaneously
>> >> > + * when deassigning the PI hooks. This makes sure that
>> >> > + * all the appropriate state of PI descriptor is actually
>> >> > + * set up for all vCPus before leaving this function.
>> >> > + */
>> >> > +domain_pause(d);
>> >> > +
>> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
>> >> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
>> >> > +
>> >> > +domain_unpause(d);
>> >> >  }
>> >>
>> >> First of all I'm missing a word on whether the race mentioned in
>> >> the description and comment can actually happen. Device
>> >> (de)assignment should already be pretty much serialized (via
>> >> the domctl lock, and maybe also via the pcidevs one).
>> >
>> > The purpose of this patch is to address the race condition that
>> > the _vCPU_ is running while we are installing these hooks. Do you
>> > think this cannot happen?  This patch is trying to fix the issue
>> > described at:
>> > http://www.gossamer-threads.com/lists/xen/devel/433229 
>> > Consider that the other two hooks were installed when the VM
>> > is created, seems no such race condition. However, according
>> > to the discussion about patch 1 and patch 2 of series, we need
>> > to install the other two hooks here as well,
>> 
>> I don't think we've agreed that the creation time installation of
>> those hooks is actually necessary. In fact your most recent
>> response to patch 1 makes me think you now agree we don't
>> need to do so. And hence with that precondition not holding
>> anymore, I don't think the conclusion does.
> 
> I think there might be some confusion. Let me explain what I
> am think of to make sure we are on the same page:
> 1. We need install all the four hooks when the first device is
> assigned.
> 2. If _1_ is true, the issue described in
> http://www.gossamer-threads.com/lists/xen/devel/433229 
> exists.

If you mean this

* vcpu 0 starts running on a pcpu
* a device is assigned, causing the hooks to be set
* an interrupt from the device is routed to vcpu 0, but it is not
actually delivered properly, since ndst is not pointing to the right
processor.

raised by George, then I'm not convinced it can happen (after all, the
hooks get set _before_ the device gets assigned, and hence before
the device can raise an interrupt destined at the guest). And if it can
happen, then rather than pausing the guest I don't see why, along
with setting the hooks, any possibly affected NDST field can't be
programmed correctly. ISTR having recommended something like
this already during review of the series originally introducing PI.

Jan

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

Re: [Xen-devel] [PATCH v5 14/16] public/hvm/params.h: Add macros for HVM_PARAM_CALLBACK_TYPE_PPI

[Jan Beulich]

>>> On 02.09.16 at 09:23,  wrote:

> 
> On 2016/9/2 14:18, Jan Beulich wrote:
> On 02.09.16 at 04:55,  wrote:
>>> --- a/xen/include/public/hvm/params.h
>>> +++ b/xen/include/public/hvm/params.h
>>> @@ -30,6 +30,7 @@
>>>   */
>>>  
>>>  #define HVM_PARAM_CALLBACK_IRQ 0
>>> +#define HVM_PARAM_CALLBACK_IRQ_TYPE_SHIFT 56
>> 
>> This covering the top 8 bits, just the shift value might indeed be
>> enough.
>> 
>>> @@ -66,6 +67,8 @@
>>>   * This is only used by ARM/ARM64 and masking/eoi the interrupt associated 
>>> to
>>>   * the notification is handled by the interrupt controller.
>>>   */
>>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_SHIFT 8
>>> +#define HVM_PARAM_CALLBACK_TYPE_PPI_FLAG_LOW_LEVEL 2
>> 
>> Here, however, I don't see how the shift value alone can be of
>> use when wanting to extract the relevant bits. I think this (and
>> for consistency also the other) value should be specified as a
>> mask, with users expected to have mechanisms like our
>> MASK_EXTR() / MASK_INSR() available.
>> 
> Ok, will add the mask. Thanks.

And just to avoid any misunderstanding (and another extra round
trip): I mean there to be _only_ a mask definition, without any
shift values (as those can be derived).

Jan


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

[Xen-devel] [PATCH] libxl: fix libxl_device_usbdev_list()

[Juergen Gross]

Commit 03814de1d2ecdabedabceb8e728d934a632a43b9 ("libxl: Do not trust
frontend for vusb") introduced an error in libxl_device_usbdev_list().
Fix it.

Signed-off-by: Juergen Gross 
---
Backport candidate for 4.7
---
 tools/libxl/libxl_pvusb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
index 88e9ed4..75f7b8b 100644
--- a/tools/libxl/libxl_pvusb.c
+++ b/tools/libxl/libxl_pvusb.c
@@ -736,7 +736,7 @@ libxl_device_usbdev_list(libxl_ctx *ctx, uint32_t domid, 
int *num)
 *num = 0;
 
 libxl_vusbs_path = GCSPRINTF("%s/device/vusb",
- libxl__xs_libxl_path(gc, !domid));
+ libxl__xs_libxl_path(gc, domid));
 usbctrls = libxl__xs_directory(gc, XBT_NULL, libxl_vusbs_path, );
 
 for (i = 0; i < nc; i++) {
-- 
2.6.6


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

Re: [Xen-devel] [PATCH] libxl: fix libxl_device_usbdev_list()

[Wei Liu]

On Fri, Sep 02, 2016 at 10:16:14AM +0200, Juergen Gross wrote:
> Commit 03814de1d2ecdabedabceb8e728d934a632a43b9 ("libxl: Do not trust
> frontend for vusb") introduced an error in libxl_device_usbdev_list().
> Fix it.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

> ---
> Backport candidate for 4.7
> ---
>  tools/libxl/libxl_pvusb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/libxl/libxl_pvusb.c b/tools/libxl/libxl_pvusb.c
> index 88e9ed4..75f7b8b 100644
> --- a/tools/libxl/libxl_pvusb.c
> +++ b/tools/libxl/libxl_pvusb.c
> @@ -736,7 +736,7 @@ libxl_device_usbdev_list(libxl_ctx *ctx, uint32_t domid, 
> int *num)
>  *num = 0;
>  
>  libxl_vusbs_path = GCSPRINTF("%s/device/vusb",
> - libxl__xs_libxl_path(gc, !domid));
> + libxl__xs_libxl_path(gc, domid));
>  usbctrls = libxl__xs_directory(gc, XBT_NULL, libxl_vusbs_path, );
>  
>  for (i = 0; i < nc; i++) {
> -- 
> 2.6.6
> 

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

[Xen-devel] [distros-debian-jessie test] 67625: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-jessie-netboot-pvgrub 10 guest-start fail REGR. vs. 
67596

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass

baseline version:
 flight   67596

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub fail
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-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] fail to register IRQ for virtualization exception

[Big Strong]

Sorry for that. Could you give any suggestions on how to register the IRQ
handler for #VE?

2016-09-02 15:52 GMT+08:00 Jan Beulich :

> >>> On 02.09.16 at 04:59,  wrote:
> > I'm recently trying to utilize the virtualization exception (#VE)
> feature.
> > As the document says, #VE is handled by guest interrupt handler. The IRQ
> > number of #VE is 20. However, when I tried to register an IRQ handler for
> > #VE, it returns errno -22, which means invalid arguments.
> >
> > request_irq(20, ve_handler, IRQF_NO_SUSPEND, "ve", NULL)
> >
> > Is there anything wrong?
>
> You're mixing up exception vectors and IRQ numbers.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 03/38] arm/p2m: Introduce p2m_(switch|restore)_vttbr_and_(g|s)et_flags

[Sergej Proskurin]

Hi Julien,

On 09/01/2016 05:51 PM, Julien Grall wrote:
> Hello Sergej,
> 
> On 16/08/16 23:16, Sergej Proskurin wrote:
>> This commit introduces macros for switching and restoring the vttbr
>> considering the currently set irq flags. We define these macros, as the
>> following commits will use the associated functionality multiple times
>> throughout the file ./xen/arch/arm/p2m.c.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>>  xen/arch/arm/p2m.c | 37 +++--
>>  1 file changed, 23 insertions(+), 14 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 08114d8..02e9ee7 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -27,6 +27,26 @@ static unsigned int __read_mostly p2m_root_level;
>>
>>  #define P2M_ROOT_PAGES(1<>
>> +#define p2m_switch_vttbr_and_get_flags(ovttbr, nvttbr, flags)   \
>> +({  \
> 
> It makes more sense to save the content of VTTBR_EL2 in the macro.
> 

I assume you mean the VTTBR_EL2 within the macro parameter ovttbr. I
will move the definition of the ovttbr variable into the macro and
return its value at the end so that it can be subsequently provided with
the "p2m_restore_vttbr_and_set_flags" macro. Thank you.

>> +if ( ovttbr != nvttbr ) \
>> +{   \
>> +local_irq_save(flags);  \
>> +WRITE_SYSREG64(nvttbr, VTTBR_EL2);  \
>> +isb();  \
>> +}   \
>> +})
>> +
>> +#define p2m_restore_vttbr_and_set_flags(ovttbr, flags)  \
>> +({  \
>> +if ( ovttbr != READ_SYSREG64(VTTBR_EL2) )   \
>> +{   \
>> +WRITE_SYSREG64(ovttbr, VTTBR_EL2);  \
>> +isb();  \
>> +local_irq_restore(flags);   \
>> +}   \
>> +})
>> +
>>  unsigned int __read_mostly p2m_ipa_bits;
>>
>>  /* Helpers to lookup the properties of each level */
>> @@ -173,28 +193,17 @@ void p2m_restore_state(struct vcpu *n)
>>  static void p2m_flush_tlb(struct p2m_domain *p2m)
>>  {
>>  unsigned long flags = 0;
>> -uint64_t ovttbr;
>> +uint64_t ovttbr = READ_SYSREG64(VTTBR_EL2);
>>
>>  /*
>>   * ARM only provides an instruction to flush TLBs for the current
>>   * VMID. So switch to the VTTBR of a given P2M if different.
>>   */
>> -ovttbr = READ_SYSREG64(VTTBR_EL2);
>> -if ( ovttbr != p2m->vttbr )
>> -{
>> -local_irq_save(flags);
>> -WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
>> -isb();
>> -}
>> +p2m_switch_vttbr_and_get_flags(ovttbr, p2m->vttbr, flags);
>>
>>  flush_tlb();
>>
>> -if ( ovttbr != READ_SYSREG64(VTTBR_EL2) )
>> -{
>> -WRITE_SYSREG64(ovttbr, VTTBR_EL2);
>> -isb();
>> -local_irq_restore(flags);
>> -}
>> +p2m_restore_vttbr_and_set_flags(ovttbr, flags);
>>  }
>>
>>  /*
>>
> 
> Regards,
> 


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

Re: [Xen-devel] [PATCH v3 4/6] Pause/Unpause the domain before/after assigning PI hooks

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, September 2, 2016 4:16 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org
> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after assigning
> PI hooks
> 
> >>> On 02.09.16 at 09:31,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, September 2, 2016 3:04 PM
> >> To: Wu, Feng 
> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> >> de...@lists.xen.org
> >> Subject: RE: [PATCH v3 4/6] Pause/Unpause the domain before/after
> assigning
> >> PI hooks
> >>
> >> >>> On 02.09.16 at 03:46,  wrote:
> >>
> >> >
> >> >> -Original Message-
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: Thursday, September 1, 2016 4:30 PM
> >> >> To: Wu, Feng 
> >> >> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> >> >> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> >> >> de...@lists.xen.org
> >> >> Subject: Re: [PATCH v3 4/6] Pause/Unpause the domain before/after
> >> assigning
> >> >> PI hooks
> >> >>
> >> >> >>> On 31.08.16 at 05:56,  wrote:
> >> >> > --- a/xen/arch/x86/hvm/vmx/vmx.c
> >> >> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
> >> >> > @@ -219,8 +219,19 @@ void vmx_pi_hooks_assign(struct domain *d)
> >> >> >
> >> >> >  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> >> >> >
> >> >> > +/*
> >> >> > + * Pausing the domain can make sure the vCPU is not
> >> >> > + * running and hence calling the hooks simultaneously
> >> >> > + * when deassigning the PI hooks. This makes sure that
> >> >> > + * all the appropriate state of PI descriptor is actually
> >> >> > + * set up for all vCPus before leaving this function.
> >> >> > + */
> >> >> > +domain_pause(d);
> >> >> > +
> >> >> >  d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> >> >> >  d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> >> >> > +
> >> >> > +domain_unpause(d);
> >> >> >  }
> >> >>
> >> >> First of all I'm missing a word on whether the race mentioned in
> >> >> the description and comment can actually happen. Device
> >> >> (de)assignment should already be pretty much serialized (via
> >> >> the domctl lock, and maybe also via the pcidevs one).
> >> >
> >> > The purpose of this patch is to address the race condition that
> >> > the _vCPU_ is running while we are installing these hooks. Do you
> >> > think this cannot happen?  This patch is trying to fix the issue
> >> > described at:
> >> > http://www.gossamer-threads.com/lists/xen/devel/433229
> >> > Consider that the other two hooks were installed when the VM
> >> > is created, seems no such race condition. However, according
> >> > to the discussion about patch 1 and patch 2 of series, we need
> >> > to install the other two hooks here as well,
> >>
> >> I don't think we've agreed that the creation time installation of
> >> those hooks is actually necessary. In fact your most recent
> >> response to patch 1 makes me think you now agree we don't
> >> need to do so. And hence with that precondition not holding
> >> anymore, I don't think the conclusion does.
> >
> > I think there might be some confusion. Let me explain what I
> > am think of to make sure we are on the same page:
> > 1. We need install all the four hooks when the first device is
> > assigned.
> > 2. If _1_ is true, the issue described in
> > http://www.gossamer-threads.com/lists/xen/devel/433229
> > exists.
> 
> If you mean this
> 
> * vcpu 0 starts running on a pcpu
> * a device is assigned, causing the hooks to be set
> * an interrupt from the device is routed to vcpu 0, but it is not
> actually delivered properly, since ndst is not pointing to the right
> processor.
> 
> raised by George, then I'm not convinced it can happen (after all, the
> hooks get set _before_ the device gets assigned, and hence before
> the device can raise an interrupt destined at the guest). And if it can
> happen, then rather than pausing the guest I don't see why, along
> with setting the hooks, any possibly affected NDST field can't be
> programmed correctly. ISTR having recommended something like
> this already during review of the series originally introducing PI.

Actually here is the scenario I am concerned about:
1. ' vmx_vcpu_block ' is installed while vCPU is running vcpu_block()
and then vmx_vcpu_block().
2. There is a ASSERT() about 'NDST' field in vmx_vcpu_block(), I think
we may hit the ASSERT() since 'NDST' may not have been set to the
current processor yet.

My previous solution in v2 is to delete that ASSERT(), but seems you
guys don't like it. So here I 

[Xen-devel] [PATCH V2] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

Currently it is only possible to set mem_access restrictions only for
a contiguous range of GFNs (or, as a particular case, for a single GFN).
This patch introduces a new libxc function taking an array of GFNs.
The alternative would be to set each page in turn, using a userspace-HV
roundtrip for each call, and triggering a TLB flush per page set.

Signed-off-by: Razvan Cojocaru 

---
Changes since V1 / RFC:
 - Renamed xc_set_mem_access_sparse() to xc_set_mem_access_multi(),
   and XENMEM_access_op_set_access_sparse to
   XENMEM_access_op_set_access_multi.
 - Renamed the 'nr' parameter to 'size'.
 - Wrapped long line in the implementation of xc_set_mem_access_multi().
 - Factored out common code in _p2m_set_mem_access() (and modified
   p2m_set_altp2m_mem_access() in the process, to take an unsigned
   long argument instead of a gfn_t).
 - Factored out xenmem_access_t to p2m_access_t conversion code in
   p2m_xenmem_access_to_p2m_access().
 - Added hypercall continuation support.
 - Added compat translation support.
 - No longer allocating buffers (now using copy_from_guest_offset()).
 - Added support for setting an array of access restrictions, as
   suggested by Tamas Lengyel.
 - This patch incorporates Jan Beulich's "memory: fix compat handling
   of XENMEM_access_op".
---
 tools/libxc/include/xenctrl.h |   4 ++
 tools/libxc/xc_mem_access.c   |  38 ++
 xen/arch/x86/mm/p2m.c | 161 --
 xen/common/compat/memory.c|  24 +--
 xen/common/mem_access.c   |  11 +++
 xen/include/public/memory.h   |  14 +++-
 xen/include/xen/p2m-common.h  |   6 ++
 xen/include/xlat.lst  |   2 +-
 8 files changed, 215 insertions(+), 45 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 560ce7b..c2f14a6 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2125,6 +2125,10 @@ int xc_set_mem_access(xc_interface *xch, domid_t 
domain_id,
   xenmem_access_t access, uint64_t first_pfn,
   uint32_t nr);
 
+int xc_set_mem_access_multi(xc_interface *xch, domid_t domain_id,
+uint8_t *access, uint64_t *pages,
+uint32_t size);
+
 /*
  * Gets the mem access for the given page (returned in access on success)
  */
diff --git a/tools/libxc/xc_mem_access.c b/tools/libxc/xc_mem_access.c
index eee088c..d69d4f9 100644
--- a/tools/libxc/xc_mem_access.c
+++ b/tools/libxc/xc_mem_access.c
@@ -41,6 +41,44 @@ int xc_set_mem_access(xc_interface *xch,
 return do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
 }
 
+int xc_set_mem_access_multi(xc_interface *xch,
+domid_t domain_id,
+uint8_t *access,
+uint64_t *pages,
+uint32_t size)
+{
+DECLARE_HYPERCALL_BOUNCE(access, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(pages, size * sizeof(uint64_t),
+ XC_HYPERCALL_BUFFER_BOUNCE_IN);
+int rc;
+
+xen_mem_access_op_t mao =
+{
+.op   = XENMEM_access_op_set_access_multi,
+.domid= domain_id,
+.access   = XENMEM_access_default + 1, /* Invalid value */
+.pfn  = ~0UL, /* Invalid GFN */
+.nr   = size,
+};
+
+if ( xc_hypercall_bounce_pre(xch, pages) ||
+ xc_hypercall_bounce_pre(xch, access) )
+{
+PERROR("Could not bounce memory for 
XENMEM_access_op_set_access_multi");
+return -1;
+}
+
+set_xen_guest_handle(mao.pfn_list, pages);
+set_xen_guest_handle(mao.access_list, access);
+
+rc = do_memory_op(xch, XENMEM_access_op, , sizeof(mao));
+
+xc_hypercall_bounce_post(xch, access);
+xc_hypercall_bounce_post(xch, pages);
+
+return rc;
+}
+
 int xc_get_mem_access(xc_interface *xch,
   domid_t domain_id,
   uint64_t pfn,
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 812dbf6..ee6438b 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include  /* copy_from_guest() */
 #include 
 #include 
 #include 
@@ -1772,13 +1773,12 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
gla,
 static inline
 int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
   struct p2m_domain *ap2m, p2m_access_t a,
-  gfn_t gfn)
+  unsigned long gfn_l)
 {
 mfn_t mfn;
 p2m_type_t t;
 p2m_access_t old_a;
 unsigned int page_order;
-unsigned long gfn_l = gfn_x(gfn);
 int rc;
 
 mfn = ap2m->get_entry(ap2m, gfn_l, , _a, 0, NULL, NULL);
@@ -1811,21 +1811,39 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
p2m_domain *hp2m,
  (current->domain != d));
 }
 
-/*
- * Set 

Re: [Xen-devel] [PATCH] libxl: fix libxl_device_usbdev_list()

[Wei Liu]

On Fri, Sep 02, 2016 at 09:32:03AM +0100, Wei Liu wrote:
> On Fri, Sep 02, 2016 at 10:16:14AM +0200, Juergen Gross wrote:
> > Commit 03814de1d2ecdabedabceb8e728d934a632a43b9 ("libxl: Do not trust
> > frontend for vusb") introduced an error in libxl_device_usbdev_list().
> > Fix it.
> > 
> > Signed-off-by: Juergen Gross 
> 
> Acked-by: Wei Liu 
> 
> > ---
> > Backport candidate for 4.7

Pushed.  Backport to 4.7 is required.

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

[Xen-devel] [PATCH 2/3] mini-os: add testbuild target to Makefile

[Juergen Gross]

Add a "testbuild" target to the Makefile to test building a set of
pre-defined configurations.

Configurations tested are stored under arch//testbuild in form
of configuration files. All configurations found there are built in
a local directory.

Signed-off-by: Juergen Gross 
---
 Makefile  | 10 ++
 arch/x86/arch.mk  |  2 ++
 arch/x86/testbuild/all-no | 18 ++
 arch/x86/testbuild/all-yes| 19 +++
 arch/x86/testbuild/balloon|  2 ++
 arch/x86/testbuild/newxen |  1 +
 arch/x86/testbuild/newxen-yes | 20 
 arch/x86/testbuild/std|  0
 8 files changed, 72 insertions(+)
 create mode 100644 arch/x86/testbuild/all-no
 create mode 100644 arch/x86/testbuild/all-yes
 create mode 100644 arch/x86/testbuild/balloon
 create mode 100644 arch/x86/testbuild/newxen
 create mode 100644 arch/x86/testbuild/newxen-yes
 create mode 100644 arch/x86/testbuild/std

diff --git a/Makefile b/Makefile
index 8e8e56e..81b936f 100644
--- a/Makefile
+++ b/Makefile
@@ -178,6 +178,16 @@ clean: arch_clean
$(RM) $(OBJ_DIR)/lwip.a $(LWO)
rm -f tags TAGS
 
+.PHONY: testbuild
+TEST_CONFIGS := $(wildcard $(CURDIR)/$(TARGET_ARCH_DIR)/testbuild/*)
+testbuild:
+   for arch in $(MINIOS_TARGET_ARCHS); do \
+   for conf in $(TEST_CONFIGS); do \
+   $(MAKE) clean; \
+   MINIOS_TARGET_ARCH=$$arch MINIOS_CONFIG=$$conf $(MAKE) 
|| exit 1; \
+   done; \
+   done
+   $(MAKE) clean
 
 define all_sources
  ( find . -name '*.[chS]' -print )
diff --git a/arch/x86/arch.mk b/arch/x86/arch.mk
index 673a19d..c87885f 100644
--- a/arch/x86/arch.mk
+++ b/arch/x86/arch.mk
@@ -3,6 +3,8 @@
 # (including x86_32, x86_32y and x86_64).
 #
 
+MINIOS_TARGET_ARCHS := x86_32 x86_64
+
 ifeq ($(MINIOS_TARGET_ARCH),x86_32)
 ARCH_CFLAGS  := -m32 -march=i686
 ARCH_LDFLAGS := -m elf_i386
diff --git a/arch/x86/testbuild/all-no b/arch/x86/testbuild/all-no
new file mode 100644
index 000..78720c3
--- /dev/null
+++ b/arch/x86/testbuild/all-no
@@ -0,0 +1,18 @@
+CONFIG_PARAVIRT = n
+CONFIG_START_NETWORK = n
+CONFIG_SPARSE_BSS = n
+CONFIG_QEMU_XS_ARGS = n
+CONFIG_TEST = n
+CONFIG_PCIFRONT = n
+CONFIG_BLKFRONT = n
+CONFIG_TPMFRONT = n
+CONFIG_TPM_TIS = n
+CONFIG_TPMBACK = n
+CONFIG_NETFRONT = n
+CONFIG_FBFRONT = n
+CONFIG_KBDFRONT = n
+CONFIG_CONSFRONT = n
+CONFIG_XENBUS = n
+CONFIG_XC = n
+CONFIG_LWIP = n
+CONFIG_BALLOON = n
diff --git a/arch/x86/testbuild/all-yes b/arch/x86/testbuild/all-yes
new file mode 100644
index 000..303c56b
--- /dev/null
+++ b/arch/x86/testbuild/all-yes
@@ -0,0 +1,19 @@
+CONFIG_PARAVIRT = y
+CONFIG_START_NETWORK = y
+CONFIG_SPARSE_BSS = y
+CONFIG_QEMU_XS_ARGS = y
+CONFIG_TEST = y
+CONFIG_PCIFRONT = y
+CONFIG_BLKFRONT = y
+CONFIG_TPMFRONT = y
+CONFIG_TPM_TIS = y
+CONFIG_TPMBACK = y
+CONFIG_NETFRONT = y
+CONFIG_FBFRONT = y
+CONFIG_KBDFRONT = y
+CONFIG_CONSFRONT = y
+CONFIG_XENBUS = y
+CONFIG_XC = y
+# LWIP is special: it needs support from outside
+CONFIG_LWIP = n
+CONFIG_BALLOON = y
diff --git a/arch/x86/testbuild/balloon b/arch/x86/testbuild/balloon
new file mode 100644
index 000..6fa5eef
--- /dev/null
+++ b/arch/x86/testbuild/balloon
@@ -0,0 +1,2 @@
+CONFIG_PARAVIRT = n
+CONFIG_BALLOON = y
diff --git a/arch/x86/testbuild/newxen b/arch/x86/testbuild/newxen
new file mode 100644
index 000..b412924
--- /dev/null
+++ b/arch/x86/testbuild/newxen
@@ -0,0 +1 @@
+XEN_INTERFACE_VERSION=__XEN_LATEST_INTERFACE_VERSION__
diff --git a/arch/x86/testbuild/newxen-yes b/arch/x86/testbuild/newxen-yes
new file mode 100644
index 000..907a8a0
--- /dev/null
+++ b/arch/x86/testbuild/newxen-yes
@@ -0,0 +1,20 @@
+CONFIG_PARAVIRT = y
+CONFIG_START_NETWORK = y
+CONFIG_SPARSE_BSS = y
+CONFIG_QEMU_XS_ARGS = y
+CONFIG_TEST = y
+CONFIG_PCIFRONT = y
+CONFIG_BLKFRONT = y
+CONFIG_TPMFRONT = y
+CONFIG_TPM_TIS = y
+CONFIG_TPMBACK = y
+CONFIG_NETFRONT = y
+CONFIG_FBFRONT = y
+CONFIG_KBDFRONT = y
+CONFIG_CONSFRONT = y
+CONFIG_XENBUS = y
+CONFIG_XC = y
+# LWIP is special: it needs support from outside
+CONFIG_LWIP = n
+CONFIG_BALLOON = y
+XEN_INTERFACE_VERSION=__XEN_LATEST_INTERFACE_VERSION__
diff --git a/arch/x86/testbuild/std b/arch/x86/testbuild/std
new file mode 100644
index 000..e69de29
-- 
2.6.6


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

Re: [Xen-devel] [PATCH] doc: fix some typos

[Wei Liu]

On Fri, Sep 02, 2016 at 09:30:48AM +0100, Wei Liu wrote:
> On Thu, Sep 01, 2016 at 01:02:45PM +0200, Juergen Gross wrote:
> > Fix some typos in docs/man/xl.cfg.pod.5.in
> > 
> > Signed-off-by: Juergen Gross 
> 
> Acked-by: Wei Liu 

Pushed.

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

[Xen-devel] [PATCH 1/3] mini-os: fix builds with uncommon config settings

[Juergen Gross]

Some config settings won't build standalone. Fix the following cases:

- all CONFIG_* set to "n"
- standard config with latest Xen interface version

Signed-off-by: Juergen Gross 
---
 include/x86/os.h | 5 +
 include/xenbus.h | 6 --
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/x86/os.h b/include/x86/os.h
index 90ab6e6..0f5dd6c 100644
--- a/include/x86/os.h
+++ b/include/x86/os.h
@@ -514,6 +514,11 @@ static __inline__ unsigned long __ffs(unsigned long word)
 #endif /* ifdef __INSIDE_MINIOS */
 
 /* common i386 and x86_64  /
+#define xen_mb()  mb()
+#define xen_rmb() rmb()
+#define xen_wmb() wmb()
+#define xen_barrier() asm volatile ( "" : : : "memory")
+
 #define wrmsr(msr,val1,val2) \
   __asm__ __volatile__("wrmsr" \
: /* no outputs */ \
diff --git a/include/xenbus.h b/include/xenbus.h
index c254652..12391b9 100644
--- a/include/xenbus.h
+++ b/include/xenbus.h
@@ -7,10 +7,14 @@ typedef unsigned long xenbus_transaction_t;
 #define XBT_NIL ((xenbus_transaction_t)0)
 
 #ifdef CONFIG_XENBUS
+extern uint32_t xenbus_evtchn;
+
 /* Initialize the XenBus system. */
 void init_xenbus(void);
 void get_xenbus(void *p);
 #else
+#define xenbus_evtchn ~0
+
 static inline void init_xenbus(void)
 {
 }
@@ -33,8 +37,6 @@ struct xenbus_event {
 };
 typedef struct xenbus_event *xenbus_event_queue;
 
-extern uint32_t xenbus_evtchn;
-
 char *xenbus_watch_path_token(xenbus_transaction_t xbt, const char *path, 
const char *token, xenbus_event_queue *events);
 char *xenbus_unwatch_path_token(xenbus_transaction_t xbt, const char *path, 
const char *token);
 extern struct wait_queue_head xenbus_watch_queue;
-- 
2.6.6


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