Re: [Xen-devel] [PATCH v6 2/7] VMX: Properly handle pi when all the assigned devices are removed

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Friday, October 28, 2016 9:19 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 v6 2/7] VMX: Properly handle pi when all the assigned
> devices are removed
> 
> >>> On 28.10.16 at 04:37,  wrote:
> > @@ -215,11 +220,21 @@ void vmx_pi_hooks_assign(struct domain *d)
> >  /* This function is called when pcidevs_lock is held */
> >  void vmx_pi_hooks_deassign(struct domain *d)
> >  {
> > +struct vcpu *v;
> > +
> >  if ( !iommu_intpost || !has_hvm_container_domain(d) )
> >  return;
> >
> >  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
> >
> > +/*
> > + * Pausing the domain can make sure the vCPU is not
> > + * running and hence not calling the hooks simultaneously
> > + * when deassigning the PI hooks and removing the vCPU
> > + * from the blocking list.
> > + */
> > +domain_pause(d);
> 
> There's one additional caveat here which no-one of us so far thought
> of: Currently there's nothing preventing the domctl-s under which
> this sits from being issued by the control domain for itself. Various
> other domctl-s, however, guard against this case when intending
> to pause the target domain. The same needs to be done for the
> ones leading here.

Thanks for the comments! Could you share in which case can a domain
attach/detach a device for itself? Thanks!

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH v6 5/7] VT-d: No need to set irq affinity for posted format IRTE

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, October 31, 2016 10:57 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 v6 5/7] VT-d: No need to set irq affinity for posted 
> format
> IRTE
> 
> >>> On 28.10.16 at 04:37,  wrote:
> > v6:
> > - Make pi_can_suppress_irte_update() a check-only function
> > - Introduce another function pi_get_new_irte() to update the 'new_ire' if
> > needed
> 
> I don't see what you need this function for. My earlier comments
> were not meant to make you split the function, but to drop all this
> secondary modification (unless there's actually a reason for this,
> which so far I haven't seen any proof of). Apart from that there
> already is setup_posted_irte(), which seems to do most if not all
> of what you really need.
> 
> In any event, the sequence of operations should be
> 1) create full new entry
> 2) check whether update is needed (i.e. whether old and new entries
>have meaningful differences)
> 3) do update
> 4) flush.

Your early comment suggest we only suppress the affinity related
field. So the modification here is to handle the following case:

When the IRTE is currently in posted mode and this function tries
to update it he remapped mode, then we need to suppress
the affinity related bit, however, if the common fields (fpd, sid
sq, svt) in the new remapped IRTE is different from the value
in the old posted IRTE, what do you suggest we should do?
Here I copy these fields to the new IRTE and update them
accordingly.

> 
> > --- a/xen/drivers/passthrough/vtd/intremap.c
> > +++ b/xen/drivers/passthrough/vtd/intremap.c
> > @@ -547,6 +547,54 @@ static int remap_entry_to_msi_msg(
> >  return 0;
> >  }
> >
> > +static bool pi_can_suppress_irte_update(const struct iremap_entry *new,
> > +const struct iremap_entry *old)
> 
> The two parameter declarations should be aligned with one another.
> 
> > +{
> > +ASSERT( old && new );
> > +
> > +if ( !old->remap.p || !old->remap.im || !new->remap.p || new->remap.im 
> > )
> > +return false;
> 
> The asymmetry regarding the IM bit is confusing, and imo indicates
> a problem with the logic.

Would you please share what the problem is here? If we get here, that means
we are updating a posted IRTE to remapped one.

Thanks,
Feng

> 
> > +/*
> > + * We are updating posted IRTE to remapped one, check whether
> > + * the common fields are going to be changed.
> > + */
> > +if ( ( new->remap.fpd != old->post.fpd ) ||
> > + ( new->remap.sid != old->post.sid ) ||
> > + ( new->remap.sq != old->post.sq ) ||
> > + ( new->remap.svt != old->post.svt ) )
> 
> Stray blanks inside the inner parentheses.
> 
> Jan


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

Re: [Xen-devel] [PATCH] x86emul: {L, S}{G, I}DT ignore operand size overrides in 64-bit mode

[Jan Beulich]

>>> On 02.11.16 at 18:42,  wrote:
> On 02/11/16 16:12, Jan Beulich wrote:
>> This affects not only the layout of the data (always 2+8 bytes), but
>> also the contents (no truncation to 24 bits occurs).
>>
>> Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper , although
> wouldn't it be cleaner to set op_bytes = def_op_bytes, than to keep
> referring back to mode_64()?

That would still mean

if ( mode_64bit() )
op_bytes = def_op_bytes;

and wouldn't eliminate the uses in the second ops->write() /
read_ulong() either.

What we could do in the S{G,I}DT case is

if ( mode_64bit() )
op_bytes = 8;
else if ( op_bytes == 2 )
{
sreg.base &= 0xff;
op_bytes = 4;
}
if ( (rc = ops->write(ea.mem.seg, ea.mem.off+0,
  &sreg.limit, 2, ctxt)) ||
 (rc = ops->write(ea.mem.seg, ea.mem.off+2,
  &sreg.base, op_bytes, ctxt)) )

But the same can't be done in the L{G,I}DT case. Let me know.

Jan


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 756a514aa469c35e1a21c034a513630b7f02ecff
baseline version:
 ovmf 90a40219673303f97890d5ea2e367ee2dc04a0b3

Last test of basis67982  2016-11-02 17:47:29 Z0 days
Testing same since67984  2016-11-03 02:50:26 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Qin Long 

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 756a514aa469c35e1a21c034a513630b7f02ecff
Author: Ard Biesheuvel 
Date:   Mon Oct 31 15:43:49 2016 +

ArmPkg/CpuDxe: set DmaBufferAlignment according to CWG

The DmaBufferAlignment currently defaults to 4, which is dangerously
small and may result in lost data on platforms that perform non-coherent
DMA. So instead, take the CWG value from the cache info registers.

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

commit a8f37449c7e355e6402e3876c9db9e11d875164f
Author: Qin Long 
Date:   Tue Nov 1 10:38:36 2016 +0800

CryptoPkg: Add PKCS5 PBKDF2 interface for password derivation.

Add one new API (Pkcs5HashPassword) to provide PKCS#5 v2.0 PBKDF2
support (Password based encryption key derivation function, specified
in RFC 2898).
Also update the Cryptest utility to include the new API testing (with
the test vector from RFC6070).

Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Reviewed-by: Ting Ye 

commit 72009c626d8b1c237c0de840e9bfe9d23b76b94c
Author: Qin Long 
Date:   Mon Oct 31 15:43:48 2016 +0800

CryptoPkg: Add HMAC-SHA256 cipher support

Add new HMAC-SHA256 cipher support in CryptoPkg to meet more security
and industry requirements,

and update Cryptest utility to include new HMAC-SHA256 test case.

Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Reviewed-by: Ting Ye 

commit b7d1ba0a8ae9719689ad9725e02e4cb5d469a3ae
Author: Qin Long 
Date:   Tue Nov 1 10:25:30 2016 +0800

CryptoPkg: Add HashAll APIs to facilitate the digest computation

Add new HashAll APIs to facilitate the digest computation of blob
data. New APIs include: Md4HashAll(), Md5HashAll(), Sha1HashAll(),
Sha256HashAll(), Sha384HashAll(), and Sha512HashAll().

The corresponding test cases were added in Cryptest utility.

Cc: Ting Ye 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qin Long 
Reviewed-by: Ting Ye 

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

Re: [Xen-devel] Xen on Qualcomm

[Julien Grall]

Hello Sameer,

Please try to retain everyone in CC (or at least the author of the 
e-mail). Otherwise the answer may be delayed. I have added back Suresh.


Regards,

On 02/11/2016 20:37, Goel, Sameer wrote:


Can you please post the error and details on Xen you are using?

Thanks,
Sameer
On 11/2/2016 3:04 AM, Suresh Kanzariya wrote:

Hi,

I am trying to run Xen on Qualcomm 410 platform.

I have come across below link
https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03144.html


which suggest a patch to fix Xen crashes on Qualcomm Technology, So does
anyone has any information on the post support which Qualcomm Platform?

Thanks in advance.

Regards,
Suresh




On Tue, 1 Nov 2016 at 11:48 Suresh Kanzariya mailto:skanzar...@gmail.com>> wrote:

Hi Julien,

Thanks for the information. Let me get some more information on
this, and I will get back to the mailing-list for further
information.

Thanks,
Suresh

On Mon, Oct 31, 2016 at 8:34 PM, Julien Grall mailto:julien.gr...@arm.com>> wrote:



On 31/10/16 14:59, Suresh Kanzariya wrote:

Hi Julien,


Hi,

It seems that I forgot to add xen-devel on CC in my answer.
Sorry for that.

Thanks for the information.

Just wanted to understand that Qualcomm boot itself
contains a
Hypervisor and also Xen is also a hypervisor, so I am not
sure Xen
hypervisor directly fits into the design, I guess Qualcomm
hypervisor
need modification or remove completely to support xen. It
will be
great if you can spread some light on this.


Indeed 2 hypervisors cannot cooperate on the same processor. If
Qualcomm provides any hypervisor, you would have to remove it.

Although, I don't know much this platform, so I would recommend
to contact Qualcomm for anything regarding that.

Regards,

--
Julien Grall


--
Regards,
Suresh


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





--
Julien Grall

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

Re: [Xen-devel] [PATCH v6 2/7] VMX: Properly handle pi when all the assigned devices are removed

[Jan Beulich]

>>> On 03.11.16 at 08:45,  wrote:

> 
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Friday, October 28, 2016 9:19 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 v6 2/7] VMX: Properly handle pi when all the assigned
>> devices are removed
>> 
>> >>> On 28.10.16 at 04:37,  wrote:
>> > @@ -215,11 +220,21 @@ void vmx_pi_hooks_assign(struct domain *d)
>> >  /* This function is called when pcidevs_lock is held */
>> >  void vmx_pi_hooks_deassign(struct domain *d)
>> >  {
>> > +struct vcpu *v;
>> > +
>> >  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>> >  return;
>> >
>> >  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
>> >
>> > +/*
>> > + * Pausing the domain can make sure the vCPU is not
>> > + * running and hence not calling the hooks simultaneously
>> > + * when deassigning the PI hooks and removing the vCPU
>> > + * from the blocking list.
>> > + */
>> > +domain_pause(d);
>> 
>> There's one additional caveat here which no-one of us so far thought
>> of: Currently there's nothing preventing the domctl-s under which
>> this sits from being issued by the control domain for itself. Various
>> other domctl-s, however, guard against this case when intending
>> to pause the target domain. The same needs to be done for the
>> ones leading here.
> 
> Thanks for the comments! Could you share in which case can a domain
> attach/detach a device for itself? Thanks!

That's not the question. The code path needs to be safe, just like
all others (which we also expect Dom0 - or any other eligible domain
- to not use with itself as the target domain).

Jan


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

Re: [Xen-devel] [PATCH v6 2/7] VMX: Properly handle pi when all the assigned devices are removed

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, November 3, 2016 5:08 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 v6 2/7] VMX: Properly handle pi when all the assigned
> devices are removed
> 
> >>> On 03.11.16 at 08:45,  wrote:
> 
> >
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Friday, October 28, 2016 9:19 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 v6 2/7] VMX: Properly handle pi when all the assigned
> >> devices are removed
> >>
> >> >>> On 28.10.16 at 04:37,  wrote:
> >> > @@ -215,11 +220,21 @@ void vmx_pi_hooks_assign(struct domain *d)
> >> >  /* This function is called when pcidevs_lock is held */
> >> >  void vmx_pi_hooks_deassign(struct domain *d)
> >> >  {
> >> > +struct vcpu *v;
> >> > +
> >> >  if ( !iommu_intpost || !has_hvm_container_domain(d) )
> >> >  return;
> >> >
> >> >  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
> >> >
> >> > +/*
> >> > + * Pausing the domain can make sure the vCPU is not
> >> > + * running and hence not calling the hooks simultaneously
> >> > + * when deassigning the PI hooks and removing the vCPU
> >> > + * from the blocking list.
> >> > + */
> >> > +domain_pause(d);
> >>
> >> There's one additional caveat here which no-one of us so far thought
> >> of: Currently there's nothing preventing the domctl-s under which
> >> this sits from being issued by the control domain for itself. Various
> >> other domctl-s, however, guard against this case when intending
> >> to pause the target domain. The same needs to be done for the
> >> ones leading here.
> >
> > Thanks for the comments! Could you share in which case can a domain
> > attach/detach a device for itself? Thanks!
> 
> That's not the question. The code path needs to be safe, just like
> all others (which we also expect Dom0 - or any other eligible domain
> - to not use with itself as the target domain).

Sure, got it!

Thanks,
Feng

> 
> Jan


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

Re: [Xen-devel] [PATCH v6 5/7] VT-d: No need to set irq affinity for posted format IRTE

[Jan Beulich]

>>> On 03.11.16 at 08:46,  wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, October 31, 2016 10:57 PM
>> >>> On 28.10.16 at 04:37,  wrote:
>> > v6:
>> > - Make pi_can_suppress_irte_update() a check-only function
>> > - Introduce another function pi_get_new_irte() to update the 'new_ire' if
>> > needed
>> 
>> I don't see what you need this function for. My earlier comments
>> were not meant to make you split the function, but to drop all this
>> secondary modification (unless there's actually a reason for this,
>> which so far I haven't seen any proof of). Apart from that there
>> already is setup_posted_irte(), which seems to do most if not all
>> of what you really need.
>> 
>> In any event, the sequence of operations should be
>> 1) create full new entry
>> 2) check whether update is needed (i.e. whether old and new entries
>>have meaningful differences)
>> 3) do update
>> 4) flush.
> 
> Your early comment suggest we only suppress the affinity related
> field. So the modification here is to handle the following case:
> 
> When the IRTE is currently in posted mode and this function tries
> to update it he remapped mode, then we need to suppress
> the affinity related bit, however, if the common fields (fpd, sid
> sq, svt) in the new remapped IRTE is different from the value
> in the old posted IRTE, what do you suggest we should do?
> Here I copy these fields to the new IRTE and update them
> accordingly.

You continue to look at this from what I think is the wrong angle:
msi_msg_to_remap_entry() should not make assumptions or
special case either of the formats. It should construct the new
entry (whichever format that's supposed to be) and compare
all relevant (for the given format) fields with those of the old
entry. If they all match, skip the flush.

>> > --- a/xen/drivers/passthrough/vtd/intremap.c
>> > +++ b/xen/drivers/passthrough/vtd/intremap.c
>> > @@ -547,6 +547,54 @@ static int remap_entry_to_msi_msg(
>> >  return 0;
>> >  }
>> >
>> > +static bool pi_can_suppress_irte_update(const struct iremap_entry *new,
>> > +const struct iremap_entry *old)
>> 
>> The two parameter declarations should be aligned with one another.
>> 
>> > +{
>> > +ASSERT( old && new );

Btw, stray blanks here (in case I didn't point this out before).

>> > +if ( !old->remap.p || !old->remap.im || !new->remap.p || 
>> > new->remap.im )
>> > +return false;
>> 
>> The asymmetry regarding the IM bit is confusing, and imo indicates
>> a problem with the logic.
> 
> Would you please share what the problem is here? If we get here, that means
> we are updating a posted IRTE to remapped one.

It's the assumption expressed by the second sentence of your reply
which is the problem: You're making an assumption here which you
shouldn't make - I don't see the caller guaranteeing that assumption,
and even if this one caller did, a function like the one here should be
generic enough so that future callers won't need to worry about
preconditions.

Jan


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

[Xen-devel] [distros-debian-wheezy test] 67985: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   67941

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] xc_hvm_inject_trap() races

[Razvan Cojocaru]

On 11/02/2016 11:30 AM, Jan Beulich wrote:
 On 02.11.16 at 10:11,  wrote:
>> On 11/02/2016 11:05 AM, Jan Beulich wrote:
>> On 02.11.16 at 09:57,  wrote:
 On 11/02/2016 10:49 AM, Jan Beulich wrote:
> The fact that {vmx,svm}_inject_trap() combine the new exception
> with an already injected one (and blindly discard events other than
> hw exceptions), otoh, looks like indeed wants to be controllable by
> the caller: When the event comes from the outside (the hypercall),
> it would clearly seem better to simply tell the caller that no injection
> happened and the event needs to be kept pending.

 However this is not possible with the current design, since all
 xc_hvm_inject_trap() really does is set the info to be used at
 hvm_do_resume() time. So at the time xc_hvm_inject_trap() returns, it's
 not yet possible to know if the injection will succeed or not (assuming
 we discard it when it would collide with another).
>>>
>>> That's my point - it shouldn't get discarded, but remain latched
>>> for a future invocation of hvm_do_resume(). Making
>>> hvm_inject_trap() have a suitable parameter (and a return value)
>>> would be the easy part of the change here. The difficult part would
>>> be to make sure the injection context is the right one.
>>
>> Should I then bring this patch back?
>>
>> https://lists.xen.org/archives/html/xen-devel/2014-07/msg02927.html 
>>
>> It has been rejected at the time on the grounds that
>> xc_hvm_inject_trap() is sufficient.
> 
> I don't think it would deal with all possible situations, the more
> that it's (already by its title) #PF specific. I think the named
> difficult part would need to be solved in the hypervisor alone,
> without further external information.

Found an earlier version of the patch, proposing to extend
HVMOP_inject_trap instead of a new libxc hypercall, which apparently got
so far as to have an "Acked-by" and a "Reviewed-by":

https://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01244.html

Is this one worth bringing back with the new information?


Thanks,
Razvan

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

Re: [Xen-devel] xc_hvm_inject_trap() races

[Jan Beulich]

>>> On 03.11.16 at 10:59,  wrote:
> Found an earlier version of the patch, proposing to extend
> HVMOP_inject_trap instead of a new libxc hypercall, which apparently got
> so far as to have an "Acked-by" and a "Reviewed-by":
> 
> https://lists.xenproject.org/archives/html/xen-devel/2014-09/msg01244.html 
> 
> Is this one worth bringing back with the new information?

Considering the discussion we had here, I'm not convinced. As said
before, I think the issue wants addressing in the hypervisor alone.

Jan


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

Re: [Xen-devel] [PATCH v3.1 03/15] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

[Roger Pau Monne]

On Wed, Nov 02, 2016 at 06:14:13PM +0100, Roger Pau Monne wrote:
> On Tue, Nov 01, 2016 at 10:45:05AM +, Tim Deegan wrote:
> > At 10:34 -0600 on 31 Oct (1477910088), Jan Beulich wrote:
> > > >>> On 29.10.16 at 10:59,  wrote:
> >   * the idle vcpu (e.g. during dom0 construction), check if there is
> >   * background work to be done that should interrupt this operation.
> >   */
> >  static inline bool general_preempt_check(void)
> >  {
> >  return unlikely(softirq_pending(smp_processor_id()) ||
> >  (!is_idle_vcpu(current) && 
> > local_events_need_delivery()));
> >  }
> >
> > If you're feeling keen, you could convert hypercall_preempt_check() to
> > an inline function and comment it too. :)
> 
> IMHO this is better, and I don't mind changing hypercall_preempt_check to an 
> inline function :).

So it turns out this is not trivial at all. Converting 
hypercall_preempt_check and also adding general_preempt_check as inline 
functions into shed.h causes trouble because they depend on 
local_events_need_delivery which in turn depends on the struct vcpu being 
defined. I could possibly move {general/hypercall}_preempt_check into 
xen/event.h and fixup the callers, but I would maybe prefer to leave this 
as-is for the time being, and add general_preempt_check as a macro.

Roger.

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

Re: [Xen-devel] [PATCH v3.1 03/15] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

[Tim Deegan]

At 11:20 +0100 on 03 Nov (1478172025), Roger Pau Monne wrote:
> On Wed, Nov 02, 2016 at 06:14:13PM +0100, Roger Pau Monne wrote:
> > On Tue, Nov 01, 2016 at 10:45:05AM +, Tim Deegan wrote:
> > > At 10:34 -0600 on 31 Oct (1477910088), Jan Beulich wrote:
> > > > >>> On 29.10.16 at 10:59,  wrote:
> > >   * the idle vcpu (e.g. during dom0 construction), check if there is
> > >   * background work to be done that should interrupt this operation.
> > >   */
> > >  static inline bool general_preempt_check(void)
> > >  {
> > >  return unlikely(softirq_pending(smp_processor_id()) ||
> > >  (!is_idle_vcpu(current) && 
> > > local_events_need_delivery()));
> > >  }
> > >
> > > If you're feeling keen, you could convert hypercall_preempt_check() to
> > > an inline function and comment it too. :)
> > 
> > IMHO this is better, and I don't mind changing hypercall_preempt_check to 
> > an 
> > inline function :).
> 
> So it turns out this is not trivial at all. Converting 
> hypercall_preempt_check and also adding general_preempt_check as inline 
> functions into shed.h causes trouble because they depend on 
> local_events_need_delivery which in turn depends on the struct vcpu being 
> defined. I could possibly move {general/hypercall}_preempt_check into 
> xen/event.h and fixup the callers, but I would maybe prefer to leave this 
> as-is for the time being, and add general_preempt_check as a macro.

Righto - that sounds fine to me.

Cheers,

Tim.

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

Re: [Xen-devel] Xen on Qualcomm

[Suresh Kanzariya]

Hi Sameer,

I have not build it yet, but before I started building and porting on 410
platform, I just want to make feasibility whether it is possible or not?,
Because as I said earlier Qualcomm uses its own hypervisor that is QHEE, so
just wanted to conform whether 2 hypervisor run simultaneous or not and if
not what are the possible changes are required in xen hypervisor to make it
run on 410 platform.

Also does anyone did it before as the earlier link i shared stats that Xen
crashes on Qualcomm platform, but I don't find any information about the
platform.

So It will be great if someone can spread more lights on this.

My specific questions are below.
1. does xen run on Qualcomm 410 platform? if not what are the reasons and
if it can run what are the possible changes are required?

It will be great if I get some more details on above questions so that I
don't go in wrong direction.

Thank You for your time in advance.

Regards,
Suresh

On Thu, 3 Nov 2016 at 14:35 Julien Grall  wrote:

> Hello Sameer,
>
> Please try to retain everyone in CC (or at least the author of the
> e-mail). Otherwise the answer may be delayed. I have added back Suresh.
>
> Regards,
>
> On 02/11/2016 20:37, Goel, Sameer wrote:
> >
> > Can you please post the error and details on Xen you are using?
> >
> > Thanks,
> > Sameer
> > On 11/2/2016 3:04 AM, Suresh Kanzariya wrote:
> >> Hi,
> >>
> >> I am trying to run Xen on Qualcomm 410 platform.
> >>
> >> I have come across below link
> >>
> https://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03144.html
> >>
> >>
> >> which suggest a patch to fix Xen crashes on Qualcomm Technology, So does
> >> anyone has any information on the post support which Qualcomm Platform?
> >>
> >> Thanks in advance.
> >>
> >> Regards,
> >> Suresh
> >>
> >>
> >>
> >>
> >> On Tue, 1 Nov 2016 at 11:48 Suresh Kanzariya  >> > wrote:
> >>
> >> Hi Julien,
> >>
> >> Thanks for the information. Let me get some more information on
> >> this, and I will get back to the mailing-list for further
> >> information.
> >>
> >> Thanks,
> >> Suresh
> >>
> >> On Mon, Oct 31, 2016 at 8:34 PM, Julien Grall  >> > wrote:
> >>
> >>
> >>
> >> On 31/10/16 14:59, Suresh Kanzariya wrote:
> >>
> >> Hi Julien,
> >>
> >>
> >> Hi,
> >>
> >> It seems that I forgot to add xen-devel on CC in my answer.
> >> Sorry for that.
> >>
> >> Thanks for the information.
> >>
> >> Just wanted to understand that Qualcomm boot itself
> >> contains a
> >> Hypervisor and also Xen is also a hypervisor, so I am not
> >> sure Xen
> >> hypervisor directly fits into the design, I guess Qualcomm
> >> hypervisor
> >> need modification or remove completely to support xen. It
> >> will be
> >> great if you can spread some light on this.
> >>
> >>
> >> Indeed 2 hypervisors cannot cooperate on the same processor. If
> >> Qualcomm provides any hypervisor, you would have to remove it.
> >>
> >> Although, I don't know much this platform, so I would recommend
> >> to contact Qualcomm for anything regarding that.
> >>
> >> Regards,
> >>
> >> --
> >> Julien Grall
> >>
> >>
> >> --
> >> Regards,
> >> Suresh
> >>
> >>
> >> ___
> >> Xen-devel mailing list
> >> Xen-devel@lists.xen.org
> >> https://lists.xen.org/xen-devel
> >>
> >
>
> --
> Julien Grall
>
-- 
Regards,
Suresh
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.8] x86/emul: Reject LGDT/LIDT attempts with non-canonical base addresses

[Wei Liu]

On Wed, Nov 02, 2016 at 09:42:33AM -0600, Jan Beulich wrote:
> >>> On 02.11.16 at 15:52,  wrote:
> > No sane OS would deliberately try this, but make Xen's emulation match real
> > hardware by delivering #GP(0), rather than suffering a VMEntry failure.
> > 
> > Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Jan Beulich 

Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86emul: {L, S}{G, I}DT ignore operand size overrides in 64-bit mode

[Wei Liu]

On Wed, Nov 02, 2016 at 05:42:53PM +, Andrew Cooper wrote:
> On 02/11/16 16:12, Jan Beulich wrote:
> > This affects not only the layout of the data (always 2+8 bytes), but
> > also the contents (no truncation to 24 bits occurs).
> >
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper , although
> wouldn't it be cleaner to set op_bytes = def_op_bytes, than to keep
> referring back to mode_64()?
> 

Release-acked-by: Wei Liu 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 414b198be9c2065efda01cf43f7c86e41a449b4b
baseline version:
 ovmf 756a514aa469c35e1a21c034a513630b7f02ecff

Last test of basis67984  2016-11-03 02:50:26 Z0 days
Testing same since67986  2016-11-03 08:48:41 Z0 days1 attempts


People who touched revisions under test:
  Bell Song 
  Liming Gao 
  Song, BinX 

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 414b198be9c2065efda01cf43f7c86e41a449b4b
Author: Song, BinX 
Date:   Wed Nov 2 10:11:55 2016 +0800

MdeModulePkg/FrameBufferBltLib: Change module type to UEFI_DRIVER

- BASE -> UEFI_DRIVER
- https://bugzilla.tianocore.org/show_bug.cgi?id=173

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bell Song 
Reviewed-by: Liming Gao 

commit 9cc42a92428bb3a2eaea7789b1e34a68c29223b8
Author: Song, BinX 
Date:   Wed Nov 2 10:09:26 2016 +0800

EdkCompatibilityPkg/PrintLite: Fix ErrorPrint() wrong NULL char check

- '\0' -> NULL
- https://bugzilla.tianocore.org/show_bug.cgi?id=47

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bell Song 
Reviewed-by: Liming Gao 

commit b782753fa24229d3b677c6fd5ad5594028d14a8b
Author: Liming Gao 
Date:   Mon Oct 31 13:27:19 2016 +0800

UefiCpuPkg PeiCpuExceptionHandlerLib: Add the missing nasm files in INF

All CpuExceptionHandlerLib library instances use nasm source files.

Cc: Reviewed-by: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Jeff Fan 

commit 00f5e11913a8706a1733da2b591502d59f848a99
Author: Liming Gao 
Date:   Thu Oct 27 14:54:27 2016 +0800

IntelFrameworkModulePkg LzmaDecompressLib: Update LZMA to new 16.04 version

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 

commit 1e230224d412d763b98472a8cd92a8349afba99b
Author: Liming Gao 
Date:   Thu Oct 27 14:08:39 2016 +0800

MdeModulePkg LzmaDecompressLib: Update LZMA to new 16.04 version

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 

commit c4ab09ef2f543ebf420da5d7cd8d48988c99b89c
Author: Liming Gao 
Date:   Thu Oct 27 14:50:54 2016 +0800

BaseTools LzmaCompress: Update LZMA to new 16.04 version

New version LZMA SDK improves the compression performance on windows OS,
and has no change on the compression ratio. I compress 8M FVMAIN image,
the compression time is reduced from 2.590s to 1.419s.

Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao 
Reviewed-by: Yonghong Zhu 

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

Re: [Xen-devel] [PATCH v3.1 07/15] xen/x86: do the PCI scan unconditionally

[Roger Pau Monne]

On Mon, Oct 31, 2016 at 10:47:15AM -0600, Jan Beulich wrote:
> >>> On 29.10.16 at 10:59,  wrote:
> > --- a/xen/arch/x86/setup.c
> > +++ b/xen/arch/x86/setup.c
> > @@ -1491,6 +1491,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> >  
> >  early_msi_init();
> >  
> > +scan_pci_devices();
> > +
> >  iommu_setup();/* setup iommu if available */
> >  
> >  smp_prepare_cpus(max_cpus);
> > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
> > @@ -219,7 +219,8 @@ int __init amd_iov_detect(void)
> >  
> >  if ( !amd_iommu_perdev_intremap )
> >  printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table 
> > is not recommended (see XSA-36)!\n");
> > -return scan_pci_devices();
> > +
> > +return 0;
> >  }
> 
> I'm relatively certain that I did point out on a prior version that the
> error handling here gets lost. At the very least the commit message
> should provide a reason for doing so; even better would be if there
> was no behavioral change (other than the point in time where this
> happens slightly changing).

Behaviour here is different on Intel or AMD hardware, on Intel failure to 
scan the PCI bus will not be fatal, and the IOMMU will be enabled anyway. On 
AMD OTOH failure to scan the PCI bus will cause the IOMMU to be disabled. 
I expect we should be able to behave equally for both Intel and AMD, so 
which one should be used?

Roger.

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

Re: [Xen-devel] [PATCH v3] features: declare the Credit2 scheduler as Supported.

[Wei Liu]

Fixed one typo, removed period in subject line and pushed.

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

Re: [Xen-devel] [PATCH for-4.8] libxl: disallow enabling PoD and ALTP2M at the same time

[Wei Liu]

On Wed, Nov 02, 2016 at 02:51:41PM +, Wei Liu wrote:
> On Wed, Nov 02, 2016 at 02:43:58PM +, Ian Jackson wrote:
> > Wei Liu writes ("[PATCH for-4.8] libxl: disallow enabling PoD and ALTP2M at 
> > the same time"):
> > > That combination would cause Xen to crash. Note that this is not a
> > > security issue because ALTP2M is experimental.
> > 
> > Acked-by: Ian Jackson 
> > 
> > You mean, though
> > 
> >   Note that although this is a security issue, is not an XSA-worthy
> >   because ALTP2M is experimental.
> 

Updated commit message and applied.

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

Re: [Xen-devel] [PATCH v2] build: make debug option affect tools only

[Wei Liu]

On Wed, Nov 02, 2016 at 10:13:28AM +, Wei Liu wrote:
> On Wed, Nov 02, 2016 at 02:53:32AM -0600, Jan Beulich wrote:
> > >>> On 01.11.16 at 20:22,  wrote:
> > > The debug option in Config.mk affects hypervisor, tools and stubdom by
> > > appending different flags to CFLAGS.  Mini-os under extra is not
> > > affected because it already has its own build system when it is
> > > separated from xen.git.
> > > 
> > > It is undesirable because now hypervisor build is affected by both
> > > Kconfig and debug.
> > > 
> > > Disentangle the semantics of debug by pushing relevant options to
> > > individual sub-systems.
> > > 
> > > For hypervisor, the flags previously added by debug option is now
> > > controlled by CONFIG_DEBUG.
> > > 
> > > For tools, flags are moved from config/*.mk into tools/Rules.mk.
> > > 
> > > For stubdom, because it unilaterally sets debug=y before including
> > > top-level Config.mk, we only need to move the debug build set of flags
> > > into stubdom Makefile.
> > > 
> > > Specifically there are some considerations on what flags are picked:
> > > 
> > > 1. we don't need -fno-optimize-sibling-calls anymore because gcc doc
> > >indicates that it is not enabled for -O1, which we already set in the
> > >debug build.
> > > 2. for tools we use -O0 -g3 in Rules.mk because they already take
> > >precedence over the flags set in config/*.mk.
> > > 3. for hypervisor we don't add -fno-omit-frame-pointer to debug build
> > >because that's controlled by CONFIG_FRAME_POINTER.
> > > 
> > > This patch doesn't intend to tune those flags, but to provide identical
> > > set of effective flags as before.  The debug option in Config.mk will
> > > only affect tools components after this patch is applied.
> > > 
> > > Signed-off-by: Wei Liu 
> > 
> > Acked-by: Jan Beulich 
> > 
> 
> Thanks.
> 
> I will push this patch along with the two other earlier patches after my
> OSSTest patch lands on production. Please speak up if anyone thinks
> that's a bad idea.
> 

My osstest patch landed last night, so I've now pushed this patch and
the other two.

Wei.

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

Re: [Xen-devel] [PATCH] x86emul: {L, S}{G, I}DT ignore operand size overrides in 64-bit mode

[Andrew Cooper]

On 03/11/16 08:06, Jan Beulich wrote:
 On 02.11.16 at 18:42,  wrote:
>> On 02/11/16 16:12, Jan Beulich wrote:
>>> This affects not only the layout of the data (always 2+8 bytes), but
>>> also the contents (no truncation to 24 bits occurs).
>>>
>>> Signed-off-by: Jan Beulich 
>> Reviewed-by: Andrew Cooper , although
>> wouldn't it be cleaner to set op_bytes = def_op_bytes, than to keep
>> referring back to mode_64()?
> That would still mean
>
> if ( mode_64bit() )
> op_bytes = def_op_bytes;

Oh true.

>
> and wouldn't eliminate the uses in the second ops->write() /
> read_ulong() either.
>
> What we could do in the S{G,I}DT case is
>
> if ( mode_64bit() )
> op_bytes = 8;
> else if ( op_bytes == 2 )
> {
> sreg.base &= 0xff;
> op_bytes = 4;
> }
> if ( (rc = ops->write(ea.mem.seg, ea.mem.off+0,
>   &sreg.limit, 2, ctxt)) ||
>  (rc = ops->write(ea.mem.seg, ea.mem.off+2,
>   &sreg.base, op_bytes, ctxt)) )
>
> But the same can't be done in the L{G,I}DT case. Let me know.

This does look a little cleaner, even if it is only for the sgdt/sidt case.

~Andrew


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

[Xen-devel] [PATCH for-4.8] docs: fixup PVHv2 documentation regarding AP startup

[Roger Pau Monne]

On PVHv2 guests the local APIC can also be used to start APs if present.
Amend the documentation in order to reflect this.

Signed-off-by: Roger Pau Monné 
---
Cc: boris.ostrov...@oracle.com
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 docs/misc/hvmlite.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 69d90fe..09051ee 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -49,8 +49,8 @@ as HVM guests, using the hypervisor cpuid leaves and msr 
ranges.
 
 ## AP startup ##
 
-AP startup is performed using hypercalls. The following VCPU operations
-are used in order to bring up secondary vCPUs:
+AP startup can be performed using hypercalls or the local APIC if present.
+The following VCPU hypercalls can be used in order to bring up secondary vCPUs:
 
  * `VCPUOP_initialise` is used to set the initial state of the vCPU. The
argument passed to the hypercall must be of the type vcpu_hvm_context.
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [RFC] Shared coprocessor framework

[Andrii Anisov]

Dear All,

Would you please come up with more comments, ideas or blames on the topic?

Sincerely,
Andrii Anisov.

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

Re: [Xen-devel] [PATCH v3.1 03/15] xen/x86: allow calling {sh/hap}_set_allocation with the idle domain

[Jan Beulich]

>>> On 03.11.16 at 11:20,  wrote:
> On Wed, Nov 02, 2016 at 06:14:13PM +0100, Roger Pau Monne wrote:
>> On Tue, Nov 01, 2016 at 10:45:05AM +, Tim Deegan wrote:
>> > At 10:34 -0600 on 31 Oct (1477910088), Jan Beulich wrote:
>> > > >>> On 29.10.16 at 10:59,  wrote:
>> >   * the idle vcpu (e.g. during dom0 construction), check if there is
>> >   * background work to be done that should interrupt this operation.
>> >   */
>> >  static inline bool general_preempt_check(void)
>> >  {
>> >  return unlikely(softirq_pending(smp_processor_id()) ||
>> >  (!is_idle_vcpu(current) && 
>> > local_events_need_delivery()));
>> >  }
>> >
>> > If you're feeling keen, you could convert hypercall_preempt_check() to
>> > an inline function and comment it too. :)
>> 
>> IMHO this is better, and I don't mind changing hypercall_preempt_check to an 
>> inline function :).
> 
> So it turns out this is not trivial at all. Converting 
> hypercall_preempt_check and also adding general_preempt_check as inline 
> functions into shed.h causes trouble because they depend on 
> local_events_need_delivery which in turn depends on the struct vcpu being 
> defined. I could possibly move {general/hypercall}_preempt_check into 
> xen/event.h and fixup the callers, but I would maybe prefer to leave this 
> as-is for the time being, and add general_preempt_check as a macro.

Fine with me.

Jan


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

Re: [Xen-devel] [PATCH v3.1 07/15] xen/x86: do the PCI scan unconditionally

[Jan Beulich]

>>> On 03.11.16 at 11:58,  wrote:
> On Mon, Oct 31, 2016 at 10:47:15AM -0600, Jan Beulich wrote:
>> >>> On 29.10.16 at 10:59,  wrote:
>> > --- a/xen/arch/x86/setup.c
>> > +++ b/xen/arch/x86/setup.c
>> > @@ -1491,6 +1491,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>> >  
>> >  early_msi_init();
>> >  
>> > +scan_pci_devices();
>> > +
>> >  iommu_setup();/* setup iommu if available */
>> >  
>> >  smp_prepare_cpus(max_cpus);
>> > --- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> > +++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
>> > @@ -219,7 +219,8 @@ int __init amd_iov_detect(void)
>> >  
>> >  if ( !amd_iommu_perdev_intremap )
>> >  printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table 
>> > is not recommended (see XSA-36)!\n");
>> > -return scan_pci_devices();
>> > +
>> > +return 0;
>> >  }
>> 
>> I'm relatively certain that I did point out on a prior version that the
>> error handling here gets lost. At the very least the commit message
>> should provide a reason for doing so; even better would be if there
>> was no behavioral change (other than the point in time where this
>> happens slightly changing).
> 
> Behaviour here is different on Intel or AMD hardware, on Intel failure to 
> scan the PCI bus will not be fatal, and the IOMMU will be enabled anyway. On 
> AMD OTOH failure to scan the PCI bus will cause the IOMMU to be disabled. 
> I expect we should be able to behave equally for both Intel and AMD, so 
> which one should be used?

I'm afraid I have to defer to the vendor IOMMU maintainers for
that one, as I don't know the reason for the difference in behavior.
An aspect that may play into here is that for AMD the IOMMU is
represented by a PCI device, while for Intel it's just a part of one
of the core chipset devices.

Jan


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

Re: [Xen-devel] [PATCH for-4.8] docs: fixup PVHv2 documentation regarding AP startup

[Jan Beulich]

>>> On 03.11.16 at 12:29,  wrote:
> On PVHv2 guests the local APIC can also be used to start APs if present.
> Amend the documentation in order to reflect this.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH v3.1 07/15] xen/x86: do the PCI scan unconditionally

[Boris Ostrovsky]

On 11/03/2016 07:35 AM, Jan Beulich wrote:

On 03.11.16 at 11:58,  wrote:

On Mon, Oct 31, 2016 at 10:47:15AM -0600, Jan Beulich wrote:

On 29.10.16 at 10:59,  wrote:

--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1491,6 +1491,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)

 early_msi_init();

+scan_pci_devices();
+
 iommu_setup();/* setup iommu if available */

 smp_prepare_cpus(max_cpus);
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -219,7 +219,8 @@ int __init amd_iov_detect(void)

 if ( !amd_iommu_perdev_intremap )
 printk(XENLOG_WARNING "AMD-Vi: Using global interrupt remap table is not 
recommended (see XSA-36)!\n");
-return scan_pci_devices();
+
+return 0;
 }


I'm relatively certain that I did point out on a prior version that the
error handling here gets lost. At the very least the commit message
should provide a reason for doing so; even better would be if there
was no behavioral change (other than the point in time where this
happens slightly changing).


Behaviour here is different on Intel or AMD hardware, on Intel failure to
scan the PCI bus will not be fatal, and the IOMMU will be enabled anyway. On
AMD OTOH failure to scan the PCI bus will cause the IOMMU to be disabled.
I expect we should be able to behave equally for both Intel and AMD, so
which one should be used?


I'm afraid I have to defer to the vendor IOMMU maintainers for
that one, as I don't know the reason for the difference in behavior.
An aspect that may play into here is that for AMD the IOMMU is
represented by a PCI device, while for Intel it's just a part of one
of the core chipset devices.


That's probably the reason although it looks like the only failure that 
scan_pci_devices() can return is -ENOMEM, in which case disabling IOMMU 
may not be the biggest problem.


-boris

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

[Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[Roger Pau Monne]

It is possible for PVHv2 guests to get the hardware description from ACPI
tables, add this to the documentation also.

Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Boris Ostrovsky 
Cc: Konrad Rzeszutek Wilk 
---
 docs/misc/hvmlite.markdown | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 09051ee..946908e 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -64,3 +64,14 @@ The following VCPU hypercalls can be used in order to bring 
up secondary vCPUs:
  * `VCPUOP_down` is used to bring down a vCPU.
 
  * `VCPUOP_is_up` is used to scan the number of available vCPUs.
+
+## Hardware description ##
+
+PVHv2 guests that have access to hardware (either emulated or real) will also
+have ACPI tables with the description of the hardware that's available to the
+guest. This applies to both privileged and unprivileged guests. A hint of
+the position of the RSDP in memory (if present) can be fetched from the start
+info structure that's passed at boot time (field rsdp_paddr).
+
+Description of paravirtualized devices will come from XenStore, just as it's
+done for HVM guests.
-- 
2.7.4 (Apple Git-66)


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

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[Andrew Cooper]

On 03/11/16 12:19, Roger Pau Monne wrote:
> It is possible for PVHv2 guests to get the hardware description from ACPI
> tables, add this to the documentation also.
>
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne]

On Mon, Oct 31, 2016 at 10:32:47AM -0600, Jan Beulich wrote:
> >>> On 29.10.16 at 10:59,  wrote:
> > PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
> > from physical or emulated devices over event channels using PIRQs. This
> > applies to both DomU and Dom0 PVHv2 guests.
> > 
> > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
> > route physical interrupts (even from emulated devices) over event channels,
> > and is thus allowed to use some of the PHYSDEV ops.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> The patch looks fine now for its purpose, but I'm hesitant to ack it
> without us having settled on whether we indeed mean to hide all
> those physdev ops from Dom0. In particular I don't recall this (and
> the reasoning behind it) having got written down somewhere.

I'm planning to add the following doc update together with this commit:

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 946908e..4fc757f 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -75,3 +75,38 @@ info structure that's passed at boot time (field rsdp_paddr).
 
 Description of paravirtualized devices will come from XenStore, just as it's
 done for HVM guests.
+
+## Interrupts ##
+
+### Interrupts from physical devices ###
+
+Interrupts from physical devices are delivered using native methods, this is
+done in order to take advantage of new hardware assisted virtualization
+functions, like posted interrupts. This implies that PVHv2 guests with physical
+devices will also have the necessary interrupt controllers in order to manage
+the delivery of interrupts from those devices, using the same interfaces that
+are available on native hardware.
+
+### Interrupts from paravirtualized devices ###
+
+Interrupts from paravirtualized devices are delivered using event channels, see
+[Event Channel Internals][event_channels] for more detailed information about
+event channels. In order to inject interrupts into the guest an IDT vector is
+used. This is the same mechanism used on PVHVM guests, and allows having
+per-cpu interrupts that can be also used to deliver timers or IPIs if desired.
+
+In order to register the callback IDT vector the `HVMOP_set_param` hypercall
+is used with the following values:
+
+domid = DOMID_SELF
+index = HVM_PARAM_CALLBACK_IRQ
+value = (0x2 << 56) | vector_value
+
+The OS has to program the IDT for the `vector_value` using the baremetal
+mechanism.
+
+In order to know which event channel has fired, we need to look into the
+information provided in the `shared_info` structure. The `evtchn_pending`
+array is used as a bitmap in order to find out which event channel has
+fired. Event channels can also be masked by setting it's port value in the
+`shared_info->evtchn_mask` bitmap.


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

Re: [Xen-devel] [PATCH for-4.8] docs: fixup PVHv2 documentation regarding AP startup

[Wei Liu]

On Thu, Nov 03, 2016 at 05:37:22AM -0600, Jan Beulich wrote:
> >>> On 03.11.16 at 12:29,  wrote:
> > On PVHv2 guests the local APIC can also be used to start APs if present.
> > Amend the documentation in order to reflect this.
> > 
> > Signed-off-by: Roger Pau Monné 
> 
> Acked-by: Jan Beulich 

Applied

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

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[Wei Liu]

On Thu, Nov 03, 2016 at 12:22:57PM +, Andrew Cooper wrote:
> On 03/11/16 12:19, Roger Pau Monne wrote:
> > It is possible for PVHv2 guests to get the hardware description from ACPI
> > tables, add this to the documentation also.
> >
> > Signed-off-by: Roger Pau Monné 
> 
> Reviewed-by: Andrew Cooper 

Applied.

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

[Xen-devel] Xen Solaris support still required?

[Juergen Gross]

Xen tools contain several sources specific to Solaris, e.g. in
libxc, xenstored, xenstat, some other libs.

Is this still required? If yes, all of it?

Google tells me Oracle has dropped XVM support on Solaris.
Openindiana seems to have replaced XVM by a KVM port.


Juergen

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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Jan Beulich]

>>> On 03.11.16 at 13:35,  wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,38 @@ info structure that's passed at boot time (field 
> rsdp_paddr).
>  
>  Description of paravirtualized devices will come from XenStore, just as it's
>  done for HVM guests.
> +
> +## Interrupts ##
> +
> +### Interrupts from physical devices ###
> +
> +Interrupts from physical devices are delivered using native methods, this is
> +done in order to take advantage of new hardware assisted virtualization
> +functions, like posted interrupts.

Okay, that's a reason for this to be optional (iirc AMD doesn't
have posted interrupts so far), not for all the physdev ops being
made not work at all. The more that I think I did point out before
that there is at least one case where interrupt delivery info
needs to be made available to Xen despite Dom0 not setting up
an IO-APIC entry, and hence a physdev op is the only way to
communicate that information.

Jan


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

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[Jan Beulich]

>>> On 03.11.16 at 13:19,  wrote:
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -64,3 +64,14 @@ The following VCPU hypercalls can be used in order to 
> bring up secondary vCPUs:
>   * `VCPUOP_down` is used to bring down a vCPU.
>  
>   * `VCPUOP_is_up` is used to scan the number of available vCPUs.
> +
> +## Hardware description ##
> +
> +PVHv2 guests that have access to hardware (either emulated or real) will also
> +have ACPI tables with the description of the hardware that's available to the
> +guest. This applies to both privileged and unprivileged guests. A hint of
> +the position of the RSDP in memory (if present) can be fetched from the start
> +info structure that's passed at boot time (field rsdp_paddr).

Why "hint"?

Jan


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

Re: [Xen-devel] Xen Solaris support still required?

[Konrad Rzeszutek Wilk]

On Nov 3, 2016 8:49 AM, Juergen Gross  wrote:
>
> Xen tools contain several sources specific to Solaris, e.g. in
> libxc, xenstored, xenstat, some other libs.
>
> Is this still required? If yes, all of it?
>
Could we wait with the answer to say until beginning of 2017?
> Google tells me Oracle has dropped XVM support on Solaris.
Correct.
Albeit Solaria does work under Xen with PV drivers (as an HVM guest).
> Openindiana seems to have replaced XVM by a KVM port.
>
>
> Juergen
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] PCMachineState: introduce acpi_build_enabled field

[Eduardo Habkost]

On Tue, Nov 01, 2016 at 03:30:59PM -0700, Stefano Stabellini wrote:
> On Tue, 1 Nov 2016, Eduardo Habkost wrote:
> > On Tue, Nov 01, 2016 at 05:44:16PM +, Wei Liu wrote:
> > > Introduce this field to control whether ACPI build is enabled by a
> > > particular machine or accelerator.
> > > 
> > > It defaults to true if the machine itself supports ACPI build. Xen
> > > accelerator will disable it because Xen is in charge of building ACPI
> > > tables for the guest.
> > > 
> > > Signed-off-by: Wei Liu 
> > 
> > Reviewed-by: Eduardo Habkost 
> 
> Thank you Eduardo. I can queue it up unless you have other stuff in
> progress.

In case you didn't queue it yet, please go ahead.

Acked-by: Eduardo Habkost 

-- 
Eduardo

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

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

[Jan Beulich]

>>> On 03.11.16 at 13:14,  wrote:
> Jan,
> A backport ' c/s 22135 ' was mentioned in above link.  Does it refer to 
> https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&package=
>  
> xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=5 ??

Judging from the name, I guess so. But this has been ages ago.

Jan


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

Re: [Xen-devel] Xen Solaris support still required?

[Juergen Gross]

On 03/11/16 14:13, Konrad Rzeszutek Wilk wrote:
> On Nov 3, 2016 8:49 AM, Juergen Gross  wrote:
>>
>> Xen tools contain several sources specific to Solaris, e.g. in
>> libxc, xenstored, xenstat, some other libs.
>>
>> Is this still required? If yes, all of it?
>>
> 
> Could we wait with the answer to say until beginning of 2017?

Okay. Makes me suspicious, though. :-)

>> Google tells me Oracle has dropped XVM support on Solaris.
> 
> Correct.
> 
> Albeit Solaria does work under Xen with PV drivers (as an HVM guest).

Sure. But this shouldn't need Xen tools to be built for Solaris, right?


Juergen

> 
>> Openindiana seems to have replaced XVM by a KVM port.
>>
>>
>> Juergen
> 


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

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

[Xuquan (Quan Xu)]

On November 03, 2016 9:18 PM, < jbeul...@suse.com > wrote:
 On 03.11.16 at 13:14,  wrote:
>> Jan,
>> A backport ' c/s 22135 ' was mentioned in above link.  Does it refer
>> to
>https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&pack
>age=
>> xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=5 ??
>
>Judging from the name, I guess so. But this has been ages ago.
>

Thanks. btw, if you still recall, could you share how to fix this BUG_ON? 

 Yes, It is really ages ago, thanks again.

Quan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e9d0933d45e51027836f570427141fd2e3a7dfbd
baseline version:
 ovmf 414b198be9c2065efda01cf43f7c86e41a449b4b

Last test of basis   101866  2016-11-03 02:44:09 Z0 days
Testing same since   101872  2016-11-03 06:22:51 Z0 days1 attempts


People who touched revisions under test:
  Cinnamon Shia 
  Jiewen Yao 

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=e9d0933d45e51027836f570427141fd2e3a7dfbd
+ . ./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 
e9d0933d45e51027836f570427141fd2e3a7dfbd
+ branch=ovmf
+ revision=e9d0933d45e51027836f570427141fd2e3a7dfbd
+ . ./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
+ '[' xe9d0933d45e51027836f570427141fd2e3a7dfbd = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/

[Xen-devel] [PATCH v2] x86emul: {L, S}{G, I}DT ignore operand size overrides in 64-bit mode

[Jan Beulich]

This affects not only the layout of the data (always 2+8 bytes), but
also the contents (no truncation to 24 bits occurs).

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4424,12 +4424,17 @@ x86_emulate(
 fail_if(ops->read_segment == NULL);
 if ( (rc = ops->read_segment(seg, &sreg, ctxt)) )
 goto done;
-if ( op_bytes == 2 )
+if ( mode_64bit() )
+op_bytes = 8;
+else if ( op_bytes == 2 )
+{
 sreg.base &= 0xff;
-if ( (rc = ops->write(ea.mem.seg, ea.mem.off+0,
-  &sreg.limit, 2, ctxt)) ||
- (rc = ops->write(ea.mem.seg, ea.mem.off+2,
-  &sreg.base, mode_64bit() ? 8 : 4, ctxt)) )
+op_bytes = 4;
+}
+if ( (rc = ops->write(ea.mem.seg, ea.mem.off, &sreg.limit,
+  2, ctxt)) != X86EMUL_OKAY ||
+ (rc = ops->write(ea.mem.seg, ea.mem.off + 2, &sreg.base,
+  op_bytes, ctxt)) != X86EMUL_OKAY )
 goto done;
 break;
 case 2: /* lgdt */
@@ -4446,7 +4451,7 @@ x86_emulate(
 generate_exception_if(!is_canonical_address(base), EXC_GP, 0);
 sreg.base = base;
 sreg.limit = limit;
-if ( op_bytes == 2 )
+if ( !mode_64bit() && op_bytes == 2 )
 sreg.base &= 0xff;
 if ( (rc = ops->write_segment(seg, &sreg, ctxt)) )
 goto done;



x86emul: {L,S}{G,I}DT ignore operand size overrides in 64-bit mode

This affects not only the layout of the data (always 2+8 bytes), but
also the contents (no truncation to 24 bits occurs).

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4424,12 +4424,17 @@ x86_emulate(
 fail_if(ops->read_segment == NULL);
 if ( (rc = ops->read_segment(seg, &sreg, ctxt)) )
 goto done;
-if ( op_bytes == 2 )
+if ( mode_64bit() )
+op_bytes = 8;
+else if ( op_bytes == 2 )
+{
 sreg.base &= 0xff;
-if ( (rc = ops->write(ea.mem.seg, ea.mem.off+0,
-  &sreg.limit, 2, ctxt)) ||
- (rc = ops->write(ea.mem.seg, ea.mem.off+2,
-  &sreg.base, mode_64bit() ? 8 : 4, ctxt)) )
+op_bytes = 4;
+}
+if ( (rc = ops->write(ea.mem.seg, ea.mem.off, &sreg.limit,
+  2, ctxt)) != X86EMUL_OKAY ||
+ (rc = ops->write(ea.mem.seg, ea.mem.off + 2, &sreg.base,
+  op_bytes, ctxt)) != X86EMUL_OKAY )
 goto done;
 break;
 case 2: /* lgdt */
@@ -4446,7 +4451,7 @@ x86_emulate(
 generate_exception_if(!is_canonical_address(base), EXC_GP, 0);
 sreg.base = base;
 sreg.limit = limit;
-if ( op_bytes == 2 )
+if ( !mode_64bit() && op_bytes == 2 )
 sreg.base &= 0xff;
 if ( (rc = ops->write_segment(seg, &sreg, ctxt)) )
 goto done;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] qeustion: a panic in __do_update_va_mapping()

[Jan Beulich]

>>> On 03.11.16 at 14:27,  wrote:
> On November 03, 2016 9:18 PM, < jbeul...@suse.com > wrote:
> On 03.11.16 at 13:14,  wrote:
>>> Jan,
>>> A backport ' c/s 22135 ' was mentioned in above link.  Does it refer
>>> to
>>https://build.opensuse.org/package/view_file?file=22135-heap-lock.patch&pack 
>>age=
>>> xen&project=home%3Acharlesa%3AopenSUSE11.3&rev=5 ??
>>
>>Judging from the name, I guess so. But this has been ages ago.
>>
> 
> Thanks. btw, if you still recall, could you share how to fix this BUG_ON? 

Well, you did find the fix for the issue back then; yours then is
a different one pretty certainly.

Jan


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

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Daniel Kiper]

On Mon, Oct 24, 2016 at 03:57:22AM -0600, Jan Beulich wrote:
> >>> On 24.10.16 at 11:03,  wrote:

[...]

> > It looks that it is last thing which blocks whole patch series.
>
> I don't think so - Andrew has (not via mail) already indicated he'd
> like to comment on the not insignificant amount of assembly code
> getting added, some of which presumably could (and hence should)
> better be done in C. I've specifically avoided so far to respond with
> any R-b or ack on the two main (in this regard) patches.

Andrew, ping? Could you send me your comments?

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs. 
101834

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  ff53c65311a32e54dba51f2b8112632e9dd2af3b
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101834  2016-10-31 22:10:29 Z2 days
Testing same since   101884  2016-11-03 12:02:50 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  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 fail
 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 ff53c65311a32e54dba51f2b8112632e9dd2af3b
Author: Wei Liu 
Date:   Wed Nov 2 14:10:37 2016 +

libxl: disallow enabling PoD and ALTP2M at the same time

That combination would cause Xen to crash.

Note that although this is a security issue, is not XSA-worthy because
ALTP2M is experimental.

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

commit 3c79495579adddee535c2b7f8c332e4517764a0e
Author: Dario Faggioli 
Date:   Wed Nov 2 16:05:03 2016 +0100

features: declare the Credit2 scheduler as Supported

Credit2 is available in tree as an "Experimental" scheduler since
a few years. Recently, effort started for making it production ready
and, eventually, the new Xen's default scheduler. As a consequence of
that, it has undergone a great deal of development, testing and
benchmarking.

In fact, Credit2's much more modern (wrt Credit1) design and cleaner
code makes it a lot easier to understand what the scheduler is doing,
fix scheduling issues that may come up, and implement new and more
advanced features, in future.

In some more details:

 - key features that were missing (pinning and context switching
   rate-limiting) have now been implemented, and more (soft affinity,
   caps and reservations) are about to come. The gap wrt Credit1 is
   therefore closing. In particular, with pinning and rate-limiting
   available, the scheduler can be considered usable.

 - Credit2 is tested by OSSTest since long time. Furthermore, as a
   part of recent efforts, stress tests and benchmarks have been run
   and shown no bugs or stability issues.

 - A number of different benchmarks have been run, most of them
   comparing Credit2 with Credit1. Some of the results were posted on
   xen-devel, some others have been illustrated during a talk at 2016
   edition of Xen-Project Developer Summit. In general, performance
   look promising --if not better than Credit1 already, in some of
   the cases.

It therefore appears that we are ready to mark the Credit2 scheduler
as a 'Supported' feature, and ask users to look at it and try it, if
they think it suits their needs.

Of course, declaring something 'Supported' has security implications.
So here it is how the situation looks like from a security standpoint:

1) Is guest->host privilege escalation possible?

The only interfaces exposed to unprivileged guests are the SCHEDOP
hypercalls, and timers. None of those hypercalls contain any pointers,
and they don't look to contain any privilege escalation path. Also,
they're not specific to Credit2, as they're "used" by all schedulers
(ingludin

[Xen-devel] Libvirt build broken

[Wei Liu]

Hi

Xen Project's CI system found a build failure between libvirt changes
06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.

The build log can be found at:

http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log

The first error:

  CC   libvirt_driver_la-libvirt-host.lo
libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
incomplete type
 static struct gcry_thread_cbs virTLSThreadImpl = {
   ^
Earlier in configure:

  configure: gnutls: no 

From the look of it configure doesn't work properly anymore.


Wei.

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

Re: [Xen-devel] Xen Solaris support still required? Illumos Xen

[Pasi Kärkkäinen]

On Thu, Nov 03, 2016 at 01:49:07PM +0100, Juergen Gross wrote:
> Xen tools contain several sources specific to Solaris, e.g. in
> libxc, xenstored, xenstat, some other libs.
> 
> Is this still required? If yes, all of it?
> 
> Google tells me Oracle has dropped XVM support on Solaris.
> Openindiana seems to have replaced XVM by a KVM port.
> 

In 2014 there was some work being done by Igor Kozhukhov (CC'd) to get Illumos 
(Opensolaris) Xen support improved / working..

Illumos Xen 4.3 port status:
https://lists.xenproject.org/archives/html/xen-devel/2014-01/msg02240.html

Illumos Xen dom0:
https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg00146.html

Illumos PV domU support:
https://lists.xenproject.org/archives/html/xen-devel/2014-02/msg01160.html

Let's hope Igor can comment if he's still working on Illumos Xen stuff.. 


-- Pasi


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

Re: [Xen-devel] Xen Solaris support still required?

[Konrad Rzeszutek Wilk]

On Thu, Nov 03, 2016 at 02:21:42PM +0100, Juergen Gross wrote:
> On 03/11/16 14:13, Konrad Rzeszutek Wilk wrote:
> > On Nov 3, 2016 8:49 AM, Juergen Gross  wrote:
> >>
> >> Xen tools contain several sources specific to Solaris, e.g. in
> >> libxc, xenstored, xenstat, some other libs.
> >>
> >> Is this still required? If yes, all of it?
> >>
> > 
> > Could we wait with the answer to say until beginning of 2017?
> 
> Okay. Makes me suspicious, though. :-)

I am just swamped so giving myself some time to answer.
> 
> >> Google tells me Oracle has dropped XVM support on Solaris.
> > 
> > Correct.
> > 
> > Albeit Solaria does work under Xen with PV drivers (as an HVM guest).
> 
> Sure. But this shouldn't need Xen tools to be built for Solaris, right?

That I am not sure. I know we have some services that use libxenstore
inside of the guests (domU). And those services I believe could also
be compiled under Solaris (domU) guest. I need to verify that.
> 
> 
> Juergen
> 
> > 
> >> Openindiana seems to have replaced XVM by a KVM port.
> >>
> >>
> >> Juergen
> > 
> 

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

Re: [Xen-devel] [libvirt] Libvirt build broken

[Martin Kletzander]

On Thu, Nov 03, 2016 at 01:50:17PM +, Wei Liu wrote:

Hi

Xen Project's CI system found a build failure between libvirt changes
06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.



My guess is either 680d2f49dad425395de627a31006cb84848cfa65 or
0c62ccf927c60c9c248db52a23670ec2f9bce2b2 as those are the two that touch
gnutls configure stuff.


The build log can be found at:

http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log

The first error:

 CC   libvirt_driver_la-libvirt-host.lo
libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
incomplete type
static struct gcry_thread_cbs virTLSThreadImpl = {
  ^
Earlier in configure:

 configure: gnutls: no


From the look of it configure doesn't work properly anymore.




There are two problems here.  One is that you probably have old gnutls
(older than 2.2.0, for more info check the two commits).  That's why you
are not building with gnutls, but the real problem here (which is in the
code) is that we are not able to build without gnutls (my quick guess).
We are using struct gcry_thread_cbs even when building without gnutls
and that's what should be fixed, IMHO.



Wei.

--
libvir-list mailing list
libvir-l...@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


signature.asc
Description: Digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64

[Daniel Kiper]

On Fri, Feb 19, 2016 at 04:28:52PM +, Julien Grall wrote:
> Xen is currently crashing because of malformed compatible property for
> the boot module. This is because the property string is not
> null-terminated as requested by the ePAR spec.

Just two nitpicks. Could you change subject to "arm64/xen_boot: Fix
xen boot using Grub on AARCH64" and add your SOB? You can also repost
this patch with: Reviewed-by: Daniel Kiper 

Daniel

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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Konrad Rzeszutek Wilk]

On Thu, Nov 03, 2016 at 01:35:37PM +0100, Roger Pau Monne wrote:
> On Mon, Oct 31, 2016 at 10:32:47AM -0600, Jan Beulich wrote:
> > >>> On 29.10.16 at 10:59,  wrote:
> > > PVHv2 guests, unlike HVM guests, won't have the option to route interrupts
> > > from physical or emulated devices over event channels using PIRQs. This
> > > applies to both DomU and Dom0 PVHv2 guests.
> > > 
> > > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest can
> > > route physical interrupts (even from emulated devices) over event 
> > > channels,
> > > and is thus allowed to use some of the PHYSDEV ops.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > 
> > The patch looks fine now for its purpose, but I'm hesitant to ack it
> > without us having settled on whether we indeed mean to hide all
> > those physdev ops from Dom0. In particular I don't recall this (and
> > the reasoning behind it) having got written down somewhere.
> 
> I'm planning to add the following doc update together with this commit:
> 
> diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
> index 946908e..4fc757f 100644
> --- a/docs/misc/hvmlite.markdown
> +++ b/docs/misc/hvmlite.markdown
> @@ -75,3 +75,38 @@ info structure that's passed at boot time (field 
> rsdp_paddr).
>  
>  Description of paravirtualized devices will come from XenStore, just as it's
>  done for HVM guests.
> +
> +## Interrupts ##
> +
> +### Interrupts from physical devices ###
> +
> +Interrupts from physical devices are delivered using native methods, this is
> +done in order to take advantage of new hardware assisted virtualization
> +functions, like posted interrupts. This implies that PVHv2 guests with 
> physical
> +devices will also have the necessary interrupt controllers in order to manage
> +the delivery of interrupts from those devices, using the same interfaces that
> +are available on native hardware.
> +
> +### Interrupts from paravirtualized devices ###
> +
> +Interrupts from paravirtualized devices are delivered using event channels, 
> see
> +[Event Channel Internals][event_channels] for more detailed information about

Is this a must? This mechanism was designed before vAPIC was present -
and has the inherent disadvantage that:

 1) It can't use vAPIC (it actually has to disable this as it needs to
turn on VMX interrupt window to do this).

 2) It is hackish. It completly bypasses the APIC and it uses the
VM_ENTRY_INTR_INFO (suppose to be used for traps).

 3) It is also racy for events that are more than 64 values apart (with
the old 2 level one). That is you can have this callback vector
being injected couple of times - as the OS interrupt handler does not
mask the events.

 4) It causes the guest an VMEXIT (to stop it so that we can tweak
the VM_ENTRY_INTR_INFO).

If we really want to use it, could we instead use the per-vector
that Paul added? HVMOP_set_evtchn_upcall_vector?

Or perhaps just add events -> MSI-X mechanism and then we can also
do this under normal HVM guests?

Either option would require changes in Linux/FreeBSD to deal with this.
> +event channels. In order to inject interrupts into the guest an IDT vector is
> +used. This is the same mechanism used on PVHVM guests, and allows having
> +per-cpu interrupts that can be also used to deliver timers or IPIs if 
> desired.
> +
> +In order to register the callback IDT vector the `HVMOP_set_param` hypercall
> +is used with the following values:
> +
> +domid = DOMID_SELF
> +index = HVM_PARAM_CALLBACK_IRQ
> +value = (0x2 << 56) | vector_value
> +
> +The OS has to program the IDT for the `vector_value` using the baremetal
> +mechanism.
> +
> +In order to know which event channel has fired, we need to look into the
> +information provided in the `shared_info` structure. The `evtchn_pending`
> +array is used as a bitmap in order to find out which event channel has
> +fired. Event channels can also be masked by setting it's port value in the
> +`shared_info->evtchn_mask` bitmap.

.. Well that is for the 2-level, but the FIFO is a bit different.
> 

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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Konrad Rzeszutek Wilk]

On Thu, Nov 03, 2016 at 06:52:16AM -0600, Jan Beulich wrote:
> >>> On 03.11.16 at 13:35,  wrote:
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -75,3 +75,38 @@ info structure that's passed at boot time (field 
> > rsdp_paddr).
> >  
> >  Description of paravirtualized devices will come from XenStore, just as 
> > it's
> >  done for HVM guests.
> > +
> > +## Interrupts ##
> > +
> > +### Interrupts from physical devices ###
> > +
> > +Interrupts from physical devices are delivered using native methods, this 
> > is
> > +done in order to take advantage of new hardware assisted virtualization
> > +functions, like posted interrupts.
> 
> Okay, that's a reason for this to be optional (iirc AMD doesn't
> have posted interrupts so far), not for all the physdev ops being

They do, it is called AVIC. AMD posted an RFC patch to implement that:

https://lists.xenproject.org/archives/html/xen-devel/2016-09/msg01815.html

And it is mentioned at page 505 in the 24593 (Rev 3.26) manual.

> made not work at all. The more that I think I did point out before
> that there is at least one case where interrupt delivery info
> needs to be made available to Xen despite Dom0 not setting up
> an IO-APIC entry, and hence a physdev op is the only way to
> communicate that information.
> 
> Jan
> 

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

Re: [Xen-devel] Nested virtualization off VMware vSphere 6.0 with EL6 guests crashes on Xen 4.6

[Konrad Rzeszutek Wilk]

.. snip..
>>
>> > (XEN) Failed vm entry (exit reason 0x8021) caused by invalid guest 
>> > state (4).
>>
>> 4 means invalid VMCS link pointer - interesting.
>>
>
> Hey Jan,
>
> I hadn't been able to look at this for a quite while. A couple of folks have
> showed interest in looking at this, CC-ing them.
>

and Matt (CC-ed) had been able to debug this a bit further as well:

" I tracked this down to incorrect Xen emulation of  VMWRITE, VMPTRLD,
VMLAUNCH, and VMRESUME, in which Xen is failing the
operation if the provided address can't be mapped. A L1 VMM should be
allowed to write whatever garbage it wants into VMCS. The value may
not even be used depending on other control fields.

Xen also shouldn't be setting RFLAGS.CF (VMfailInvalid) for any
condition other than an invalid VMCS-link pointer (it was setting
RFLAGS.CF when it couldn't map the bitmap pages)."

And in retrospective it makes sense that VMWare writes garbage in
VMCS - it is probably using the binary translation part at that point.

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

Re: [Xen-devel] [PATCH v6 1/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386

[Daniel Kiper]

On Tue, Jul 26, 2016 at 05:13:40PM +0800, fu@linaro.org wrote:
> From: Fu Wei 
>
> Signed-off-by: Fu Wei 
> ---
>  grub-core/loader/i386/xen.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
> index c4d9689..15b0727 100644
> --- a/grub-core/loader/i386/xen.c
> +++ b/grub-core/loader/i386/xen.c
> @@ -689,6 +689,7 @@ fail:
>  }
>
>  static grub_command_t cmd_xen, cmd_initrd, cmd_module, cmd_multiboot;
> +static grub_command_t cmd_xen_hypervisor, cmd_xen_module;
>
>  GRUB_MOD_INIT (xen)
>  {
> @@ -696,10 +697,14 @@ GRUB_MOD_INIT (xen)
>  0, N_("Load Linux."));
>cmd_multiboot = grub_register_command ("multiboot", grub_cmd_xen,
>0, N_("Load Linux."));
> +  cmd_xen_hypervisor = grub_register_command ("xen_hypervisor", grub_cmd_xen,
> +   0, N_("Load Linux."));
>cmd_initrd = grub_register_command ("initrd", grub_cmd_initrd,
> 0, N_("Load initrd."));
>cmd_module = grub_register_command ("module", grub_cmd_module,
> 0, N_("Load module."));
> +  cmd_xen_module = grub_register_command ("xen_module", grub_cmd_module,
> +   0, N_("Load module."));
>my_mod = mod;
>  }
>
> @@ -709,4 +714,6 @@ GRUB_MOD_FINI (xen)
>grub_unregister_command (cmd_initrd);
>grub_unregister_command (cmd_multiboot);
>grub_unregister_command (cmd_module);
> +  grub_unregister_command (cmd_xen_module);
> +  grub_unregister_command (cmd_xen_hypervisor);

Hmmm... This whole patch does not make sense for me. Why are you
adding aliases for ARM Xen hypervisor et consortes load commands
(AIUI) in i386 PV guest loader?

Daniel

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

[Xen-devel] [PATCH for-4.8] xen/arm: early-printk: It should depends on CONFIG_DEBUG and not debug

[Julien Grall]

The variable debug is used to enable debug for the tools. As
early-printk is for the hypervisor we should use CONFIG_DEBUG.

Signed-off-by: Julien Grall 

---
This patch is candidate for Xen 4.8. This is a follow-up of [1].

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2016-11/msg00082.html
---
 xen/arch/arm/Rules.mk | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 93304be..569a0ba 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -24,7 +24,7 @@ endif
 
 EARLY_PRINTK := n
 
-ifeq ($(debug),y)
+ifeq ($(CONFIG_DEBUG),y)
 
 # See docs/misc/arm/early-printk.txt for syntax
 
@@ -77,7 +77,7 @@ CFLAGS-$(EARLY_PRINTK) += 
-DEARLY_PRINTK_BAUD=$(EARLY_PRINTK_BAUD)
 CFLAGS-$(EARLY_PRINTK) += -DEARLY_UART_BASE_ADDRESS=$(EARLY_UART_BASE_ADDRESS)
 CFLAGS-$(EARLY_PRINTK) += -DEARLY_UART_REG_SHIFT=$(EARLY_UART_REG_SHIFT)
 
-else # !debug
+else # !CONFIG_DEBUG
 
 ifneq ($(CONFIG_EARLY_PRINTK),)
 # Early printk is dependant on a debug build.
-- 
1.9.1


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

Re: [Xen-devel] [PATCH for-4.8] xen/arm: early-printk: It should depends on CONFIG_DEBUG and not debug

[Wei Liu]

On Thu, Nov 03, 2016 at 02:36:35PM +, Julien Grall wrote:
> The variable debug is used to enable debug for the tools. As
> early-printk is for the hypervisor we should use CONFIG_DEBUG.
> 
> Signed-off-by: Julien Grall 
> 

Acked-by: Wei Liu 

Sorry I missed this.

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

Re: [Xen-devel] [PATCH v6 2/4] arm64: add "--nounzip" option support in xen_module command

[Daniel Kiper]

On Tue, Jul 26, 2016 at 05:13:41PM +0800, fu@linaro.org wrote:
> From: Fu Wei 
>
> This patch adds "--nounzip" option support in order to
> be compatible with the module command of i386, then we can
> simplify grub-mkconfig support code.
>
> Signed-off-by: Fu Wei 
> ---
>  grub-core/loader/arm64/xen_boot.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/grub-core/loader/arm64/xen_boot.c 
> b/grub-core/loader/arm64/xen_boot.c
> index a914eb8..0878364 100644
> --- a/grub-core/loader/arm64/xen_boot.c
> +++ b/grub-core/loader/arm64/xen_boot.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Is it really needed?

Daniel

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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne]

On Thu, Nov 03, 2016 at 10:22:37AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 03, 2016 at 01:35:37PM +0100, Roger Pau Monne wrote:
> > On Mon, Oct 31, 2016 at 10:32:47AM -0600, Jan Beulich wrote:
> > > >>> On 29.10.16 at 10:59,  wrote:
> > > > PVHv2 guests, unlike HVM guests, won't have the option to route 
> > > > interrupts
> > > > from physical or emulated devices over event channels using PIRQs. This
> > > > applies to both DomU and Dom0 PVHv2 guests.
> > > > 
> > > > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest 
> > > > can
> > > > route physical interrupts (even from emulated devices) over event 
> > > > channels,
> > > > and is thus allowed to use some of the PHYSDEV ops.
> > > > 
> > > > Signed-off-by: Roger Pau Monné 
> > > 
> > > The patch looks fine now for its purpose, but I'm hesitant to ack it
> > > without us having settled on whether we indeed mean to hide all
> > > those physdev ops from Dom0. In particular I don't recall this (and
> > > the reasoning behind it) having got written down somewhere.
> > 
> > I'm planning to add the following doc update together with this commit:
> > 
> > diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
> > index 946908e..4fc757f 100644
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -75,3 +75,38 @@ info structure that's passed at boot time (field 
> > rsdp_paddr).
> >  
> >  Description of paravirtualized devices will come from XenStore, just as 
> > it's
> >  done for HVM guests.
> > +
> > +## Interrupts ##
> > +
> > +### Interrupts from physical devices ###
> > +
> > +Interrupts from physical devices are delivered using native methods, this 
> > is
> > +done in order to take advantage of new hardware assisted virtualization
> > +functions, like posted interrupts. This implies that PVHv2 guests with 
> > physical
> > +devices will also have the necessary interrupt controllers in order to 
> > manage
> > +the delivery of interrupts from those devices, using the same interfaces 
> > that
> > +are available on native hardware.
> > +
> > +### Interrupts from paravirtualized devices ###
> > +
> > +Interrupts from paravirtualized devices are delivered using event 
> > channels, see
> > +[Event Channel Internals][event_channels] for more detailed information 
> > about
> 
> Is this a must? This mechanism was designed before vAPIC was present -
> and has the inherent disadvantage that:
> 
>  1) It can't use vAPIC (it actually has to disable this as it needs to
> turn on VMX interrupt window to do this).
> 
>  2) It is hackish. It completly bypasses the APIC and it uses the
> VM_ENTRY_INTR_INFO (suppose to be used for traps).
> 
>  3) It is also racy for events that are more than 64 values apart (with
> the old 2 level one). That is you can have this callback vector
> being injected couple of times - as the OS interrupt handler does not
> mask the events.
> 
>  4) It causes the guest an VMEXIT (to stop it so that we can tweak
> the VM_ENTRY_INTR_INFO).
> 
> If we really want to use it, could we instead use the per-vector
> that Paul added? HVMOP_set_evtchn_upcall_vector?

PVHv2 should be able to use the same mechanism as HVM guests for event 
channel delivery. I'm not familiar with HVMOP_set_evtchn_upcall_vector, but 
AFAICT it's very similar to HVM_PARAM_CALLBACK_IRQ with the difference that 
each vCPU can specify different vectors, right?

> Or perhaps just add events -> MSI-X mechanism and then we can also
> do this under normal HVM guests?

That would be OK, but I think this is something that's out of the scope 
here. If this is ever implemented for HVM guests PVHv2 should also be able 
to use it, provided they have a local APIC.

> Either option would require changes in Linux/FreeBSD to deal with this.
> > +event channels. In order to inject interrupts into the guest an IDT vector 
> > is
> > +used. This is the same mechanism used on PVHVM guests, and allows having
> > +per-cpu interrupts that can be also used to deliver timers or IPIs if 
> > desired.
> > +
> > +In order to register the callback IDT vector the `HVMOP_set_param` 
> > hypercall
> > +is used with the following values:
> > +
> > +domid = DOMID_SELF
> > +index = HVM_PARAM_CALLBACK_IRQ
> > +value = (0x2 << 56) | vector_value
> > +
> > +The OS has to program the IDT for the `vector_value` using the baremetal
> > +mechanism.
> > +
> > +In order to know which event channel has fired, we need to look into the
> > +information provided in the `shared_info` structure. The `evtchn_pending`
> > +array is used as a bitmap in order to find out which event channel has
> > +fired. Event channels can also be masked by setting it's port value in the
> > +`shared_info->evtchn_mask` bitmap.
> 
> .. Well that is for the 2-level, but the FIFO is a bit different.

Right, I've just copy-pasted this from the classic PVH documented, which is 
clearly outdated now. We should have a document that describ

Re: [Xen-devel] Libvirt build broken

[Wei Liu]

On Thu, Nov 03, 2016 at 03:58:04PM +0100, Pavel Hrdina wrote:
> On Thu, Nov 03, 2016 at 01:50:17PM +, Wei Liu wrote:
> > Hi
> > 
> > Xen Project's CI system found a build failure between libvirt changes
> > 06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.
> > 
> > The build log can be found at:
> > 
> > http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log
> > 
> > The first error:
> > 
> >   CC   libvirt_driver_la-libvirt-host.lo
> > libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
> > incomplete type
> >  static struct gcry_thread_cbs virTLSThreadImpl = {
> >^
> > Earlier in configure:
> > 
> >   configure: gnutls: no 
> 
> Hi
> 
> I've just pushed a patch that fixes this build issue:
> 
> 
> 

Thanks!

Wei.

> Pavel



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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne]

On Thu, Nov 03, 2016 at 06:52:16AM -0600, Jan Beulich wrote:
> >>> On 03.11.16 at 13:35,  wrote:
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -75,3 +75,38 @@ info structure that's passed at boot time (field 
> > rsdp_paddr).
> >  
> >  Description of paravirtualized devices will come from XenStore, just as 
> > it's
> >  done for HVM guests.
> > +
> > +## Interrupts ##
> > +
> > +### Interrupts from physical devices ###
> > +
> > +Interrupts from physical devices are delivered using native methods, this 
> > is
> > +done in order to take advantage of new hardware assisted virtualization
> > +functions, like posted interrupts.
> 
> Okay, that's a reason for this to be optional (iirc AMD doesn't
> have posted interrupts so far), not for all the physdev ops being
> made not work at all. The more that I think I did point out before
> that there is at least one case where interrupt delivery info
> needs to be made available to Xen despite Dom0 not setting up
> an IO-APIC entry, and hence a physdev op is the only way to
> communicate that information.

IIRC we already had this discussion earlier, and the only thing that could 
need such information is a serial console that uses a non ISA IRQ, which we 
can also drive in polling mode. IMHO we can always enable some PHYSDEV ops 
if they are strictly necessary, but I would like to start with as few (ie: 
none) as possible.

Roger.

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

Re: [Xen-devel] [PATCH for-4.8] flask: build policy in different locations

[Daniel De Graaf]

On 10/28/2016 11:17 AM, Wei Liu wrote:

The flask policy can be build twice -- one for hypervisor and one for
tools.

Before this patch, everything is built inside tools/flask/policy
directory.  It is possible to have a race to write to the same output
file when running parallel builds.

Prepend output file names with FLASK_BUILD_DIR. Hypervisor and tools
build will set that variable to different directories, so that we can
be safe from races.

Adjust other bits of the build system as needed.

Signed-off-by: Wei Liu 


Acked-by: Daniel De Graaf 

Pulling the definition of POLICY_FILENAME out of Makefile.common might
remove the need for the cmp||cp line in the xen-side Makefile, but that
probably belongs in another patch.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] Libvirt build broken

[Pavel Hrdina]

On Thu, Nov 03, 2016 at 01:50:17PM +, Wei Liu wrote:
> Hi
> 
> Xen Project's CI system found a build failure between libvirt changes
> 06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.
> 
> The build log can be found at:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log
> 
> The first error:
> 
>   CC   libvirt_driver_la-libvirt-host.lo
> libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
> incomplete type
>  static struct gcry_thread_cbs virTLSThreadImpl = {
>^
> Earlier in configure:
> 
>   configure: gnutls: no 

Hi

I've just pushed a patch that fixes this build issue:



Pavel


signature.asc
Description: Digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support

[Daniel Kiper]

On Tue, Jul 26, 2016 at 05:13:42PM +0800, fu@linaro.org wrote:
> From: Fu Wei 
>
> This patch adds the support of xen_boot command:
> xen_hypervisor
> xen_module
>
> Also add a new "feature_xen_boot" to indicate this grub support
> xen_boot command.
>
> Signed-off-by: Fu Wei 
> ---
>  grub-core/normal/main.c |  2 +-
>  util/grub.d/20_linux_xen.in | 13 ++---
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c
> index 78a70a8..3402a05 100644
> --- a/grub-core/normal/main.c
> +++ b/grub-core/normal/main.c
> @@ -488,7 +488,7 @@ static const char *features[] = {
>"feature_chainloader_bpb", "feature_ntldr", "feature_platform_search_hint",
>"feature_default_font_path", "feature_all_video_module",
>"feature_menuentry_id", "feature_menuentry_options", "feature_200_final",
> -  "feature_nativedisk_cmd", "feature_timeout_style"
> +  "feature_nativedisk_cmd", "feature_timeout_style", "feature_xen_boot"

I do not like it. This is not generic feature but ARM specific one.
Hence, we should not announce it as generic stuff. Then...

>  };
>
>  GRUB_MOD_INIT(normal)
> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
> index c48af94..231e640 100644
> --- a/util/grub.d/20_linux_xen.in
> +++ b/util/grub.d/20_linux_xen.in
> @@ -122,16 +122,23 @@ linux_entry ()
>  else
>  xen_rm_opts="no-real-mode edd=off"
>  fi
> - multiboot   ${rel_xen_dirname}/${xen_basename} placeholder 
> ${xen_args} \${xen_rm_opts}
> +if [ "x\$feature_xen_boot" != xy ]; then

...we should consult $grub_platform and/or $grub_cpu here.

Daniel

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

Re: [Xen-devel] [libvirt] Libvirt build broken

[Olga Krishtal]

On 03/11/16 16:50, Wei Liu wrote:

Hi

Xen Project's CI system found a build failure between libvirt changes
06a7b1ff..478ddedc.  I don't think this is Xen specific FWIW.

The build log can be found at:

http://logs.test-lab.xenproject.org/osstest/logs/101868/build-amd64-libvirt/5.ts-libvirt-build.log

The first error:

   CC   libvirt_driver_la-libvirt-host.lo
libvirt.c:320:15: error: variable 'virTLSThreadImpl' has initializer but 
incomplete type
  static struct gcry_thread_cbs virTLSThreadImpl = {
^
Earlier in configure:

   configure: gnutls: no

>From the look of it configure doesn't work properly anymore.


Wei.

--
libvir-list mailing list
libvir-l...@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

I have just sent.
[PATCH] gcrypt: fix build in case we do not use gnutls and gcrypt


--
Best regards,
Olga


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

Re: [Xen-devel] [PATCH for-4.8] flask: build policy in different locations

[Wei Liu]

On Thu, Nov 03, 2016 at 11:17:59AM -0400, Daniel De Graaf wrote:
> On 10/28/2016 11:17 AM, Wei Liu wrote:
> >The flask policy can be build twice -- one for hypervisor and one for
> >tools.
> >
> >Before this patch, everything is built inside tools/flask/policy
> >directory.  It is possible to have a race to write to the same output
> >file when running parallel builds.
> >
> >Prepend output file names with FLASK_BUILD_DIR. Hypervisor and tools
> >build will set that variable to different directories, so that we can
> >be safe from races.
> >
> >Adjust other bits of the build system as needed.
> >
> >Signed-off-by: Wei Liu 
> 
> Acked-by: Daniel De Graaf 
> 

Thanks.

> Pulling the definition of POLICY_FILENAME out of Makefile.common might
> remove the need for the cmp||cp line in the xen-side Makefile, but that
> probably belongs in another patch.
> 

Yes, I think that's better done with another patch.

I will remove the redundant "tmp" in Makefile.common as discussed with
Jan and commit the updated patch with your ack.

Wei.

> -- 
> Daniel De Graaf
> National Security Agency

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

[Xen-devel] [ovmf baseline-only test] 67987: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 67986

version targeted for testing:
 ovmf e9d0933d45e51027836f570427141fd2e3a7dfbd
baseline version:
 ovmf 414b198be9c2065efda01cf43f7c86e41a449b4b

Last test of basis67986  2016-11-03 08:48:41 Z0 days
Testing same since67987  2016-11-03 13:47:59 Z0 days1 attempts


People who touched revisions under test:
  Cinnamon Shia 
  Jiewen Yao 

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 fail
 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 e9d0933d45e51027836f570427141fd2e3a7dfbd
Author: Jiewen Yao 
Date:   Fri Sep 30 15:45:50 2016 +0800

BaseTool/Pkcs7: Add TestRoot.cer.

We add this binary data file for TestRoot.cer.
So that a platform may include this default file in FDF,
to check if the platform is using default test key,
or different production key.

Cc: Yonghong Zhu 
Cc: Liming Gao 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Yonghong Zhu 
Reviewed-by: Michael D Kinney 

commit bfb4c2ba3742b61ef778e07957ff1b26b5a159b5
Author: Cinnamon Shia 
Date:   Wed Nov 2 10:40:34 2016 +0800

MdeModulePkg/PCD: Fix PcdGetNextToken may get a wrong PCD token

If there are two DynamicEx PCDs have the same PCD token number but
in different PCD token spaces, the PcdGetNextToken function may get
the wrong PCD token.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia 
Reviewed-by: Star Zeng 

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

Re: [Xen-devel] [PATCH v6 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Daniel Kiper]

On Tue, Jul 26, 2016 at 05:13:43PM +0800, fu@linaro.org wrote:
> From: Fu Wei 
>
> delete: xen_linux, xen_initrd, xen_xsm
> add: xen_module
>
> This update bases on
> commit 0edd750e50698854068358ea53528100a9192902
> Author: Vladimir Serbinenko 
> Date:   Fri Jan 22 10:18:47 2016 +0100
>
> xen_boot: Remove obsolete module type distinctions.
>
> Also bases on the module loading mechanism of Xen code:
> 488c2a8 docs/arm64: clarify the documention for loading XSM support
> 67831c4 docs/arm64: update the documentation for loading XSM support
> ca32012 xen/arm64: check XSM Magic from the second unknown module.
>
> Signed-off-by: Fu Wei 
> Reviewed-by: Julien Grall 
> ---
>  docs/grub.texi | 32 +---
>  1 file changed, 9 insertions(+), 23 deletions(-)
>
> diff --git a/docs/grub.texi b/docs/grub.texi
> index 82f6fa4..85c913e 100644
> --- a/docs/grub.texi
> +++ b/docs/grub.texi
> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
> @command{help}
>  * videoinfo::   List available video modes
>  @comment * xen_*::  Xen boot commands
>  * xen_hypervisor::  Load xen hypervisor binary
> -* xen_linux::   Load dom0 kernel for xen hypervisor
> -* xen_initrd::  Load dom0 initrd for dom0 kernel
> -* xen_xsm:: Load xen security module for xen hypervisor
> +* xen_module::  Load xen modules for xen hypervisor
>  @end menu
>
>
> @@ -5141,30 +5139,18 @@ verbatim as the @dfn{kernel command-line}. Any other 
> binaries must be
>  reloaded after using this command.
>  @end deffn
>
> -@node xen_linux
> -@subsection xen_linux
> +@node xen_module
> +@subsection xen_module
>
> -@deffn Command xen_linux file [arguments]
> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
> +@deffn Command xen_module [--nounzip] file [arguments]
> +Load a module for xen hypervisor at the booting process of xen.
>  The rest of the line is passed verbatim as the module command line.
> +Modules should be loaded in the following order:
> + - dom0 kernel image
> + - dom0 ramdisk if present
> + - XSM policy if present

What happens if somebody wants to use XSM without ramdisk?

Please do not forget to mention somewhere that xen_hypervisor and
xen_module commands are ARM specific.

Daniel

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs. 
101834
 build-armhf   5 xen-buildfail REGR. vs. 101834

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  6723676c2651a40855e37861315569892fa2b923
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101834  2016-10-31 22:10:29 Z2 days
Failing since101884  2016-11-03 12:02:50 Z0 days2 attempts
Testing same since   101887  2016-11-03 14:03:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  fail
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 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 6723676c2651a40855e37861315569892fa2b923
Author: Roger Pau Monne 
Date:   Thu Nov 3 13:19:03 2016 +0100

docs: document ACPI usage in PVHv2 guests

It is possible for PVHv2 guests to get the hardware description from ACPI
tables, add this to the documentation also.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 

commit 33b79dd04445b3ce289aa821eed8d812157478d6
Author: Roger Pau Monne 
Date:   Thu Nov 3 12:29:21 2016 +0100

docs: fixup PVHv2 documentation regarding AP startup

On PVHv2 guests the local APIC can also be used to start APs if present.
Amend the documentation in order to reflect this.

Signed-off-by: Roger Pau Monné 
Acked-by: Jan Beulich 
Release-acked-by: Wei Liu 

commit 12bc22f79117dfae5e59382cdda6b8b6b70a7554
Author: Andrew Cooper 
Date:   Wed Nov 2 14:43:48 2016 +

x86/emul: Reject LGDT/LIDT attempts with non-canonical base addresses

No sane OS would deliberately try this, but make Xen's emulation match real
hardware by delivering #GP(0), rather than suffering a VMEntry failure.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Release-acked-by: Wei Liu 

commit ff53c65311a32e54dba51f2b8112632e9dd2af3b
Author: Wei Liu 
Date:   Wed Nov 2 14:10:37 2016 +

libxl: disallow enabling PoD and ALTP2M at the same time

That combination would cause Xen to crash.

Note that although this is a security issue, is not XSA-worthy because
ALTP2M is experimental.

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

commit 3c79495579adddee535c2b7f8c332e4517764a0e
Author: Dario Faggioli 
Date:   Wed Nov 2 16:05:03 2016 +0100

features: declare the Credit2 scheduler as Supported

Credit2 is available in tree as an "Experimental" scheduler since
a few years. Recently, effort started for making it production ready
and, eventually, the new Xen's default scheduler. As a consequence of
that, it has undergone a great deal of development, testing and
benchmarking.

In fact, Credit2's much more modern (wrt Credit1) design and cleaner
code makes it a lot easier to understand what the scheduler is doing,
fix scheduling issues that may come up, and implement new and more
advanced features, in future.

In some more details:

 - key features that were missing (pinning and context switching
   rate-limiting) have now been implemented, and more (soft affinity,
   caps and reservations) are about to come. The gap wrt Credit1 is
   therefore closing. In particular, wi

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[Roger Pau Monne]

On Thu, Nov 03, 2016 at 07:06:14AM -0600, Jan Beulich wrote:
> >>> On 03.11.16 at 13:19,  wrote:
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -64,3 +64,14 @@ The following VCPU hypercalls can be used in order to 
> > bring up secondary vCPUs:
> >   * `VCPUOP_down` is used to bring down a vCPU.
> >  
> >   * `VCPUOP_is_up` is used to scan the number of available vCPUs.
> > +
> > +## Hardware description ##
> > +
> > +PVHv2 guests that have access to hardware (either emulated or real) will 
> > also
> > +have ACPI tables with the description of the hardware that's available to 
> > the
> > +guest. This applies to both privileged and unprivileged guests. A hint of
> > +the position of the RSDP in memory (if present) can be fetched from the 
> > start
> > +info structure that's passed at boot time (field rsdp_paddr).
> 
> Why "hint"?

Hm, maybe that's not the best word? (my English is clearly lacking 
sometimes). What I meant is that this is a pointer to the RSDP. I've 
probably used "hint" here because in FreeBSD the position of the RSDP is 
passed from the loader to the kernel as "hint.acpi.0.rsdp". Let me know if 
you would like me to rephrase this.

Roger.

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc V2

[Lan, Tianyu]

On 10/26/2016 5:39 PM, Jan Beulich wrote:

On 22.10.16 at 09:32,  wrote:

On 10/21/2016 4:36 AM, Andrew Cooper wrote:

3.5 Implementation consideration
VT-d spec doesn't define a capability bit for the l2 translation.
Architecturally there is no way to tell guest that l2 translation
capability is not available. Linux Intel IOMMU driver thinks l2
translation is always available when VTD exits and fail to be loaded
without l2 translation support even if interrupt remapping and l1
translation are available. So it needs to enable l2 translation first
before other functions.


What then is the purpose of the nested translation support bit in the
extended capability register?


It's to translate output GPA from first level translation(IOVA->GPA)
to HPA.

Detail please see VTD spec - 3.8 Nested Translation
"When Nesting Enable (NESTE) field is 1 in extended-context-entries,
requests-with-PASID translated through first-level translation are also
subjected to nested second-level translation. Such extendedcontext-
entries contain both the pointer to the PASID-table (which contains the
pointer to the firstlevel translation structures), and the pointer to
the second-level translation structures."


I didn't phrase my question very well.  I understand what the nested
translation bit means, but I don't understand why we have a problem
signalling the presence or lack of nested translations to the guest.

In other words, why can't we hide l2 translation from the guest by
simply clearing the nested translation capability?


You mean to tell no support of l2 translation via nest translation bit?
But the nested translation is a different function with l2 translation
even from guest view and nested translation only works requests with
PASID (l1 translation).

Linux intel iommu driver enables l2 translation unconditionally and free
iommu instance when failed to enable l2 translation.


In which cases the wording of your description is confusing: Instead of
"Linux Intel IOMMU driver thinks l2 translation is always available when
VTD exits and fail to be loaded without l2 translation support ..." how
about using something closer to what you've replied with last?

Jan



Hi All:
I have some updates about implementation dependency between l2
translation(DMA translation) and irq remapping.

I find there are a kernel parameter "intel_iommu=on" and kconfig option
CONFIG_INTEL_IOMMU_DEFAULT_ON which control DMA translation function.
When they aren't set, DMA translation function will not be enabled by
IOMMU driver even if some vIOMMU registers show L2 translation function
available. In the meantime, irq remapping function still can work to
support >255 vcpus.

I check distribution RHEL, SLES, Oracle and ubuntu don't set the kernel
parameter or select the kconfig option. So we can emulate irq remapping
fist with some capability bits(e,g SAGAW of Capability Register) of l2
translation for >255 vcpus support without l2 translation emulation.

Showing l2 capability bits is to make sure IOMMU driver probe ACPI DMAR
tables successfully because IOMMU driver access these bits during
reading ACPI tables.

If someone add "intel_iommu=on" kernel parameter manually, IOMMU driver
will panic guest because it can't enable DMA remapping function via gcmd
register and "Translation Enable Status" bit in gsts register is never
set by vIOMMU. This shows actual vIOMMU status of no l2 translation
emulation and warn user should not enable l2 translation.




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

Re: [Xen-devel] [PATCH v3.1 01/15] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne]

On Thu, Nov 03, 2016 at 10:22:37AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Nov 03, 2016 at 01:35:37PM +0100, Roger Pau Monne wrote:
> > On Mon, Oct 31, 2016 at 10:32:47AM -0600, Jan Beulich wrote:
> > > >>> On 29.10.16 at 10:59,  wrote:
> > > > PVHv2 guests, unlike HVM guests, won't have the option to route 
> > > > interrupts
> > > > from physical or emulated devices over event channels using PIRQs. This
> > > > applies to both DomU and Dom0 PVHv2 guests.
> > > > 
> > > > Introduce a new XEN_X86_EMU_USE_PIRQ to notify Xen whether a HVM guest 
> > > > can
> > > > route physical interrupts (even from emulated devices) over event 
> > > > channels,
> > > > and is thus allowed to use some of the PHYSDEV ops.
> > > > 
> > > > Signed-off-by: Roger Pau Monné 
> > > 
> > > The patch looks fine now for its purpose, but I'm hesitant to ack it
> > > without us having settled on whether we indeed mean to hide all
> > > those physdev ops from Dom0. In particular I don't recall this (and
> > > the reasoning behind it) having got written down somewhere.
> > 
> > I'm planning to add the following doc update together with this commit:
> > 
> > diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
> > index 946908e..4fc757f 100644
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -75,3 +75,38 @@ info structure that's passed at boot time (field 
> > rsdp_paddr).
> >  
> >  Description of paravirtualized devices will come from XenStore, just as 
> > it's
> >  done for HVM guests.
> > +
> > +## Interrupts ##
> > +
> > +### Interrupts from physical devices ###
> > +
> > +Interrupts from physical devices are delivered using native methods, this 
> > is
> > +done in order to take advantage of new hardware assisted virtualization
> > +functions, like posted interrupts. This implies that PVHv2 guests with 
> > physical
> > +devices will also have the necessary interrupt controllers in order to 
> > manage
> > +the delivery of interrupts from those devices, using the same interfaces 
> > that
> > +are available on native hardware.
> > +
> > +### Interrupts from paravirtualized devices ###
> > +
> > +Interrupts from paravirtualized devices are delivered using event 
> > channels, see
> > +[Event Channel Internals][event_channels] for more detailed information 
> > about
> 
> Is this a must? This mechanism was designed before vAPIC was present -
> and has the inherent disadvantage that:
> 
>  1) It can't use vAPIC (it actually has to disable this as it needs to
> turn on VMX interrupt window to do this).
> 
>  2) It is hackish. It completly bypasses the APIC and it uses the
> VM_ENTRY_INTR_INFO (suppose to be used for traps).
> 
>  3) It is also racy for events that are more than 64 values apart (with
> the old 2 level one). That is you can have this callback vector
> being injected couple of times - as the OS interrupt handler does not
> mask the events.
> 
>  4) It causes the guest an VMEXIT (to stop it so that we can tweak
> the VM_ENTRY_INTR_INFO).
> 
> If we really want to use it, could we instead use the per-vector
> that Paul added? HVMOP_set_evtchn_upcall_vector?
> 
> Or perhaps just add events -> MSI-X mechanism and then we can also
> do this under normal HVM guests?
> 
> Either option would require changes in Linux/FreeBSD to deal with this.
> > +event channels. In order to inject interrupts into the guest an IDT vector 
> > is
> > +used. This is the same mechanism used on PVHVM guests, and allows having
> > +per-cpu interrupts that can be also used to deliver timers or IPIs if 
> > desired.
> > +
> > +In order to register the callback IDT vector the `HVMOP_set_param` 
> > hypercall
> > +is used with the following values:
> > +
> > +domid = DOMID_SELF
> > +index = HVM_PARAM_CALLBACK_IRQ
> > +value = (0x2 << 56) | vector_value
> > +
> > +The OS has to program the IDT for the `vector_value` using the baremetal
> > +mechanism.
> > +
> > +In order to know which event channel has fired, we need to look into the
> > +information provided in the `shared_info` structure. The `evtchn_pending`
> > +array is used as a bitmap in order to find out which event channel has
> > +fired. Event channels can also be masked by setting it's port value in the
> > +`shared_info->evtchn_mask` bitmap.
> 
> .. Well that is for the 2-level, but the FIFO is a bit different.

I've modified the last paragraph, so now it's less concise about how event 
channel works (it doesn't mention l2 internals anymore):

### Interrupts from paravirtualized devices ###

Interrupts from paravirtualized devices are delivered using event channels, see
[Event Channel Internals][event_channels] for more detailed information about
event channels. Delivery of those interrupts can be configured in the same way
as HVM guests, check xen/include/public/hvm/params.h and
xen/include/public/hvm/hvm_op.h for more information about available delivery
methods.

Roger.

_

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[Jan Beulich]

>>> On 03.11.16 at 16:38,  wrote:
> On Thu, Nov 03, 2016 at 07:06:14AM -0600, Jan Beulich wrote:
>> >>> On 03.11.16 at 13:19,  wrote:
>> > --- a/docs/misc/hvmlite.markdown
>> > +++ b/docs/misc/hvmlite.markdown
>> > @@ -64,3 +64,14 @@ The following VCPU hypercalls can be used in order to 
> bring up secondary vCPUs:
>> >   * `VCPUOP_down` is used to bring down a vCPU.
>> >  
>> >   * `VCPUOP_is_up` is used to scan the number of available vCPUs.
>> > +
>> > +## Hardware description ##
>> > +
>> > +PVHv2 guests that have access to hardware (either emulated or real) will 
>> > also
>> > +have ACPI tables with the description of the hardware that's available to 
>> > the
>> > +guest. This applies to both privileged and unprivileged guests. A hint of
>> > +the position of the RSDP in memory (if present) can be fetched from the 
>> > start
>> > +info structure that's passed at boot time (field rsdp_paddr).
>> 
>> Why "hint"?
> 
> Hm, maybe that's not the best word? (my English is clearly lacking 
> sometimes). What I meant is that this is a pointer to the RSDP. I've 
> probably used "hint" here because in FreeBSD the position of the RSDP is 
> passed from the loader to the kernel as "hint.acpi.0.rsdp". Let me know if 
> you would like me to rephrase this.

I indeed think this should be re-worded. After all that start info field
is iirc the _only_ way to get the pointer.

Jan


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

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[George Dunlap]

On 03/11/16 15:55, Jan Beulich wrote:
 On 03.11.16 at 16:38,  wrote:
>> On Thu, Nov 03, 2016 at 07:06:14AM -0600, Jan Beulich wrote:
>> On 03.11.16 at 13:19,  wrote:
 --- a/docs/misc/hvmlite.markdown
 +++ b/docs/misc/hvmlite.markdown
 @@ -64,3 +64,14 @@ The following VCPU hypercalls can be used in order to 
>> bring up secondary vCPUs:
   * `VCPUOP_down` is used to bring down a vCPU.
  
   * `VCPUOP_is_up` is used to scan the number of available vCPUs.
 +
 +## Hardware description ##
 +
 +PVHv2 guests that have access to hardware (either emulated or real) will 
 also
 +have ACPI tables with the description of the hardware that's available to 
 the
 +guest. This applies to both privileged and unprivileged guests. A hint of
 +the position of the RSDP in memory (if present) can be fetched from the 
 start
 +info structure that's passed at boot time (field rsdp_paddr).
>>>
>>> Why "hint"?
>>
>> Hm, maybe that's not the best word? (my English is clearly lacking 
>> sometimes). What I meant is that this is a pointer to the RSDP. I've 
>> probably used "hint" here because in FreeBSD the position of the RSDP is 
>> passed from the loader to the kernel as "hint.acpi.0.rsdp". Let me know if 
>> you would like me to rephrase this.
> 
> I indeed think this should be re-worded. After all that start info field
> is iirc the _only_ way to get the pointer.

Yes, a hint, particularly in computer science, is a bit of information
which 1) isn't strictly needed, and 2) may not actually be correct; a
hint may be ignored with no change in functionality (only performance).
You might hint to the OS that a bit of memory is going to be very hot
and should therefore not be paged out; but the OS can ignore that hint
if it wants.  SCHEDOP_yield in Xen is a hint.

Since as Jan says, the information *is* strictly needed, and must always
be correct, you should probably just call it a pointer.

 -George

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

Re: [Xen-devel] [PATCH for-4.8] docs: document ACPI usage in PVHv2 guests

[George Dunlap]

On 03/11/16 15:55, Jan Beulich wrote:
 On 03.11.16 at 16:38,  wrote:
>> On Thu, Nov 03, 2016 at 07:06:14AM -0600, Jan Beulich wrote:
>> On 03.11.16 at 13:19,  wrote:
 --- a/docs/misc/hvmlite.markdown
 +++ b/docs/misc/hvmlite.markdown
 @@ -64,3 +64,14 @@ The following VCPU hypercalls can be used in order to 
>> bring up secondary vCPUs:
   * `VCPUOP_down` is used to bring down a vCPU.
  
   * `VCPUOP_is_up` is used to scan the number of available vCPUs.
 +
 +## Hardware description ##
 +
 +PVHv2 guests that have access to hardware (either emulated or real) will 
 also
 +have ACPI tables with the description of the hardware that's available to 
 the
 +guest. This applies to both privileged and unprivileged guests. A hint of
 +the position of the RSDP in memory (if present) can be fetched from the 
 start
 +info structure that's passed at boot time (field rsdp_paddr).
>>>
>>> Why "hint"?
>>
>> Hm, maybe that's not the best word? (my English is clearly lacking 
>> sometimes). What I meant is that this is a pointer to the RSDP. I've 
>> probably used "hint" here because in FreeBSD the position of the RSDP is 
>> passed from the loader to the kernel as "hint.acpi.0.rsdp". Let me know if 
>> you would like me to rephrase this.
> 
> I indeed think this should be re-worded. After all that start info field
> is iirc the _only_ way to get the pointer.

In plain English, a "hint" is a bit of information that is meant to help
you reach the answer to a puzzle more quickly; but without which you
should (in theory) be able to solve it yourself.  If a student was
struggling with a mathematical proof, the teacher might say something
like, "Here's a hint: x is never negative." (Or whatever.)  Or if you
had hidden something for someone to find, you might say, "Here's a hint:
It's near something blue."

But if you wanted to come visit me, I couldn't say, "Here's a hint: My
address is 123 Easy St", because I certainly wasn't expecting you to
figure out what my address was by doing a brute-force search. :-)

 -George

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

Re: [Xen-devel] [PATCH for-4.8] libxl: disallow enabling PoD and ALTP2M at the same time

[Wei Liu]

On Thu, Nov 03, 2016 at 11:10:44AM +, Wei Liu wrote:
> On Wed, Nov 02, 2016 at 02:51:41PM +, Wei Liu wrote:
> > On Wed, Nov 02, 2016 at 02:43:58PM +, Ian Jackson wrote:
> > > Wei Liu writes ("[PATCH for-4.8] libxl: disallow enabling PoD and ALTP2M 
> > > at the same time"):
> > > > That combination would cause Xen to crash. Note that this is not a
> > > > security issue because ALTP2M is experimental.
> > > 
> > > Acked-by: Ian Jackson 
> > > 
> > > You mean, though
> > > 
> > >   Note that although this is a security issue, is not an XSA-worthy
> > >   because ALTP2M is experimental.
> > 
> 
> Updated commit message and applied.

I interpreted the code for setting default value wrong. I will revert
the patch and staging and rework it.

Wei.

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

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  680d2f49dad425395de627a31006cb84848cfa65
  Bug not present: c290f216c47afbd4f3d1e082cdb98181675cd31e
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101885/


  commit 680d2f49dad425395de627a31006cb84848cfa65
  Author: Pavel Hrdina 
  Date:   Fri Oct 21 23:09:53 2016 +0200
  
  configure: move gnutls check into virt-gnutls.m4
  
  Signed-off-by: Pavel Hrdina 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-amd64-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-amd64-libvirt.libvirt-build 
--summary-out=tmp/101885.bisection-summary --basis-template=101839 
--blessings=real,real-bisect libvirt build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 101868 fail [host=godello1] / 101854 [host=baroque0] 101839 [host=baroque0] 
101773 [host=chardonnay1] 101738 [host=godello0] 101711 [host=godello0] 101677 
ok.
Failure / basis pass flights: 101868 / 101677
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 478ddedc12b77313cbaf72328ab2236ce7c56ead 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
Basis pass 13022ce430da9d6ce4dc9e9117d6be519e7afc4a 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
6f9b62ca57322197e26d3b22ff11b629697142bd
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#13022ce430da9d6ce4dc9e9117d6be519e7afc4a-478ddedc12b77313cbaf72328ab2236ce7c56ead
 
git://git.sv.gnu.org/gnulib.git#e89b4a7aefce9cb02963920712ba7cdd13641644-e89b4a7aefce9cb02963920712ba7cdd13641644
 
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-c4e0d84d3c92923fdbc7fa922638d54e5e834753
 
git://xenbits.xen.org/qemu-xen.git#6cfcdf037edadba984ccf8476b5d1e2a0940b789-6cfcdf037edadba984ccf8476b5d1e2a0940b789
 
git://xenbits.xen.org/xen.git#6f9b62ca57322197e26d3b22ff11b629697142bd-496673a2ada93c201fbe1cc83146c8bd8e79169d
From git://cache:9419/git://libvirt.org/libvirt
   478dded..a55fdc3  master -> origin/master
From git://cache:9419/git://xenbits.xen.org/xen
   6723676..bd41a22  staging-> origin/staging
Loaded 2001 nodes in revision graph
Searching for test results:
 101677 pass 13022ce430da9d6ce4dc9e9117d6be519e7afc4a 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
6f9b62ca57322197e26d3b22ff11b629697142bd
 101711 [host=godello0]
 101738 [host=godello0]
 101773 [host=chardonnay1]
 101839 [host=baroque0]
 101874 fail 478ddedc12b77313cbaf72328ab2236ce7c56ead 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101875 pass 8b035c84d8a7362a87a95e6114b8e7f959685ed9 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
a418ec07cf2668197548c6503924139a2098e41d
 101876 pass 06a7b1ff4dbb1ed6a69e09765bef1f67a75a86eb 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
7791790c7ab97c85306dce749c6c8eb56d1dc0da
 101877 fail 0c62ccf927c60c9c248db52a23670ec2f9bce2b2 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101878 pass ac9bf9394138d0cf9a802245ad3eebf8adcb4841 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101879 pass c290f216c47afbd4f3d1e082cdb98181675cd31e 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101880 fail 680d2f49dad425395de627a31006cb84848cfa65 
e89b4a7aefce9cb0296

[Xen-devel] [PATCH for-4.8 0/2] libxl: adjustment to initiate_domain_create

[Wei Liu]

Wei Liu (2):
  libxl: set ret in the check for nestedhvm and altp2m
  libxl: disallow enabling PoD and ALTP2M at the same time

 tools/libxl/libxl_create.c | 9 +
 1 file changed, 9 insertions(+)

-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8] docs: replace hint with pointer in PVHv2 ACPI documentation

[Roger Pau Monne]

Use pointer instead of hint, since this is the only way to get the address
of the RSDP.

Signed-off-by: Roger Pau Monné 
Reported-by: Jan Beulich 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Boris Ostrovsky 
Cc: Konrad Rzeszutek Wilk 
---
 docs/misc/hvmlite.markdown | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/misc/hvmlite.markdown b/docs/misc/hvmlite.markdown
index 946908e..898b8ee 100644
--- a/docs/misc/hvmlite.markdown
+++ b/docs/misc/hvmlite.markdown
@@ -69,7 +69,7 @@ The following VCPU hypercalls can be used in order to bring 
up secondary vCPUs:
 
 PVHv2 guests that have access to hardware (either emulated or real) will also
 have ACPI tables with the description of the hardware that's available to the
-guest. This applies to both privileged and unprivileged guests. A hint of
+guest. This applies to both privileged and unprivileged guests. A pointer to
 the position of the RSDP in memory (if present) can be fetched from the start
 info structure that's passed at boot time (field rsdp_paddr).
 
-- 
2.7.4 (Apple Git-66)


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

[Xen-devel] [PATCH for-4.8 1/2] libxl: set ret in the check for nestedhvm and altp2m

[Wei Liu]

The error path expects ret to be set, otherwise an assertion is
triggered.

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

Please backport to 4.6 and 4.7.
---
 tools/libxl/libxl_create.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index d986cd2..abd2272 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -910,6 +910,7 @@ static void initiate_domain_create(libxl__egc *egc,
 if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
 (libxl_defbool_val(d_config->b_info.u.hvm.nested_hvm) &&
  libxl_defbool_val(d_config->b_info.u.hvm.altp2m))) {
+ret = ERROR_INVAL;
 LOG(ERROR, "nestedhvm and altp2mhvm cannot be used together");
 goto error_out;
 }
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.8 2/2] libxl: disallow enabling PoD and ALTP2M at the same time

[Wei Liu]

That combination would cause Xen to crash.

Note that although this is a security issue, is not XSA-worthy because
ALTP2M is experimental.

Signed-off-by: Wei Liu 
---
Move the snippet to the correct location after altp2m is correctly
initialised. Also correctly set ret before exiting.

Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: George Dunlap ,
Cc: Andrew Cooper 
Cc: Kevin Tian 
Cc: Jun Nakajima 
---
 tools/libxl/libxl_create.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index abd2272..7c1695a 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -915,6 +915,14 @@ static void initiate_domain_create(libxl__egc *egc,
 goto error_out;
 }
 
+if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
+libxl_defbool_val(d_config->b_info.u.hvm.altp2m) &&
+pod_enabled) {
+ret = ERROR_INVAL;
+LOG(ERROR, "Cannot enable PoD and ALTP2M at the same time");
+goto error_out;
+}
+
 ret = libxl__domain_make(gc, d_config, &domid, &state->config);
 if (ret) {
 LOG(ERROR, "cannot make domain: %d", ret);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH for-4.8] docs: replace hint with pointer in PVHv2 ACPI documentation

[Jan Beulich]

>>> On 03.11.16 at 17:48,  wrote:
> Use pointer instead of hint, since this is the only way to get the address
> of the RSDP.
> 
> Signed-off-by: Roger Pau Monné 
> Reported-by: Jan Beulich 

Acked-by: Jan Beulich 

Thanks, Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 9 debian-hvm-install fail REGR. vs. 
101834
 test-armhf-armhf-xl   6 xen-boot fail REGR. vs. 101834

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

version targeted for testing:
 xen  6723676c2651a40855e37861315569892fa2b923
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101834  2016-10-31 22:10:29 Z2 days
Failing since101884  2016-11-03 12:02:50 Z0 days3 attempts
Testing same since   101887  2016-11-03 14:03:07 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  fail
 test-amd64-amd64-xl-qemuu-debianhvm-i386 fail
 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 6723676c2651a40855e37861315569892fa2b923
Author: Roger Pau Monne 
Date:   Thu Nov 3 13:19:03 2016 +0100

docs: document ACPI usage in PVHv2 guests

It is possible for PVHv2 guests to get the hardware description from ACPI
tables, add this to the documentation also.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 
Release-acked-by: Wei Liu 

commit 33b79dd04445b3ce289aa821eed8d812157478d6
Author: Roger Pau Monne 
Date:   Thu Nov 3 12:29:21 2016 +0100

docs: fixup PVHv2 documentation regarding AP startup

On PVHv2 guests the local APIC can also be used to start APs if present.
Amend the documentation in order to reflect this.

Signed-off-by: Roger Pau Monné 
Acked-by: Jan Beulich 
Release-acked-by: Wei Liu 

commit 12bc22f79117dfae5e59382cdda6b8b6b70a7554
Author: Andrew Cooper 
Date:   Wed Nov 2 14:43:48 2016 +

x86/emul: Reject LGDT/LIDT attempts with non-canonical base addresses

No sane OS would deliberately try this, but make Xen's emulation match real
hardware by delivering #GP(0), rather than suffering a VMEntry failure.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
Release-acked-by: Wei Liu 

commit ff53c65311a32e54dba51f2b8112632e9dd2af3b
Author: Wei Liu 
Date:   Wed Nov 2 14:10:37 2016 +

libxl: disallow enabling PoD and ALTP2M at the same time

That combination would cause Xen to crash.

Note that although this is a security issue, is not XSA-worthy because
ALTP2M is experimental.

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

commit 3c79495579adddee535c2b7f8c332e4517764a0e
Author: Dario Faggioli 
Date:   Wed Nov 2 16:05:03 2016 +0100

features: declare the Credit2 scheduler as Supported

Credit2 is available in tree as an "Experimental" scheduler since
a few years. Recently, effort started for making it production ready
and, eventually, the new Xen's default scheduler. As a consequence of
that, it has undergone a great deal of development, testing and
benchmarking.

In fact, Credit2's much more modern (wrt Credit1) design and cleaner
code makes it a lot easier to understand what the scheduler is doing,
fix scheduling issues that may come up, and implement new and more
advanced features, in future.

In some more details:

 - key features that were missing (pinning and context switching
   rate-limiting) have now been implemented, and more (soft affinity,
   caps and reservations) are about to come. The gap wrt Credit1 is
   therefore closing. In particular, with pinning and rate-limiting
   available, the scheduler can be conside

Re: [Xen-devel] [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits

[Julien Grall]

Hi Andre,

On 28/09/16 19:24, Andre Przywara wrote:

Create a new file to hold the emulation code for the ITS widget.
For now we emulate the memory mapped ITS registers and provide a stub
to introduce the ITS command handling framework (but without actually
emulating any commands at this time).


The ITS is a complex piece so I think it would be good to describe more 
in the commit message how this will work. Also a documentation in the 
tree would be very good to help understanding the code.




Signed-off-by: Andre Przywara 
---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/vgic-its.c   | 378 ++
 xen/arch/arm/vgic-v3.c|   9 -
 xen/include/asm-arm/gic_v3_defs.h |  19 ++
 4 files changed, 398 insertions(+), 9 deletions(-)
 create mode 100644 xen/arch/arm/vgic-its.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index c2c4daa..cb0201f 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -44,6 +44,7 @@ obj-y += traps.o
 obj-y += vgic.o
 obj-y += vgic-v2.o
 obj-$(CONFIG_ARM_64) += vgic-v3.o
+obj-$(CONFIG_HAS_ITS) += vgic-its.o
 obj-y += vm_event.o
 obj-y += vtimer.o
 obj-y += vpsci.o
diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
new file mode 100644
index 000..875b992
--- /dev/null
+++ b/xen/arch/arm/vgic-its.c
@@ -0,0 +1,378 @@
+/*
+ * xen/arch/arm/vgic-its.c
+ *
+ * ARM Interrupt Translation Service (ITS) emulation
+ *
+ * Andre Przywara 
+ * Copyright (c) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Data structure to describe a virtual ITS */
+struct virt_its {
+struct domain *d;
+struct host_its *hw_its;
+spinlock_t vcmd_lock;   /* protects the virtual command buffer */
+uint64_t cbaser;
+uint64_t *cmdbuf;
+int cwriter;
+int creadr;


CWRITER and CREADR are registers so they need to be described in term of 
number of bits. Also, while the top word of CREADR/CWRITER is RES0. I 
would much prefer to see uint64_t rather than uint32_t as this is the 
real size of the register.



+spinlock_t its_lock;/* protects the collection and device tables */
+uint64_t baser0, baser1;


Please describe what contains baser0 and baser1. If I understand 
correctly the code, baser0 will be store Device information whilst 
baser1 the collection.



+uint16_t *coll_table;


What is the layout of the device table?


+int max_collections;


unsigned int


+uint64_t *dev_table;


What is the layout of the device table?


+int max_devices;


unsigned int.


+bool enabled;
+};
+
+/* An Interrupt Translation Table Entry: this is indexed by a


Coding style:

/*
 * Foo


+ * DeviceID/EventID pair and is located in guest memory.
+ */
+struct vits_itte
+{
+uint64_t hlpi:24;
+uint64_t vlpi:24;
+uint64_t collection:16;
+};
+
+/**
+ * Functions that handle ITS commands *
+ **/
+
+static uint64_t its_cmd_mask_field(uint64_t *its_cmd,


Please make this function inline.


+   int word, int shift, int size)


unsigned for all those parameters.


+{
+return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);


It is probably better to use BIT_ULL (see my explanation on previous 
patches).



+}
+
+#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
+#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
+#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
+#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
+#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
+#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
+#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
+#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
+
+#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
+
+static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
+uint32_t writer)


uint64_t here.


+{
+uint64_t *cmdptr;
+
+if ( !its->cmdbuf )
+return -1;
+
+if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
+return -1;


You return an error value but the cal

[Xen-devel] [PATCH for-4.8] git: Add metadata to the result of `git archive`

[Andrew Cooper]

When building Xen from a source tarball, commit information is usually lost,
especially if the tarball was generated from a tag.

Have `git archive` automatically fill in metadata at the point of creating the
archive, which is especially useful when using web snapshot links such as:

  http://xenbits.xen.org/gitweb/?p=xen.git;a=snapshot;h=HEAD;sf=tgz

to obtain the tarball.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 

It would be useful if this could be included in 4.8, and backported to older
releases  (Assuming noone has any objections)
---
 .gitarchive-info | 2 ++
 .gitattributes   | 1 +
 2 files changed, 3 insertions(+)
 create mode 100644 .gitarchive-info
 create mode 100644 .gitattributes

diff --git a/.gitarchive-info b/.gitarchive-info
new file mode 100644
index 000..83e5b86
--- /dev/null
+++ b/.gitarchive-info
@@ -0,0 +1,2 @@
+Changeset: $Format:%H$
+Commit date: $Format:%cD$
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 000..f7bf506
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+.gitarchive-info export-subst
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH 12/24] ARM: vGICv3: introduce basic ITS emulation bits

[Andre Przywara]

Hi,

On 24/10/16 16:31, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> wrote:
>> Create a new file to hold the emulation code for the ITS widget.
>> For now we emulate the memory mapped ITS registers and provide a stub
>> to introduce the ITS command handling framework (but without actually
>> emulating any commands at this time).
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/Makefile |   1 +
>>  xen/arch/arm/vgic-its.c   | 378 
>> ++
>>  xen/arch/arm/vgic-v3.c|   9 -
>>  xen/include/asm-arm/gic_v3_defs.h |  19 ++
>>  4 files changed, 398 insertions(+), 9 deletions(-)
>>  create mode 100644 xen/arch/arm/vgic-its.c
>>
>> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
>> index c2c4daa..cb0201f 100644
>> --- a/xen/arch/arm/Makefile
>> +++ b/xen/arch/arm/Makefile
>> @@ -44,6 +44,7 @@ obj-y += traps.o
>>  obj-y += vgic.o
>>  obj-y += vgic-v2.o
>>  obj-$(CONFIG_ARM_64) += vgic-v3.o
>> +obj-$(CONFIG_HAS_ITS) += vgic-its.o
>>  obj-y += vm_event.o
>>  obj-y += vtimer.o
>>  obj-y += vpsci.o
>> diff --git a/xen/arch/arm/vgic-its.c b/xen/arch/arm/vgic-its.c
>> new file mode 100644
>> index 000..875b992
>> --- /dev/null
>> +++ b/xen/arch/arm/vgic-its.c
>> @@ -0,0 +1,378 @@
>> +/*
>> + * xen/arch/arm/vgic-its.c
>> + *
>> + * ARM Interrupt Translation Service (ITS) emulation
>> + *
>> + * Andre Przywara 
>> + * Copyright (c) 2016 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* Data structure to describe a virtual ITS */
>> +struct virt_its {
>> +struct domain *d;
>> +struct host_its *hw_its;
>> +spinlock_t vcmd_lock;   /* protects the virtual command buffer */
>> +uint64_t cbaser;
>> +uint64_t *cmdbuf;
>> +int cwriter;
>> +int creadr;
>> +spinlock_t its_lock;/* protects the collection and device 
>> tables */
>> +uint64_t baser0, baser1;
>> +uint16_t *coll_table;
>> +int max_collections;
>> +uint64_t *dev_table;
>> +int max_devices;
>> +bool enabled;
>> +};
>> +
>> +/* An Interrupt Translation Table Entry: this is indexed by a
>> + * DeviceID/EventID pair and is located in guest memory.
>> + */
>> +struct vits_itte
>> +{
>> +uint64_t hlpi:24;
>> +uint64_t vlpi:24;
>> +uint64_t collection:16;
>> +};
>> +
>> +/**
>> + * Functions that handle ITS commands *
>> + **/
>> +
>> +static uint64_t its_cmd_mask_field(uint64_t *its_cmd,
>> +   int word, int shift, int size)
>> +{
>> +return (le64_to_cpu(its_cmd[word]) >> shift) & (BIT(size) - 1);
>> +}
>> +
>> +#define its_cmd_get_command(cmd)its_cmd_mask_field(cmd, 0,  0,  8)
>> +#define its_cmd_get_deviceid(cmd)   its_cmd_mask_field(cmd, 0, 32, 32)
>> +#define its_cmd_get_size(cmd)   its_cmd_mask_field(cmd, 1,  0,  5)
>> +#define its_cmd_get_id(cmd) its_cmd_mask_field(cmd, 1,  0, 32)
>> +#define its_cmd_get_physical_id(cmd)its_cmd_mask_field(cmd, 1, 32, 32)
>> +#define its_cmd_get_collection(cmd) its_cmd_mask_field(cmd, 2,  0, 16)
>> +#define its_cmd_get_target_addr(cmd)its_cmd_mask_field(cmd, 2, 16, 32)
>> +#define its_cmd_get_validbit(cmd)   its_cmd_mask_field(cmd, 2, 63,  1)
>> +
>> +#define ITS_CMD_BUFFER_SIZE(baser)  baser) & 0xff) + 1) << 12)
>> +
>> +static int vgic_its_handle_cmds(struct domain *d, struct virt_its *its,
>> +uint32_t writer)
>> +{
>> +uint64_t *cmdptr;
>> +
>> +if ( !its->cmdbuf )
>> +return -1;
>> +
>> +if ( writer >= ITS_CMD_BUFFER_SIZE(its->cbaser) )
>> +return -1;
>> +
>> +spin_lock(&its->vcmd_lock);
>> +
>> +while ( its->creadr != writer )
>> +{
>> +cmdptr = its->cmdbuf + (its->creadr / sizeof(*its->cmdbuf));
>> +switch (its_cmd_get_command(cmdptr))
>> +{
>> +case GITS_CMD_SYNC:
>> +/* We handle ITS commands synchronously, so we ignore SYNC. */
>> +   break;
>> +default:
>> +gdprintk(XENLOG_G_WARNING, "ITS: unhandled ITS command %ld\n",
>> +   its_cmd_get_command(cmdptr));
>> +break;
>> +  

Re: [Xen-devel] [RFC PATCH 07/24] ARM: GICv3 ITS: introduce device mapping

[Andre Przywara]

Hi,

On 24/10/16 16:31, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> wrote:
>> The ITS uses device IDs to map LPIs to a device. Dom0 will later use
>> those IDs, which we directly pass on to the host.
>> For this we have to map each device that Dom0 may request to a host
>> ITS device with the same identifier.
>> Allocate the respective memory and enter each device into a list to
>> later be able to iterate over it or to easily teardown guests.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic-its.c| 90 
>> +++
>>  xen/include/asm-arm/gic-its.h | 16 
>>  2 files changed, 106 insertions(+)
>>
>> diff --git a/xen/arch/arm/gic-its.c b/xen/arch/arm/gic-its.c
>> index 2140e4a..bf1f5b5 100644
>> --- a/xen/arch/arm/gic-its.c
>> +++ b/xen/arch/arm/gic-its.c
>> @@ -168,6 +168,94 @@ static int its_send_cmd_mapc(struct host_its *its, int 
>> collection_id, int cpu)
>>  return its_send_command(its, cmd);
>>  }
>>
>> +static int its_send_cmd_mapd(struct host_its *its, uint32_t deviceid,
>> + int size, uint64_t itt_addr, bool valid)
>> +{
>> +uint64_t cmd[4];
>> +
>> +cmd[0] = GITS_CMD_MAPD | ((uint64_t)deviceid << 32);
>> +cmd[1] = size & GENMASK(4, 0);
>> +cmd[2] = itt_addr & GENMASK(51, 8);
>> +if ( valid )
>> +cmd[2] |= BIT(63);
>> +cmd[3] = 0x00;
>> +
>> +return its_send_command(its, cmd);
>> +}
>> +
>> +int gicv3_its_map_device(struct host_its *hw_its, struct domain *d,
>> + int devid, int bits, bool valid)
>> +{
>> +void *itt_addr = NULL;
>> +struct its_devices *dev, *temp;
>> +bool reuse_dev = false;
>> +
>> +list_for_each_entry_safe(dev, temp, &hw_its->its_devices, entry)
>> +{
>> +if ( (dev->d->domain_id != d->domain_id) || (dev->devid != devid) )
>> +continue;
>> +
>> +its_send_cmd_mapd(hw_its, dev->devid, 0, 0, false);
>> +xfree(dev->itt_addr);
>> +if ( !valid )
>> +{
>> +xfree(dev);
> xfree() should be done after list_del()

Oh, indeed.

>> +list_del(&dev->entry);
>> +
>> +return 0;
>> +}
>> +
>> +reuse_dev = true;
>> +break;
>> +}
>> +
>> +if ( !valid )
>> +return 0;
>> +
>> +itt_addr = _xmalloc(BIT(bits) * hw_its->itte_size, 256);
>> +if ( !itt_addr )
>> +return -ENOMEM;
>> +
>> +if ( !reuse_dev )
>> +{
>> +dev = xmalloc(struct its_devices);
>> +if ( !dev )
>> +return -ENOMEM;
>> +
>> +list_add_tail(&dev->entry, &hw_its->its_devices);
>> +}
>> +
>> +dev->itt_addr = itt_addr;
>> +dev->d = d;
>> +dev->devid = devid;
>> +
>> +return its_send_cmd_mapd(hw_its, devid, bits - 1,
>> + itt_addr ? virt_to_maddr(itt_addr) : 0, true);
>   check on itt_addr is redundant

Ah, yes, this is an artifact of an earlier version. Thanks for spotting
this.

> 
>> +}
>> +
>> +/* Removing any connections a domain had to any ITS in the system. */
>> +int its_remove_domain(struct domain *d)
>> +{
>> +struct host_its *its;
>> +struct its_devices *dev, *temp;
>> +
>> +list_for_each_entry(its, &host_its_list, entry)
>> +{
>> +list_for_each_entry_safe(dev, temp, &its->its_devices, entry)
>> +{
>> +if ( dev->d->domain_id != d->domain_id )
>> +continue;
>> +
>> +its_send_cmd_mapd(its, dev->devid, 0, 0, false);
>> +xfree(dev->itt_addr);
>> +xfree(dev);
> 
> xfree() should be done after list_del(
>> +list_del(&dev->entry);
>> +}
> This code is same as above. Can be moved to a separate function?

Probably. Will take a look.

Thanks,
Andre.

>> +}
>> +
>> +return 0;
>> +}
>> +
>>  /* Set up the (1:1) collection mapping for the given host CPU. */
>>  void gicv3_its_setup_collection(int cpu)
>>  {
>> @@ -297,6 +385,7 @@ int gicv3_its_init(struct host_its *hw_its)
>>
>>  reg = readq_relaxed(hw_its->its_base + GITS_TYPER);
>>  hw_its->pta = reg & GITS_TYPER_PTA;
>> +hw_its->itte_size = ((reg >> 4) & 0xf) + 1;
>   can define a macro for these constants
>>
>>  for (i = 0; i < 8; i++)
>>  {
>> @@ -520,6 +609,7 @@ void gicv3_its_dt_init(const struct dt_device_node *node)
>>  its_data->size = size;
>>  its_data->dt_node = its;
>>  spin_lock_init(&its_data->cmd_lock);
>> +INIT_LIST_HEAD(&its_data->its_devices);
>>
>>  printk("GICv3: Found ITS @0x%lx\n", addr);
>>
>> diff --git a/xen/include/asm-arm/gic-its.h b/xen/include/asm-arm/gic-its.h
>> index 512a388..4e9841a 100644
>> --- a/xen/include/asm-arm/gic-its.h
>> +++ b/xen/include/asm-arm/gic-its.h
>> @@ -79,6 +79,13 @@
>>  #ifndef __ASSEMBLY__
>>  #include 
>>
>> +struct its_devices {
>> +struct list_head entry;
>> +struct domain *d;
>> +void 

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

[osstest service owner]

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

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  4ccb2adb96042e0d1e334c01fe260b32e6001db9
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101834  2016-10-31 22:10:29 Z2 days
Failing since101884  2016-11-03 12:02:50 Z0 days4 attempts
Testing same since   101892  2016-11-03 18:02:24 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Konrad Rzeszutek Wilk 
  Roger Pau Monne 
  Roger Pau Monné 
  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=4ccb2adb96042e0d1e334c01fe260b32e6001db9
+ . ./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 
4ccb2adb96042e0d1e334c01fe260b32e6001db9
+ branch=xen-unstable-smoke
+ revision=4ccb2adb96042e0d1e334c01fe260b32e6001db9
+ . ./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
+ '[' x4ccb2adb96042e0d1e334c01fe260b32e6001db9 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/

Re: [Xen-devel] [RFC PATCH 08/24] ARM: GICv3: introduce separate pending_irq structs for LPIs

[Andre Przywara]

Hi,

On 24/10/16 16:31, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> wrote:
>> For the same reason that allocating a struct irq_desc for each
>> possible LPI is not an option, having a struct pending_irq for each LPI
>> is also not feasible. However we actually only need those when an
>> interrupt is on a vCPU (or is about to be injected).
>> Maintain a list of those structs that we can use for the lifecycle of
>> a guest LPI. We allocate new entries if necessary, however reuse
>> pre-owned entries whenever possible.
>> Teach the existing VGIC functions to find the right pointer when being
>> given a virtual LPI number.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/gic.c|  3 +++
>>  xen/arch/arm/vgic-v3.c|  2 ++
>>  xen/arch/arm/vgic.c   | 56 
>> ---
>>  xen/include/asm-arm/domain.h  |  1 +
>>  xen/include/asm-arm/gic-its.h | 10 
>>  xen/include/asm-arm/vgic.h|  9 +++
>>  6 files changed, 78 insertions(+), 3 deletions(-)
>>
>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>> index 63c744a..ebe4035 100644
>> --- a/xen/arch/arm/gic.c
>> +++ b/xen/arch/arm/gic.c
>> @@ -506,6 +506,9 @@ static void gic_update_one_lr(struct vcpu *v, int i)
>>  struct vcpu *v_target = vgic_get_target_vcpu(v, irq);
>>  irq_set_affinity(p->desc, cpumask_of(v_target->processor));
>>  }
>> +/* If this was an LPI, mark this struct as available again. */
>> +if ( p->irq >= 8192 )
>  Can define something line is_lpi(irq) and use it everywhere

Yes, that was on my list anyway.

>> +p->irq = 0;
>>  }
>>  }
>>  }
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index ec038a3..e9b6490 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -1388,6 +1388,8 @@ static int vgic_v3_vcpu_init(struct vcpu *v)
>>  if ( v->vcpu_id == last_cpu || (v->vcpu_id == (d->max_vcpus - 1)) )
>>  v->arch.vgic.flags |= VGIC_V3_RDIST_LAST;
>>
>> +INIT_LIST_HEAD(&v->arch.vgic.pending_lpi_list);
>> +
>>  return 0;
>>  }
>>
>> diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
>> index 0965119..b961551 100644
>> --- a/xen/arch/arm/vgic.c
>> +++ b/xen/arch/arm/vgic.c
>> @@ -31,6 +31,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>>  static inline struct vgic_irq_rank *vgic_get_rank(struct vcpu *v, int rank)
>>  {
>> @@ -61,7 +63,7 @@ struct vgic_irq_rank *vgic_rank_irq(struct vcpu *v, 
>> unsigned int irq)
>>  return vgic_get_rank(v, rank);
>>  }
>>
>> -static void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
>> +void vgic_init_pending_irq(struct pending_irq *p, unsigned int virq)
>>  {
>>  INIT_LIST_HEAD(&p->inflight);
>>  INIT_LIST_HEAD(&p->lr_queue);
>> @@ -244,10 +246,14 @@ struct vcpu *vgic_get_target_vcpu(struct vcpu *v, 
>> unsigned int virq)
>>
>>  static int vgic_get_virq_priority(struct vcpu *v, unsigned int virq)
>>  {
>> -struct vgic_irq_rank *rank = vgic_rank_irq(v, virq);
>> +struct vgic_irq_rank *rank;
>>  unsigned long flags;
>>  int priority;
>>
>> +if ( virq >= 8192 )
>> +return gicv3_lpi_get_priority(v->domain, virq);
>> +
>> +rank = vgic_rank_irq(v, virq);
>>  vgic_lock_rank(v, rank, flags);
>>  priority = rank->priority[virq & INTERRUPT_RANK_MASK];
>>  vgic_unlock_rank(v, rank, flags);
>> @@ -446,13 +452,55 @@ int vgic_to_sgi(struct vcpu *v, register_t sgir, enum 
>> gic_sgi_mode irqmode, int
>>  return 1;
>>  }
>>
>> +/*
>> + * Holding struct pending_irq's for each possible virtual LPI in each domain
>> + * requires too much Xen memory, also a malicious guest could potentially
>> + * spam Xen with LPI map requests. We cannot cover those with (guest 
>> allocated)
>> + * ITS memory, so we use a dynamic scheme of allocating struct pending_irq's
>> + * on demand.
>> + */
>> +struct pending_irq *lpi_to_pending(struct vcpu *v, unsigned int lpi,
>> +   bool allocate)
>> +{
>> +struct lpi_pending_irq *lpi_irq, *empty = NULL;
>> +
>> +/* TODO: locking! */
>> +list_for_each_entry(lpi_irq, &v->arch.vgic.pending_lpi_list, entry)
>> +{
>> +if ( lpi_irq->pirq.irq == lpi )
>> +return &lpi_irq->pirq;
>> +
>> +if ( lpi_irq->pirq.irq == 0 && !empty )
>> +empty = lpi_irq;
>> +}
>With this approach of allocating pending_irq on demand, if the
> pending_lpi_list
> is at n position then it iterates for long time to find pending_irq entry.
> This will increase LPI injection time to domain.
> 
> Why can't we use btree?

That's an optimization. You will find that the actual number of
interrupts on a VCPU at any given time is very low, especially if we
look at LPIs only. So my hunch is that it's either 0, 1 or 2, not more.
So for simplicity I'd keep it as a list for now. If we s

Re: [Xen-devel] [RFC PATCH 11/24] ARM: vGICv3: handle virtual LPI pending and property tables

[Andre Przywara]

Hi,

On 24/10/16 16:32, Vijay Kilari wrote:
> On Wed, Sep 28, 2016 at 11:54 PM, Andre Przywara  
> wrote:
>> Allow a guest to provide the address and size for the memory regions
>> it has reserved for the GICv3 pending and property tables.
>> We sanitise the various fields of the respective redistributor
>> registers and map those pages into Xen's address space to have easy
>> access.
>>
>> Signed-off-by: Andre Przywara 
>> ---
>>  xen/arch/arm/vgic-v3.c| 189 
>> ++
>>  xen/arch/arm/vgic.c   |   4 +
>>  xen/include/asm-arm/domain.h  |   7 +-
>>  xen/include/asm-arm/gic-its.h |  10 ++-
>>  xen/include/asm-arm/vgic.h|   3 +
>>  5 files changed, 197 insertions(+), 16 deletions(-)
>>
>> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
>> index e9b6490..8fe8386 100644
>> --- a/xen/arch/arm/vgic-v3.c
>> +++ b/xen/arch/arm/vgic-v3.c
>> @@ -20,12 +20,14 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -228,12 +230,14 @@ static int __vgic_v3_rdistr_rd_mmio_read(struct vcpu 
>> *v, mmio_info_t *info,
>>  goto read_reserved;
>>
>>  case VREG64(GICR_PROPBASER):
>> -/* LPI's not implemented */
>> -goto read_as_zero_64;
>> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> +*r = vgic_reg64_extract(v->domain->arch.vgic.rdist_propbase, info);
>> +return 1;
>>
>>  case VREG64(GICR_PENDBASER):
>> -/* LPI's not implemented */
>> -goto read_as_zero_64;
>> +if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> +*r = vgic_reg64_extract(v->arch.vgic.rdist_pendbase, info);
>> +return 1;
>>
>>  case 0x0080:
>>  goto read_reserved;
>> @@ -301,11 +305,6 @@ bad_width:
>>  domain_crash_synchronous();
>>  return 0;
>>
>> -read_as_zero_64:
>> -if ( !vgic_reg64_check_access(dabt) ) goto bad_width;
>> -*r = 0;
>> -return 1;
>> -
>>  read_as_zero_32:
>>  if ( dabt.size != DABT_WORD ) goto bad_width;
>>  *r = 0;
>> @@ -330,11 +329,149 @@ read_unknown:
>>  return 1;
>>  }
>>
>> +static uint64_t vgic_sanitise_field(uint64_t reg, uint64_t field_mask,
>> +int field_shift,
>> +uint64_t (*sanitise_fn)(uint64_t))
>> +{
>> +uint64_t field = (reg & field_mask) >> field_shift;
>> +
>> +field = sanitise_fn(field) << field_shift;
>> +return (reg & ~field_mask) | field;
>> +}
>> +
>> +/* We want to avoid outer shareable. */
>> +static uint64_t vgic_sanitise_shareability(uint64_t field)
>> +{
>> +switch (field) {
>> +case GIC_BASER_OuterShareable:
>> +return GIC_BASER_InnerShareable;
>> +default:
>> +return field;
>> +}
>> +}
>> +
>> +/* Avoid any inner non-cacheable mapping. */
>> +static uint64_t vgic_sanitise_inner_cacheability(uint64_t field)
>> +{
>> +switch (field) {
>> +case GIC_BASER_CACHE_nCnB:
>> +case GIC_BASER_CACHE_nC:
>> +return GIC_BASER_CACHE_RaWb;
>> +default:
>> +return field;
>> +}
>> +}
>> +
>> +/* Non-cacheable or same-as-inner are OK. */
>> +static uint64_t vgic_sanitise_outer_cacheability(uint64_t field)
>> +{
>> +switch (field) {
>> +case GIC_BASER_CACHE_SameAsInner:
>> +case GIC_BASER_CACHE_nC:
>> +return field;
>> +default:
>> +return GIC_BASER_CACHE_nC;
>> +}
>> +}
>> +
>> +static uint64_t sanitize_propbaser(uint64_t reg)
>> +{
>> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_SHAREABILITY_MASK,
>> +  GICR_PROPBASER_SHAREABILITY_SHIFT,
>> +  vgic_sanitise_shareability);
>> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_INNER_CACHEABILITY_MASK,
>> +  GICR_PROPBASER_INNER_CACHEABILITY_SHIFT,
>> +  vgic_sanitise_inner_cacheability);
>> +reg = vgic_sanitise_field(reg, GICR_PROPBASER_OUTER_CACHEABILITY_MASK,
>> +  GICR_PROPBASER_OUTER_CACHEABILITY_SHIFT,
>> +  vgic_sanitise_outer_cacheability);
>> +
>> +reg &= ~PROPBASER_RES0_MASK;
>> +reg &= ~GENMASK(51, 48);
>> +return reg;
>> +}
>> +
>> +static uint64_t sanitize_pendbaser(uint64_t reg)
>> +{
>> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_SHAREABILITY_MASK,
>> +  GICR_PENDBASER_SHAREABILITY_SHIFT,
>> +  vgic_sanitise_shareability);
>> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_INNER_CACHEABILITY_MASK,
>> +  GICR_PENDBASER_INNER_CACHEABILITY_SHIFT,
>> +  vgic_sanitise_inner_cacheability);
>> +reg = vgic_sanitise_field(reg, GICR_PENDBASER_OUTER_CACHEABILITY_MASK,
>> +  GICR_PENDBASER_OUTER_CACH

[Xen-devel] [linux-3.10 test] 101865: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 100648
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 100648
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 100648
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 100648
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 100648

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-install   fail in 101783 pass in 101865
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 101576
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 101594
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101663
 test-amd64-i386-libvirt   6 xen-boot   fail pass in 101680
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot  fail pass in 101680
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot   fail pass in 101731
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101731
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host fail pass in 101731
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host fail pass in 101731
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot fail pass in 101783
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot   fail pass in 101783
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101800
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101800
 test-amd64-amd64-qemuu-nested-intel  6 xen-bootfail pass in 101814
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
101828
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101828
 test-amd64-amd64-pair 9 xen-boot/src_host  fail pass in 101828
 test-amd64-amd64-pair10 xen-boot/dst_host  fail pass in 101828
 test-amd64-i386-freebsd10-i386  6 xen-boot fail pass in 101837
 test-amd64-amd64-xl-multivcpu  6 xen-boot  fail pass in 101837
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot  fail pass in 101844
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101844
 test-amd64-amd64-xl-xsm   6 xen-boot   fail pass in 101856
 test-amd64-amd64-xl-qcow216 guest-localmigrate/x10 fail pass in 101856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101594 like 100646
 build-i386-rumprun5 rumprun-build fail in 101663 baseline untested
 build-amd64-rumprun   5 rumprun-build fail in 101663 baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100648
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 100648

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt 12 migrate-support-check fail in 101680 never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101731 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 101731 never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux7828a9658951301a3fd83daa4ed0a607d370399e
baseline version:
 linux2ecaf1d025af0f481d00b3701ffbcc600dcab076

Last test of basis   100648  2016-08-28 23:14:14 Z   66

[Xen-devel] [libvirt bisection] complete build-i386-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  680d2f49dad425395de627a31006cb84848cfa65
  Bug not present: c290f216c47afbd4f3d1e082cdb98181675cd31e
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/101903/


  commit 680d2f49dad425395de627a31006cb84848cfa65
  Author: Pavel Hrdina 
  Date:   Fri Oct 21 23:09:53 2016 +0200
  
  configure: move gnutls check into virt-gnutls.m4
  
  Signed-off-by: Pavel Hrdina 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/libvirt/build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-i386-libvirt.libvirt-build 
--summary-out=tmp/101903.bisection-summary --basis-template=101839 
--blessings=real,real-bisect libvirt build-i386-libvirt libvirt-build
Searching for failure / basis pass:
 101868 fail [host=baroque0] / 101854 [host=elbling0] 101839 [host=baroque1] 
101773 [host=baroque1] 101738 [host=baroque1] 101711 [host=elbling1] 101677 
[host=elbling1] 101656 [host=huxelrebe0] 101640 [host=elbling1] 101629 
[host=chardonnay1] 101602 [host=elbling0] 101573 [host=chardonnay1] 101557 
[host=huxelrebe0] 101538 [host=huxelrebe0] 101502 [host=baroque1] 101477 ok.
Failure / basis pass flights: 101868 / 101477
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 478ddedc12b77313cbaf72328ab2236ce7c56ead 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
Basis pass 538220c3c42cad0adbd818b6a931c69492a572de 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
20295ab63ce7f57edca9c450602ac2dace1fc721
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#538220c3c42cad0adbd818b6a931c69492a572de-478ddedc12b77313cbaf72328ab2236ce7c56ead
 
git://git.sv.gnu.org/gnulib.git#e89b4a7aefce9cb02963920712ba7cdd13641644-e89b4a7aefce9cb02963920712ba7cdd13641644
 
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-c4e0d84d3c92923fdbc7fa922638d54e5e834753
 
git://xenbits.xen.org/qemu-xen.git#570117996772b762e9654e58e708943a4db68b4f-6cfcdf037edadba984ccf8476b5d1e2a0940b789
 
git://xenbits.xen.org/xen.git#20295ab63ce7f57edca9c450602ac2dace1fc721-496673a2ada93c201fbe1cc83146c8bd8e79169d
Loaded 3004 nodes in revision graph
Searching for test results:
 101461 pass irrelevant
 101477 pass 538220c3c42cad0adbd818b6a931c69492a572de 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
570117996772b762e9654e58e708943a4db68b4f 
20295ab63ce7f57edca9c450602ac2dace1fc721
 101538 [host=huxelrebe0]
 101502 [host=baroque1]
 101557 [host=huxelrebe0]
 101573 [host=chardonnay1]
 101602 [host=elbling0]
 101640 [host=elbling1]
 101629 [host=chardonnay1]
 101656 [host=huxelrebe0]
 101677 [host=elbling1]
 101711 [host=elbling1]
 101738 [host=baroque1]
 101773 [host=baroque1]
 101839 [host=baroque1]
 101894 pass 06a7b1ff4dbb1ed6a69e09765bef1f67a75a86eb 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
35ac0c08178ac15565b32ca56b00fa5414f1d3b1
 101895 pass c290f216c47afbd4f3d1e082cdb98181675cd31e 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101896 fail 3c06aa7b30e91920698368ceb87c49aab06e37fe 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101897 fail 0c62ccf927c60c9c248db52a23670ec2f9bce2b2 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101854 [host=elbling0]
 101898 fail 680d2f49dad425395de627a31006cb84848cfa65 
e89b4a7aefce9cb02963920712ba7cdd13641644 
c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
496673a2ada93c201fbe1cc83146c8bd8e79169d
 101

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale  3 host-install(3) broken in 101861 pass in 101869
 test-armhf-armhf-libvirt 15 guest-start/debian.repeat fail in 101861 pass in 
101869
 test-amd64-amd64-xl-qcow29 debian-di-install fail in 101861 pass in 101869
 test-armhf-armhf-xl-vhd   6 xen-boot   fail pass in 101861

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101861
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101861
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101861
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101861
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101861
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101861
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101861
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101861
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 101861 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 101861 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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 build-amd64-rumprun   7 xen-buildfail   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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 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-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass

version targeted for testing:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d
baseline version:
 xen  496673a2ada93c201fbe1cc83146c8bd8e79169d

Last test of basis   101869  2016-11-03 04:29:02 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17108 days0 attempts

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

[Xen-devel] [linux-3.4 test] 101867: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
92983
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 92983
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 92983
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot   fail REGR. vs. 92983
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 92983
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 92983

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail in 101695 pass 
in 101867
 test-amd64-amd64-i386-pvgrub  6 xen-boot   fail pass in 101695
 test-amd64-amd64-xl-rtds  6 xen-boot   fail pass in 101695
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101695
 test-amd64-i386-pair  9 xen-boot/src_host  fail pass in 101720
 test-amd64-i386-pair 10 xen-boot/dst_host  fail pass in 101720
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot   fail pass in 101822
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot   fail pass in 101840
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot  fail pass in 101840

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92983
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92983
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92983

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-rumprun   7 xen-buildfail   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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 build-i386-rumprun7 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass

version targeted for testing:
 linux8d1988f838a95e836342b505398d38b223181f17
baseline version:
 linux343a5fbeef08baf2097b8cf4e26137cebe3cfef4

Last test of basis92983  2016-04-27 16:21:44 Z  190 days
Testing same since   101695  2016-10-26 18:26:23 Z8 days   13 attempts


People who touched revisions under test:
  "Suzuki K. Poulose" 
  Aaro Koskinen 
  Al Viro 
  Alan Stern 
  Aleksander Morgado 
  Alex Thorlton 
  Alexandru Cornea 
  Alexey Khoroshilov 
  Amitkumar Karwar 
  Andrew Banman 
  Andrew Morton 
  Andrey Ryabinin 
  Anson Huang 
  Arnaldo Carvalho de Melo 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Ben Hutchings 
  Bjørn Mork 
  Boris Brezillon 
  Borislav Petkov 
  Brian Norris 
  Charles Keepax 
  Chen Yu 
  Christoph Hellwig 
  Chunfeng Yun 
  Clemens Ladisch 
  Colin Ian King 
  Cong Wang 
  Daeho Jeong 
  Dan Carpenter 
  Darren Hart 
  Dave Airlie 
  David Howells 
  David Rientjes 
  David S. Miller 
  David Turner 
  David Vrabel 
  David Woodhouse 
  Dmitry Tunin 
  Dmitry V. Levin 
  Dmitry Vyukov 
  Eric Dumazet 
  Eric Dumazet 
  Felipe Balbi 
  Filipe Manana 
  Francesco Ruggeri 
  Francesco Ruggeri 
  Greg Kroah-Hartman 
  Helge Deller 
  Herbert Xu 
  Hillf Danton 
  Hobin Woo 
  Hu 
  Ingo Molnar 
  James Bottomley 
  James Bottomley 
  James Morris 
  Jan Beulich 
  Jan Kara 
  Jason A. Donenfeld 
  Jeff Layton 
  Jeff Layton 
  Jens Axboe 
  Jiri Kosina 
  Jiri Slaby 
  Joe Thornber 
  Johan Hovold 
  Johannes Be

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-install  fail blocked in 101835
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101835
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101835
 test-armhf-armhf-libvirt-qcow2 12 saverestore-support-check   fail like 101835
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 101835
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 101835
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101835
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 101835

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-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-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu4eb28abd52d48657cff6ff45e8dbbbefe4dbb414
baseline version:
 qemuue80b4b8fb6babce7dcc91ea9ddeecbc351fd4646

Last test of basis   101835  2016-10-31 22:21:49 Z3 days
Failing since101842  2016-11-01 09:47:34 Z2 days4 attempts
Testing same since   101850  2016-11-01 22:20:17 Z2 days3 attempts


People who touched revisions under test:
  Corey Minyard 
  Denis Plotnikov 
  Denis V. Lunev 
  Edgar E. Iglesias 
  Eduardo Habkost 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Jeff Cody 
  John Snow 
  Joseph Myers 
  Kevin Wolf 
  Li Qiang 
  Mark Cave-Ayland 
  Michael Roth 
  Peter Maydell 
  Pranith Kumar 
  Prasanna Kumar Kalever 
  Richard Henderson 
  Stefan Hajnoczi 
  Xiubo Li 

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   

Re: [Xen-devel] [PATCH 04/12] xen: make use of xenbus_read_unsigned() in xen-tpmfront

[Jarkko Sakkinen]

On Mon, Oct 31, 2016 at 05:48:22PM +0100, Juergen Gross wrote:
> Use xenbus_read_unsigned() instead of xenbus_scanf() when possible.
> This requires to change the type of one read from int to unsigned,
> but this case has been wrong before: negative values are not allowed
> for the modified case.
> 
> Cc: peterhu...@gmx.de
> Cc: tp...@selhorst.net
> Cc: jarkko.sakki...@linux.intel.com
> Cc: jguntho...@obsidianresearch.com
> Cc: tpmdd-de...@lists.sourceforge.net
> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Jarkko Sakkinen 

/Jarkko

> ---
>  drivers/char/tpm/xen-tpmfront.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
> index 62028f4..50072cc 100644
> --- a/drivers/char/tpm/xen-tpmfront.c
> +++ b/drivers/char/tpm/xen-tpmfront.c
> @@ -337,18 +337,14 @@ static int tpmfront_resume(struct xenbus_device *dev)
>  static void backend_changed(struct xenbus_device *dev,
>   enum xenbus_state backend_state)
>  {
> - int val;
> -
>   switch (backend_state) {
>   case XenbusStateInitialised:
>   case XenbusStateConnected:
>   if (dev->state == XenbusStateConnected)
>   break;
>  
> - if (xenbus_scanf(XBT_NIL, dev->otherend,
> - "feature-protocol-v2", "%d", &val) < 0)
> - val = 0;
> - if (!val) {
> + if (!xenbus_read_unsigned(dev->otherend, "feature-protocol-v2",
> +   0)) {
>   xenbus_dev_fatal(dev, -EINVAL,
>   "vTPM protocol 2 required");
>   return;
> -- 
> 2.6.6
> 

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

Re: [Xen-devel] [PATCH for-4.8 2/2] libxl: disallow enabling PoD and ALTP2M at the same time

[Tian, Kevin]

> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: Friday, November 04, 2016 12:42 AM
> 
> That combination would cause Xen to crash.
> 
> Note that although this is a security issue, is not XSA-worthy because
> ALTP2M is experimental.
> 
> Signed-off-by: Wei Liu 
> ---
> Move the snippet to the correct location after altp2m is correctly
> initialised. Also correctly set ret before exiting.
> 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: George Dunlap ,
> Cc: Andrew Cooper 
> Cc: Kevin Tian 
> Cc: Jun Nakajima 
> ---
>  tools/libxl/libxl_create.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> index abd2272..7c1695a 100644
> --- a/tools/libxl/libxl_create.c
> +++ b/tools/libxl/libxl_create.c
> @@ -915,6 +915,14 @@ static void initiate_domain_create(libxl__egc *egc,
>  goto error_out;
>  }
> 
> +if (d_config->c_info.type == LIBXL_DOMAIN_TYPE_HVM &&
> +libxl_defbool_val(d_config->b_info.u.hvm.altp2m) &&
> +pod_enabled) {
> +ret = ERROR_INVAL;
> +LOG(ERROR, "Cannot enable PoD and ALTP2M at the same time");
> +goto error_out;
> +}
> +
>  ret = libxl__domain_make(gc, d_config, &domid, &state->config);
>  if (ret) {
>  LOG(ERROR, "cannot make domain: %d", ret);
> --
> 2.1.4

Reviewed-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v2] VMX: fix realmode emulation SReg handling

[Tian, Kevin]

> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Saturday, October 29, 2016 12:21 AM
> 
> Commit 0888d36bb2 ("x86/emul: Correct the decoding of SReg3 operands")
> overlooked three places where x86_seg_cs was assumed to be zero.
> 
> Signed-off-by: Jan Beulich 
> Reviewed-by: Andrew Cooper 
> Release-acked-by: Wei Liu 
> ---
> v2: Add BUILD_BUG_ON() and use ARRAY_SIZE(reg) as loop bound.

Acked-by: Kevin Tian 

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